Phew, that title sure is a mouthful… but it is kinda hard to describe the problem in so few words.
I had just finished the primary work on a new customer’s website (http://www.BuyMyBatteries.com) and was trying to hook up the latest and greatest build of BlogEngine.Net (2.5) underneath it for the corporate blog.
The challenge, as you might have guessed is that while BE.NET requires Asp.Net 4.0, the server was running IIS 6.0 and more importantly, the parent website is running ASP.NET v2.0. Resolving this took a number steps but it appears to be working quite nicely now
Step 1
Install the application and ensure that file permissions are correct. This is a no-brainer but is an oft-overlooked step; especially if you do installs of this program regularly.
Step 2
Set the folder containing the application (in this case BlogEngine.Net) as an application and ensure that it is running in a DIFFERENT application pool than the parent’s app pool. I’ve found it to be safest to have unique app pools for every site as well as for every application but you should at minimum have a different app pool for each version of Asp.Net that you are running. The Identity of the app pool can be what ever you want but in most cases it makes sense to be Network Services in order fall in line with most install instructions.
Step 3
This is where I really had a head scratcher. When going to the application, I continued to get 404 errors even though I was certain that I had the file permissions set up correctly. As it turns out, with IIS6, just ‘cause you have Asp.Net 4.0 installed doesn’t mean it has permissions to run under the web server. If found a great solution to this in Johan Dreissen’s blog. He pointed out why this wasn’t working and more importantly, provides the command prompt to get the 4.0 version of aspnet_isapi.dll working:
cscript iisext.vbs /EnFile C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll
Note that you’ll find the iisext.vbs script in %SYSTEMROOT%\system32.
Step 4
There is a known breaking change in Asp.Net 4.0 that, by default, prevents 4.0 apps from running as children under 2.0 or 3.5. This whitepaper on asp.net site was crucial in resolving the final mystery. By wrapping the <appSettings />, <connectionStrings /> <system.web /> <system.webServer /> and <system.codedom /> sections of the PARENT web.config file in a <location> tag, you can eliminate the compilation of the earlier version of ASP.NET from trickling down to the 4.0 application. Mine looked like this:
<?xml version="1.0"?> <configuration> <configSections> ... </configSections> <location path="signin.aspx">...</location> <location path="lostpassword.aspx">...</location> <location path="" inheritInChildApplications="false" > <!-- Note above Location Wrapper has been added to enable .Net 4.0 app (BlogEngine.net) to run as a subweb under this app --> <appSettings> ... </appSettings> <system.web> ... </system.web> <system.webServer> ... </system.webServer> <system.codedom> ... </system.codedom> </location> <runtime> ... </runtime> </configuration>
So, after taking the steps above, I’ve been able to run BlogEngine.Net v2.5 (an Asp.Net 4.0 application) successfully under AspDotNetStorefront v9.2.0.0 (an Asp.Net v3.5 application) as the parent application.
Have you encountered a similar problem? What was your solution? Use the comments below to share this with the rest of the class!
- Setting up SSL on Amazon Linux Instance under EC2 - July 26, 2018
- Method Chaining of Objects in C# - January 16, 2017
- Native SQL Backup And Restores on AWS RDS - November 9, 2016