OK, after considerable head-butting & hair-pulling, I have got it through.
The problem is that the SqlDataProvider in DNN (for worse) has special treatment. The culprit is the following code in abstract DataProvider:
|
Private Const ProviderType As String = "data" ' maps to <sectionGroup> in web.config
Private Const ProviderNamespace As String = "DotNetNuke.Data" ' project namespace
Private Const ProviderAssemblyName As String = "" ' project assemblyname
' singleton reference to the instantiated object
Private Shared objProvider As DataProvider = Nothing
' constructor
Shared Sub New()
CreateProvider()
End Sub
' dynamically create provider
Private Shared Sub CreateProvider()
objProvider = CType(Framework.Reflection.CreateObject(ProviderType, ProviderNamespace, ProviderAssemblyName), DataProvider)
End Sub
|
You can clearly see the hard-coded Provider NameSpace (although the assembly name is not hard-coded). So, DNN expects its concrete DataProvider to be always DotNetNuke.Data.SqlDataProvider. (For some strange reasons beyond comprehension, the Provider namespace is not discovered the same way i.e. Reflection, as it is done for other providers).
This affectively means that you can put your DataProvider in any assembly as you wish (remember, it should still inherit the abstract provider), but the Fully Qualified Name of the DataProvider should always be DotNetNuke.Data.SqlDataProvider.
What's more, when you put this assembly in the bin folder, there arises another problem. Now there are two classes with exactly same Fully Qualified Name, that is unacceptable to DotNet. That effectively means that you need to delete the DotNetNuke.SqlDataProvider.dll assembly from your bin folder. Although you can change the abstract Data Provider to find the concrete Provider namespace y Relfection easily (just copy the code from any other provider to do so), but this code is at the heart of DNN, and modifying it would render your installation utterly difficult to upgrade. So, deleting the DNN Core provider is the prefered way according to me.
Lastly, I wanted to customize only 10-12 method. So, I inherited the DNN SqlDataProvider. But with this came the same situation again. Although I had deleted the DNN's SqlProvider assembly from the bin, but my custom provider referenced it as it inherited from one of its classes. In effect, referencing my assembly in DNN copied the DNN's provider again into the bin folder, again creating namespace conflicts.
I seriously wanted to avoid rewriting all SqlProvider methods. SO, now what I have done is to copy the DNN SqlDataProvider's source class to my custom Provider assembly, renamed it to DNNSqlDataProvider, and then inherited it. I know this is a not a clean solution, but it provided me 2 advantages: I did not had to recode the entire Provider, and 2) While upgrading for a future version of DNN, I can just copy-paste the new DNN SqlDataProvider again, it there is any change to it, inherit it & see which methods need to be overridden.
Finally, the web.config part, it should look like following:
<data defaultProvider="SqlDataProvider">
<providers>
<clear/>
<add name="DNNSqlDataProvider" type="DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider" connectionStringName="SiteSqlServer" upgradeConnectionString="" providerPath="~\Providers\DataProviders\SqlDataProvider\" objectQualifier="" databaseOwner="dbo"/>
<add name="SqlDataProvider" type="DotNetNuke.Data.SqlDataProvider, Imbibe.DNN.Provider.SharedProfile" connectionStringName="SiteSqlServer" upgradeConnectionString="" providerPath="~\bin\" objectQualifier="" databaseOwner="dbo"
sharePersonalizationInfo="true" />
</providers>
</data> |
Although you can delete the entry for DNN's Sql DataProvider, I kept it just for reference.
REMEMBER, the name of the default DataProvider should remain SqlDataProvider, as has been explained on this thread:
http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/111/threadid/171688/scope/posts/Default.aspx
Rename DNN's Provider or delete it, but keep the default provider's name to be SqlDataProvider. What's more, in the type attribute, the name of the Provider is inconsequential (I haven't tried with assembly name, but believe that invalid assembly name should should lead to a run-time exception). But you can type any garbage value as the Fully Qualified Name of the Provider class in the type attribute, and DNN would ignore it, as the this has already been hard-coded into DNN as shown above!!!
Hope, this would help many others!!!