First up we have the battle of the bits. Upon deploying my .Net 3.5 site over to the new server I immediately starting seeing this error (click the image for full size view).
The error reads "Could not load file or assembly 'System.Data' or one of its dependencies. An attempt was made to load a program with an incorrect format". A mention of System.BadImageFormatException is down in the Exception Details too, another red herring.
System.Data, WTF? How can a grassroots part of .NET be broken? Well, after a bit of Googling I'd found a few people suggesting I should set the server to run everything as 32 bit. Sure, but what about the other websites running on this machine and why bother with a 64 bit server in the first place? Plus, I was doing my builds on my Vista 64 dev machine, surely it's all 64 bit.
After building and rebuilding with various target CPU settings to no avail I stumbled upon this setting in the Application Pool in IIS that my website was running in. Oh, look... it says "Enable 32-Bit Applications".
Set it to True and watch the magic happen. So apparently, even though I'm running Vista 64 my .NET DLLs are 32 bit... or something like that. Anyway, that was the first hurdle.
The second problem was I couldn't get access to the site either through anonymous access or via the Forms Authentication. At first I thought it was my custom MembershipProvider but that didn't explain why the authentication errors were from the SQL side of things.
More poking and prodding later (and a weekend of beer drinking) I came to the realisation that my LINQ to SQL entities were using the connection string name in the app.config, not the name of the connection string I had in my web.config. *slaps forehead*
So a quick rename of the connection string on the remote server's web.config and we're back in business... *phew*
Well, that's it... I hope the whale video was entertaining for you.
No comments:
Post a Comment