The .NET Framework (including ASP.NET) strives to maintain near-100% compatibility when an existing framework is updated on a machine. We try to ensure as much as possible that if an application was developed and deployed against .NET Framework 4, it will just continue to work on 4.5. This normally means keeping quirky, buggy, or undesirable behaviors in the product between versions, as fixing them may negatively affect applications which were relying on those behaviors.<\/p>\n
Consider creating a new Console Application project targeting .NET Framework 4 and putting the following in Program.cs:<\/p>\n
Program\r\n{\r\n static void Main(string[] args)\r\n {\r\n List < int > list = new List < int >() { 1, 2, 3 };\r\n list.ForEach(i =>\r\n {\r\n Console.WriteLine(i);\r\n if (i < 3) { list.Add(i + 1); }\r\n });\r\n }\r\n}<\/pre>\nWhen run, the output of this application is 1, 2, 3, 2, 3, 3<\/strong>. Now change the project to target .NET Framework 4.5, recompile, and run again. The output is 1<\/strong>, followed by an exception: System.InvalidOperationException: Collection was modified; enumeration operation may not execute.<\/em> What happened?<\/p>\nThe contract of IEnumerator.MoveNext()<\/a> specifies that the method shall throw an InvalidOperationException if the underlying collection changes while an enumeration is currently taking place. Indeed, if you use the foreach<\/a><\/em> keyword instead of the List<T>.ForEach()<\/a> method in the above sample, you will see the exception thrown regardless of target framework. This discrepancy between the foreach<\/em> keyword and the ForEach() method is one example of a quirk. The feature team wanted to bring the ForEach() method behavior in line with the foreach keyword behavior, but doing so for all applications would have been a breaking change. So they require the application to opt in to the new 4.5 behavior by switching the target framework.<\/p>\nGiven that the .NET Framework 4.5 is an in-place update to .NET Framework 4, how is this pulled off? If you look closely at the console application project, you’ll see that it also contains one additional file App.config<\/em>:<\/p>\n<configuration >\r\n < startup > \r\n < supportedRuntime version = \"v4.0\" sku<\/span>=<\/span>\"<\/span>.NETFramework,Version=v4.0<\/span>\"<\/span>\/>\r\n <\/<\/span>startup>\r\n<\/<\/span>configuration><\/span><\/pre>\nWhen the application is targeted to 4.5, Visual Studio modifies the configuration file. There are two related concepts in the <supportedRuntime><\/a> element: runtime version and target SKU. The .NET Framework 4.5 SKU rides on top of version 4.0 of the CLR, much like how the .NET Framework 3.0 and 3.5 SKUs ride on top of version 2.0 of the CLR.<\/p>\n<<\/span>configuration>\r\n <<\/span>startup> \r\n <<\/span>supportedRuntime version<\/span>=<\/span>\"<\/span>v4.0<\/span>\" <\/span>sku<\/span>=<\/span>\"<\/span>.NETFramework,Version=v4.5<\/span>\"<\/span>\/>\r\n <\/<\/span>startup>\r\n<\/<\/span>configuration><\/span><\/pre>\nThis information is captured into an attribute and compiled into the executable:<\/p>\n
[<\/span>assembly<\/span>: <\/span>TargetFramework(<\/span>\".NETFramework,Version=v4.5\", FrameworkDisplayName = <\/span>\".NET Framework 4.5\")]<\/span><\/pre>\nWhen a component in the .NET Framework needs to decide whether to apply quirks behavior to a particular code path or whether it should use new 4.5-standards logic, it consults the [TargetFramework] attribute<\/a> to see what framework version the application targets, hence what logic it expects to take place. (If the attribute is not present, the runtime assumes 4.0 quirks behavior. There is additional fallback and resolution logic, but it’s not important to the topic at hand.)<\/p>\n<httpRuntime targetFramework><\/h3>\n
But what if ASP.NET applications want to opt in to the new 4.5 behaviors? ASP.NET developers can’t use the <supportedRuntime> element since there’s no .exe the [TargetFramework] attribute can be compiled into. However, we do control the <httpRuntime> element, and we can use its values to make decisions on how we should configure the CLR before loading your application into memory.<\/p>\n
To this effect, we introduced the targetFramework attribute<\/a><\/em> on the <httpRuntime> element. When you create a new ASP.NET application using the 4.5 project templates, the following line will be present in Web.config:<\/p>\n<<\/span>httpRuntime targetFramework<\/span>=<\/span>\"<\/span>4.5<\/span>\" <\/span>\/><\/span><\/pre>\nThe effect of this attribute is twofold. First, it controls the CLR’s quirks mode behavior, just like the <supportedRuntime> element does in a console application. Consider a handler ~\/MyHandler.ashx<\/em> whose contents are similar to the console application above.<\/p>\n<%<\/span>@ <\/span>WebHandler <\/span>Language<\/span>=\"C#\" <\/span>Class<\/span>=\"MyHandler\" <\/span>%>\r\n\r\n<\/span>using <\/span>System.Collections.Generic;\r\n<\/span>using <\/span>System.Web;\r\n<\/span>public class <\/span>MyHandler : <\/span>IHttpHandler\r\n{\r\n\r\n <\/span>public void <\/span>ProcessRequest(<\/span>HttpContext context)\r\n {\r\n context.Response.ContentType = <\/span>\"text\/plain\";\r\n <\/span>List<<\/span>int<\/span>> list = <\/span>new <\/span>List<<\/span>int<\/span>>() { 1, 2, 3 };\r\n list.ForEach(i =>\r\n {\r\n context.Response.Write(i + <\/span>\" \");\r\n <\/span>if <\/span>(i < 3) { list.Add(i + 1); }\r\n });\r\n }\r\n\r\n <\/span>public bool <\/span>IsReusable\r\n {\r\n <\/span>get <\/span>{ <\/span>return false<\/span>; }\r\n }\r\n}\r\n<\/span><\/pre>\nIf the targetFramework<\/em> attribute reads “4.0”, the output will be 1 2 3 2 3 3<\/strong>. If the targetFramework<\/em> attribute reads “4.5”, an InvalidOperationException will be thrown due to the collection having been modified during the ForEach() operation.<\/p>\nSecond, <httpRuntime targetFramework=”4.5″ \/> is a shortcut that allows the ASP.NET runtime to infer a wide array of configuration settings. If the runtime sees this setting, it will expand it out just as if you had written the following:<\/p>\n
<<\/span>configuration>\r\n <<\/span>appSettings>\r\n <<\/span>add key<\/span>=<\/span>\"<\/span>aspnet:UseTaskFriendlySynchronizationContext<\/span>\" <\/span>value<\/span>=<\/span>\"<\/span>true<\/span>\" <\/span>\/>\r\n <<\/span>add key<\/span>=<\/span>\"<\/span>ValidationSettings:UnobtrusiveValidationMode<\/span>\" <\/span>value<\/span>=<\/span>\"<\/span>WebForms<\/span>\" <\/span>\/>\r\n <\/<\/span>appSettings>\r\n <<\/span>system.web>\r\n <<\/span>compilation targetFramework<\/span>=<\/span>\"<\/span>4.5<\/span>\" <\/span>\/>\r\n <<\/span>machineKey compatibilityMode<\/span>=<\/span>\"<\/span>Framework45<\/span>\" <\/span>\/>\r\n <<\/span>pages controlRenderingCompatibilityVersion<\/span>=<\/span>\"<\/span>4.5<\/span>\" <\/span>\/>\r\n <\/<\/span>system.web>\r\n<\/<\/span>configuration><\/span><\/pre>\nBy inferring all of these settings from a single line, we help shrink the size of Web.config. Thus the file contains less runtime configuration and more application-specific configuration, such as connection strings.<\/p>\n
I’ll go over each of these in turn, explaining what they do.<\/p>\n
<add key=”aspnet:UseTaskFriendlySynchronizationContext” value=”true” \/><\/h4>\n
Enables the new await<\/em>-friendly asynchronous pipeline that was introduced in 4.5. Many of our synchronization primitives in earlier versions of ASP.NET had bad behaviors, such as taking locks on public objects or violating API contracts. In fact, ASP.NET 4’s implementation of SynchronizationContext.Post<\/a> is a blocking synchronous call! The new asynchronous pipeline strives to be more efficient while also following the expected contracts for its APIs. The new pipeline also performs a small amount of error checking on behalf of the developer, such as detecting unanticipated calls to async void<\/em> methods.<\/p>\nCertain features like WebSockets require that this switch be set. Importantly, the behavior of async<\/em> \/ await<\/em> is undefined in ASP.NET unless this switch has been set. (Remember: setting <httpRuntime targetFramework=”4.5″ \/> is also sufficient.)<\/p>\n<add key=”ValidationSettings:UnobtrusiveValidationMode” value=”WebForms” \/><\/h4>\n
Causes server controls to render data-val<\/em> attributes in markup rather than send a snippet of JavaScript for each input element which requires validation. This provides a better extensibility story for customizing how client-side validation is performed. Depending on the complexity of the page, it can also significantly reduce the size of the generated markup.<\/p>\n<compilation targetFramework=”4.5″ \/><\/h4>\n
Selects which version of the .NET Framework’s reference assemblies are used when performing compilation. (Note: Visual Studio requires that this element be present in Web.config, even though we auto-infer it.)<\/p>\n
<machineKey compatibilityMode=”Framework45″ \/><\/h4>\n
Causes ASP.NET to use an enhanced pipeline when performing cryptographic operations. More information on the new pipeline can be found here<\/a> (links to the first part of a three-part blog series).<\/p>\n<pages controlRenderingCompatibilityVersion=”4.5″ \/><\/h4>\n
Similar to quirks mode, but instead of affecting core runtime behavior it affects how controls render markup. For example, consider the control <img runat=\"server\" src=\"...\" alt=\"\" \/><\/tt> (note the empty alt tag). In earlier versions of ASP.NET, this stripped the empty alt tag and output <img src=\"...\" \/><\/tt>, which fails HTML validation. When the rendering compatibility version is set to “4.5”, the empty alt tag is preserved, and the output is <img src=\"...\" alt=\"\" \/><\/tt>.<\/p>\n
<pages controlRenderingCompatibilityVersion> defines the default value of the Control.RenderingCompatibility<\/a> property. The value can still be overridden on a per-control basis if desired.<\/p>\nMiscellaneous questions<\/h3>\nCan I detect the target framework programmatically?<\/h4>\n