I am sorry to report that this specific problem is still unresolved and I am currently using a separate copy of the JS and CSS files directly in my web project rather than having them served by the DLL.
However, recently I discovered a solution to another unrelated issue which may be a clue. In my case IIS was upgraded as well as upgrading from Visual Studio 2005 to Visual Studio 2010 and I also changed source control from SourceSafe 2005 to Subversion, so
I had too many variables to point to a specific change. Although the problem only presents itself in IIS7, I still suspect it is a compile issue. The project and all DLLs are still being compiled in .NET 2.0. Furthermore, I am using the "Publish" function
of VS.NET 2010 to build the project.
The unrelated issue: Basically, I have a file in the App_Browsers specifying a control adapter to use. It works fine in DEV but when published it quits working. The problem only happens when using VS2010, a version of .NET prior to 4.0, and using the publish
command. Details here:
http://connect.microsoft.com/VisualStudio/feedback/details/557301/precompiled-app-browsers-dll-not-working-from-visual-studio-2010. I found another post somewhere that suggested deleting the __browserCapabilitiesCompiler.compiled file from the bin directory
and that fixed the problem for me, although this is one more step I have to do every time I deploy.
Like I said, the other issue is unrelated. However, it is proof that compiling .NET 2.0 in VS2010 is not the same as compiling .NET 2.0 in VS2005. Although it is just an untested theory, I suspect that changing the version of .NET (the DLL, the web project,
or perhaps both) to match the version of Visual Studio will also fix the issue described in this post. For example, if you are using VS2008, try changing the project version to 3.5 and if you are using VS2010, try changing it to .NET 4.0.
Keep in mind, my old DLL that was working (even in IIS7) was compiled with VS2005 and the new one (and recompile of the old code) was done under VS2010.
Please report back your findings. I would still like to find a solution to this issue and I am sure there are others who will stumble on the issue as well.
-NightOwl888
Microsoft Certified Technology Specialist
Member
1 Points
32 Posts
Re: Embedded Resource Functioning in IIS 5.1 and Failing in IIS 7
Nov 15, 2011 07:06 AM|NightOwl888|LINK
Tuborg,
I am sorry to report that this specific problem is still unresolved and I am currently using a separate copy of the JS and CSS files directly in my web project rather than having them served by the DLL.
However, recently I discovered a solution to another unrelated issue which may be a clue. In my case IIS was upgraded as well as upgrading from Visual Studio 2005 to Visual Studio 2010 and I also changed source control from SourceSafe 2005 to Subversion, so I had too many variables to point to a specific change. Although the problem only presents itself in IIS7, I still suspect it is a compile issue. The project and all DLLs are still being compiled in .NET 2.0. Furthermore, I am using the "Publish" function of VS.NET 2010 to build the project.
The unrelated issue: Basically, I have a file in the App_Browsers specifying a control adapter to use. It works fine in DEV but when published it quits working. The problem only happens when using VS2010, a version of .NET prior to 4.0, and using the publish command. Details here: http://connect.microsoft.com/VisualStudio/feedback/details/557301/precompiled-app-browsers-dll-not-working-from-visual-studio-2010. I found another post somewhere that suggested deleting the __browserCapabilitiesCompiler.compiled file from the bin directory and that fixed the problem for me, although this is one more step I have to do every time I deploy.
Like I said, the other issue is unrelated. However, it is proof that compiling .NET 2.0 in VS2010 is not the same as compiling .NET 2.0 in VS2005. Although it is just an untested theory, I suspect that changing the version of .NET (the DLL, the web project, or perhaps both) to match the version of Visual Studio will also fix the issue described in this post. For example, if you are using VS2008, try changing the project version to 3.5 and if you are using VS2010, try changing it to .NET 4.0.
Keep in mind, my old DLL that was working (even in IIS7) was compiled with VS2005 and the new one (and recompile of the old code) was done under VS2010.
Please report back your findings. I would still like to find a solution to this issue and I am sure there are others who will stumble on the issue as well.
Microsoft Certified Technology Specialist