Website Error: "The specified module could not be found."

Hello all!

Finished setting up an account with DASP.NET this weekend for a demo application which uses two databases. Database side initially was tricky, but all items have been resolved (local debug run communicates and uses the DASP.NET DBs without issue). I thought the ASP.NET side would be pretty much seamless, but here is where I have run into a mystifying error:

"The specified module could not be found."​

I can't tell from the error what assembly or file it thinks it's missing. This is especially strange since I have used this same set of published files to deploy to two different servers without any issue. Potential things I can think of:

1. Application is .NET 3.5 and uses WCF, WWF (workflow), and Entity Framework. Are there are any special considerations for these I should be aware of when working with DASP.NET hosting?

2. Any file permission considerations? For example, in the past (not recently), I've seen cases where the application could not read web.config or some other fundamental file, causing things to go haywire.

3. Do I need to compile for a specific CPU target, e.g. x64?

I ran across some possibly related items, but not sure if this is the right direction:

• This sort of error can happen if there are .NET 1.1 assemblies being referenced - highly unlikely
• Can also happen if some unmanaged code is being referenced that is not included (e.g. some type of C++ redistributable) - possible I suppose, but how to best determine?

Finally, in desperation, I temporarily caused VS to "copy to local" all assemblies being referenced in the web application, to no avail.

The error may be observed firsthand here:

http://srd.sigilent.com​

Any ideas very welcome! Regards,

Allen

 

Hello all,

Posting the resolution for this for everyone's benefit. It turns out that the cause which I had completely discounted the first time was exactly the problem...

Sure enough, buried in one of the Windows Forms apps that are part of the solution (but not deployed to the web site) is a reference to an obscure little third-party assembly that is .NET 1.1.

It was exactly this one single reference (that isn't even used by the web app in any way) that was completely breaking execution. Once this reference had been removed, all is well!

Allen

P.S. Thanks for the reply Bruce, I posted before seeing your response.