I think Ihave a bead on this issue but I still wanted to post and see what others think. I have written a custom module for DNN 5.x using VS2010 Ultimate and the DNN Modulke Template. On my local server (single server) I can install it without issue, however when I try and upload the module on to my staging server(load balanced) I get the follwoing error. I can get around this by disabling all but one of my servers and logging on locally to the box and installing it locally this however is unacceptable for our production ENV. So I need a better way to get this installed on a webfarm. FYI I have even given "Everyone" full control and was still not able to install from the browser on my local dev to the staging DNN site. Any thoughts????

Info	Reading Component Manifest - Script
Info	Found valid path () for 01.00.00.SqlDataProvider.
Info	Found valid path () for Uninstall.SqlDataProvider.
Info	Reading Component Manifest - Module
Info	Module Manifest read successfully
Info	Reading Component Manifest - Assembly
Failure	File specified in the dnn could not be found in the zip file: - C:\LSIWebs\STGLSIDNN\Install\Temp\wxeamtph\UploadMultipleFiles.dll
Info	Reading Component Manifest - File
Info	Found valid path () for ViewUploadMultipleFiles

Couple of observations.

1) This looks like you're using local storage for each web head, ie. two copies of all files as opposed to a single share which both can address (by mapping or UNC share).  Unless you have a customized file storage synch, this will pose some problems.  I know some installations run this way, but they tend to do so with deep in-house expertise on these solutions.  Without synching, it won't matter how you install the application because the files will only be written to one web head and when a request is processed on the other web head for a module related file (ascx, dll, etc) it won't be there.

2) Even with file synching, you'd probably want to establish some sort of stickiness to a single webhead for administrative uses at least.  We tend to implement web farms with stickiness to a user "session" (not in the .net sense).  Because it looks like what you're getting is a response from the webhead that does not have the files on it (rather than the webhead that you clicked "submit" from).  This would indicate your doing pure round robin by request sort of farming?  If you have the ability to reach a specifc web head apart from the farm (for host operations like this), that would be idea.  You can run into the same sort of requirement for the scheduler where you need to manage a job to run on a single specified server as well.

Hope that helps!

---

Scott Willhite, Co-Founder DNN