Note: This post is part of a series and you can find the rest of the parts in the series index.
IProvider is the first class we will look at implementing for both adapters (WI and VC) as it provides the core information for the platform to talk to our adapter. The first thing you provider needs is the ProviderDescriptionAttribute, which has three properties ID, Name and Version.
[ProviderDescription("{7F3F91B2-758A-4B3C-BBA8-CE34AE1D48EE}", "SharePoint TIP Adapter - Version Control", "1.0.0.0")]
The ID must be unique and you will need a record of it somewhere as it is used in configuration for the platform. The name and version are potentially used to make it easier for users, but I have not seen them used anywhere (maybe in future/different tools).
The only method in the provider is the GetService method which is used to get the implementations of the interfaces/classes we will be building later. Put another way this allows the platform to request a class which implements a specific interface using this method:
object IServiceProvider.GetService(Type serviceType)
{
TraceManager.TraceInformation("WSSVC:Adapter:GetService - {0}", serviceType);
if (serviceType == typeof(IAnalysisProvider))
{
if (analysisProvider == null)
{
analysisProvider = new SharePointVCAnalysisProvider();
}
return analysisProvider;
}
if (serviceType == typeof(IMigrationProvider))
{
if (migrationProvider == null)
{
migrationProvider = new SharePointVCMigrationProvider();
}
return migrationProvider;
}
if (serviceType == typeof(IServerPathTranslationService))
{
if (transalationProvider == null)
{
transalationProvider = new SharePointVCAdapterTranslation();
}
return transalationProvider;
}
return null;
}
Above is the implementation is what I used in the SharePoint VC adapter, the WI adapter is the same except it does not have the server path translation service at the end.
Power Tip: Using Visual Studio 2010’s new “Generation from usage” features makes this stage of development much easier.