tags:

views:

142

answers:

3

I have a super basic form that shoots out an email. The code is contained within a virtual directory like http://url/emailer/emailer.aspx on a new server and is working fine.

We are in the process of migrating a few additional sites over to this new server. To test, I'm accessing the files via the ip address so I can see the site on the new server like http://ip/url/emailer/emailer.aspx.

For some reason, whenever I access the aspx page via the IP URL, I receive the "could not load the assembly...make sure that it is compiled before accessing the page" error. However, I've confirmed when pulled into the live site, it works fine.

Why does referencing the IP URL cause this exception?

+1  A: 

Is it setup correctly in IIS? If it's not set as an application in the same way as the original server then it will be looking for the bin directory in a different location. For example, if you have /myapp as a directory, but not an application it will look in /bin, but if you change it to an application it will look for it in /myapp/bin.

The only other time I've seen this is when the same app pool is specified for 2 different apps, each set to run a different version of the framework. It doesn't sound like this is your problem, but it might be worth checking the app pool identities in case there's something else that's listening on the ip that might be using a different framework version.

Steven Robbins
Yes, everything is setup properly in regards to IIS. In fact, I can take the live URL on the new server and replace w/ the IP URL and it won't work.
Ryan Strauss
And the ip is pointing to exactly the same IIS site? The way you describe one as http://url/ and the other as http://ip/url/ sounds.. odd?
Steven Robbins
Yeah, I should have probably been more clear. I have the folder structure setup like C:\Inetpub\wwwroot\myurl1.com and C:\Inetpub\wwwroot\myurl2.com. So when I go to http://myrurl1.com it points to C:\Inetpub\wwwroot\myurl1.com. Same with http://ip/myrurl1.com.
Ryan Strauss
That implies that they are two separate IIS sites then? One being your "default" site that hits wwwroot, the other a host headered version? If so it sounds like an app pool issue as per my edit above, or the framework version is set wrong on the default site.
Steven Robbins
Yes, I guess you are right. I've confirmed the Default Web Site is set to the 2.0 framework. I've also run aspnet_regiis.exe -i in the 2.0 framework to reset everything. However, everything is set to the same app pool. Is that the issue?
Ryan Strauss
Well if there's anything been run in that app pool that wasn't the same version, even if it was only run a while ago, then trying to load a 2.0 page will give you that error. Try making each subdir it's own app with it's own app pool and see if that helps.
Steven Robbins
Steve, you've helped me figure it out. The emailer folder under the Default Web Site was not set as an application. So that is why going to the URL worked and IP URL didn't. It makes complete sense and I'm officially an idiot. Thanks!
Ryan Strauss
No worries, glad you got it sorted :-)
Steven Robbins
A: 

This could be an IIS issue. Sometimes IIS is setup so that the IP address itself is pointing to another site since you have multiple web sites/applications all on the same server and some are picky about what the URL is for proper resolution.

Can you check the IIS settings for the application and see if the IP address is mapped to your site?

Dillie-O
Yes, I've confirmed the IP is mapped to my site. To confirm, I created a new html page on the live site and was able to see in both the http://url/email/a.htm and http://ip/url/email/a.htm URLs. It's something related to .Net somehow.
Ryan Strauss
A: 

I have run into this problem sometimes when the server I am on is running low on disk space. The site attempts to load the referenced DLL, doesn't have enough free space to do so, and then throws this error.

Just something to check. This happened to me with a partitioned drive where the C:\ drive was basically filled up by Windows Updates and even though the sites were on the D:\ drive, there wasn't enough space left on C:\ for IIS to load the assemblies.

Jay S
That's a good thought however we have 136 GB left so space is not an issue.
Ryan Strauss