Herein lies the problem: this is exactly what I did so I could get this released. There is no issue with the URLs, they are being generated and output - it is just that the resources are not being served (via WebResource.axd), at least not to the same URL that is being output. The thing is - I am using a constant to ensure that there is no way they can be different.

I tried physically moving the files to the root directory (they are in subfolders named CSS and JavaScript). I realize that the subfolders need to be included in the name but only when using C# - in VB these are left off. I also tried renaming the files (removing the extra periods) because they are named Styles.min.css and Script.min.js, but that didn't help either.

I also used the following method (and downloadable page) to verify whether the URL was being encrypted correctly - and it is exactly the same between DEV and TEST. http://blogs.telerik.com/blogs/posts/07-03-26/debugging_asp_net_2_0_web_resources_decrypting_the_url_and_getting_the_resource_name.aspx

What I don't understand is why they would serve up on Windows XP Pro, but not on Windows 2008 Server R2 (x64). I also can't seem to pin down why this DLL that has been working fine in production for several months all of a sudden won't serve the resources. Note that there is a javascript file as well as a CSS file and neither works even though all of the other resources (via 3rd party and MS DLLs) on the page work. The old DLL works fine in all environments, but if I compile the exact same code that was used to make the working DLL I get a new DLL that fails, but only in the IIS7/64 bit environment.

I ended up building a virtual machine with the same verion of Windows 2008 to try to track down some other bugs. I will try using it to compile the old code to see if I can make a DLL that will serve the resources in that environment. That should be able to give some more information on whether the windows updates really did hose my DEV environment somehow.