dukesb11 wrote
The type is just the namespace plus the class name, that is correct. It looks like you have it right in your initial post.
1st question, you had mentioned that it was pulling something from the cache, did anything ever come of that? Is it still doing that? What error is it throwing after it gets the instance from the cache?
Secondly, you might try putting your new PortalSqlDataProvider.vb file in one of the existing projects, and see if it will see it then (keep the same namespace, just either point to the new assembly or leave off the assembly name). Then you can get a better grasp as to whether it's a problem with your code or with not being able to find the class' definition.
With the /bin folder, that is the only place that ASP.NET will look for assemblies by default, they have to be in that folder to be found.
Do you have Lutz Roeder's Reflector for .NET? It's a little program that comes in handy for me a lot. It will let you look at assemblies to see what is in them, and to search through them. You might try loading your MyCompany.Provider assembly in there, and just double check the namespace and class name that it being output. (It's also useful for loading up all of the DNN assemblies and searching through them for specific classes and functionality).
Hope it helps,
Although I haven't revisited the cache issue today, the error when pulled from cache is indeed the one I was reporting before. I do not know what "cache" it is pulling from though, because the assembly is not in the GAC and it continued to pull from the cache even following a reboot.
I haven't tried putting my vb file into another one of my projects yet, but my completely updated one worked fine when it replaced the DNN core one.
I understand the need for the assemblies to be in the bin folder. I am manually copying them since my provider projects/solution is not loaded within the DNN source build. That is what I say it is mainly a convenience factor. I don't normally develop any class libraries within the DNN source.