views:

245

answers:

1

I have several DNN modules that I wish to update silently, using the portal's built-in module upgrade facilities called from a separate application, in this case a Windows service. I was able to make it all work with version 4.3 of the portal by modifying the DNN source in key areas to allow DotNetNuke.dll to function outside of a web application. I'm now trying to do the same thing with the 4.9.0 source code and I'm having problems.

Everything works fine until DNN tries to read from the database. I have my Windows service project, the DNN library project, and several other related projects loaded in one VS solution (the additional projects are the same ones that are in the main solution file provided with the DNN source). I call PaInstaller.Install in my service to update each module. Execution gets to reflection.vb and then it tries to create a DotNetNuke.Data.SqlDataProvider object based on the type name. It raises an exception when calling System.Web.Compilation.BuildManager.GetType. The exception says:

Could not load type 'DotNetNuke.Data.SqlDataProvider' from assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

I read this to mean it simply couldn't locate the DotNetNuke.SqlDataProvider.dll assembly. What's strange is that assembly is in the Bin folder for the DNN library project, and I also have it in the folder where my Windows service is running. The actual SqlDataProvider project is also loaded in the solution. I can't for the life of me understand why the runtime environment can't locate the assembly.

Has anyone tried something like this before, or know what could cause an assembly not to be found while stepping through the DNN source? Am I better off using something other than BuildManager.GetType to get an instance of the SQL provider type?

+4  A: 

Chris,

Honestly depending on your needs, I would look at doing this a different way, as this is going to be very fragile with each DNN upgrade that happens in the future.

I'd look more towards using the "bulk install" option that DNN already has. Have your service upload the module zips to the /install/modules folder, then from there, call /install/install.aspx?mode=installresources and you are done!

If you need a third party solution to parse the results, have your windows service go through and pull the HTML response and parse it to validate success.

Mitchel Sellers
I didn't know there was a bulk install option. That sounds like it would work for me. Is there any documentation for it anywhere? What exactly does the HTML response look like, and how would I know the bulk install succeeded?
Chris Tybur
Chris - AFAIK there isn't much "documentation" to it, I can try to whip up a blog post about it sometime soon. The HTML response is very structured, and should be easy to parse to validate success/failure. But it has been a little while since I looked at it.
Mitchel Sellers
Anything you can post would be helpful. I'll experiment with it and see how far I get.
Chris Tybur
Initiating a bulk install from a Windows service worked beautifully. Definitely easier than my original approach.
Chris Tybur
Chris, I'm glad that it worked out for you! (If you are a blogger, a blog post about it would be awesome. If you do let me know and I'll get you some exposure for the article)
Mitchel Sellers