Here is a list of challenges I encountered whilst upgrading the lovemoney.com solution to ASP.NET 4 from ASP.NET 3.5. I hope you find this an important reference or guide if you come to do the same thing:
1. Set your application pool to use .NET 4
2. Changing the browser definitions
3. Running .NET 4 application as a child under a .NET 3.5 root parent site in IIS 7
4. Targeting ASP.NET 3.5 with MSTest
5. Potentially dangerous request validation
6. MembershipUser and other System.Web.Security types have moved namespace
7. Publishing a project with missing files
This is indicating that your solution is targeting the .NET 4 framework but is still using the .NET 2 framework. To fix this you need to:
- Go to IIS
- Find the Application Pool you are using
- Right click it and select Basic Settings
- Change the target framework to .NET Framework v4 as illustrated
More info on unrecognized targetFramework attribute in ASP.NET 4
This is because the browser definitions have been updated for ASP.NET 4 from the 5 year old ASP.NET 2 browser definitions.
If you have not added to your browser definitions in any way your site should work okay but be aware that some browsers may be identified more (or maybe less) accurately. If you added to your browser definitions prior to the .NET4 upgrade (i.e. there are files in your App_Browser folder) you may recieve errors. These errors will be immediately apparent runtime errors.
If you are getting these runtime errors you can fix them in one of two ways:
- Remove the browser definitions you have in the web root's App_Browsers folder
- Copy the old browser definition files from the old location of C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers to C:\Windows\Microsoft.NET\Framework\v4.0.[whatever]\Config\Browsers (you will also need to do the same for the Framework64 version if you have one) and then run the Aspnet_regbrowsers.exe command-line tool.
More info on browser or gateway element not being found in browser definitions
This is because your web.config of your child site or application is inheriting from you parent application or site. This would happen if you have made an ASP.NET 4 application a child of an ASP.NET 2 or 3.5 site.
A (filthy) workaround for this problem would be to:
- Move the whole <configSections> section into the machine level web.config at C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\
- stop the web.config inheritance to wrap the whole configuration section in a <location inheritInChildApplications="false">
This feel very messy and personally I am not a fan of changing machine level configs, I went for upgrading the root site.
If you want more detailed info than this please feel free to bore dive into ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications - (and good luck!)
More info on duplicate section defined in a child .NET 4 application
Seriously, that is the end of this step. You just can't do it. Deal with it. This comes from Microsoft's mouth too (slightly more elegantly, I will concede). But, the fact remains: You cannot use Visual Studio 2010 AND target ASP.NET 3.5 AND use MS Test.
You will either have to exclude the Unit Test project from your solution or not use VS2010!
More info on changing the specified .NET framework version or profile for a test project
ValidateRequest="false"in the Page declaration solved this problem. In .NET4 this is not the case. Simple work around though. You simply need to stick the following code in your web.config:
<system.web> <httpRuntime requestValidationMode="2.0" /> <!-- everything else --> </system.web>
This will set the request validation back to how you are used to. However, why not use this opportunity to solve this potential security properly? Or maybe use a <location inheritInChildApplications="false"> to wrap this code so that it is only relevant to the specific page that needs it?
More info on potentially dangerous request in ASP.NET 4 upgrade
To fix this you just need to add a reference to the erroring project(s).
- Right click the References folder
- Click Add Reference...
- Under the .NET tab find and select System.Web.ApplicationServices
You may now need to resolve the references to MembershipUser (or other types) but you should be good to go.
More info on Membership provider not being found in System.Web.Security
You will have to go about your solution excluding all of these dud references. One by one too! Publish then exclude, publish, exclude, publish, exclude etc. until it published okay and stops complaining.
Summary and more...This is a list of the complications I encountered during the upgrade process and how to solve each one. There are other complications too that I didn't personally encounter which you can read a white paper on ASP.NET 4 breaking changes from Microsoft themselves.
Hope this helps - if it did please link to this guide.