Recently, I finished upgrading my ASP.NET MVC 4 application(in Visual Studio 2012) from .NET 4.0 to .NET 4.5 framework. Not-so-easy job though. A lot of pain and anxiety is involved when you migrate to a different target framework version and when you know that you have a lot of Nuget package references and use a couple of third-party components that interface with a specific version of .NET framework. So, i thought of sharing my experiences and challenges during this process.

The easiest way to target all projects to .NET 4.5 framework is by doing a search for all *.csproj files and replace <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>  with <TargetFrameworkVersion>v4.5</TargetFrameworkVersion> (or client profile, etc). You would also need to replace the <compilation> element's targetFramework=”4.0″ with 4.5 in the application's web.config file.

Issues after migrating ASP.NET MVC solution from .NET 4.0 to .NET 4.5:

=========================================================================================================

1. The real issue are the NuGet packages, they will just not work, – some have a .NET 4.5 specific version – a good example is Entity Framework. When the project is targeting version 4.0 of the framework and you install/update EF to version 5 you actually end up with EF 4.4 (which doesn't have support for enum types and so on, targeted for .NET 4.5). When i looked at my project reference, I found the following entry:

                      <Reference Include="EntityFramework, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
                        <SpecificVersion>False</SpecificVersion>
                       <HintPath>..\packages\EntityFramework.5.0.0\lib\net40\EntityFramework.dll</HintPath>
                    </Reference>

       The only way to solve this is to remove all packages and install them again, which is a massive pain to do manually and unfortunately the current version of NuGet is not of much help there either.

       Open Visual Studio 2012,

     Go to “Tools” > “Library Package Manager” > “Package Manager Console”. This will open a powershell command prompt,

     then type: uninstall-package EntityFramework for each of the listed projects for the default project dropdown.

       After uninstalling EntityFramework from each of the projects, install EntityFramework by typing “install-package EntityFramework” in the powershell command-prompt.

       NuGet 2.0 doesn't handle re-targeting your applications very well. In order to change your packages' target frameworks, you must uninstall and reinstall the packages.

      The reasons why packages must be uninstalled and re-installed are:

• When installing a package, we determine the target framework of your project
• We then match that up with the package contents, finding the appropriate \lib\ folder (and \content\ folder)
• Assembly references are added with Hint Paths that point to the package's \lib\ folder, with the right subfolder (\lib\net40 for example)
• Content files are copied from the packages \content\ folder, with the right subfolder (\content\net40 for example)
• We record the targetFramework used to install the package within the packages.config file
• After you change your project's target framework, the Hint Paths still point to net40
• When you uninstall packages, we check the targetFramework that was recorded in packages.config to see what target framework's libs/content to remove from your project
• When you reinstall the package, we detect your updated target framework and reference/copy the right libs/content

2. ELMAH and Ninject work like a charm without any changes. That's a good news. 

3. Make sure you take a look into this one about the new Date and DateTime editor templates in MVC 4. Also there seem to be model binding changes to do with DateTime . 

4. Lastly, don’t forget to update your test assemblies App.config with the correct assembly redirects if you are running tests against ASP.NET MVC controllers, which use MvcFutures or MvcContrib, because you will end up seeing weird “Type A doesn’t match type A” errors.

Symptoms:

===============================================================================================

Unable to start FTP, WWW, WAS services. Unable to expand server node in the IIS manager.

-------------------------

Failed to connect

-------------------------

There was an error when trying to connect. Do you want to retype your credentials and try again?

Details: Filename:\\?\C:\Windows\Microsoft.Net\Framework64\v2.0.50727\CONFIG\machine.config

Error:

Cause:

===============================================================================================

Ran 'appcmd list sites' command from an elevated prompt.

ERROR ( message: Configuration error

Filename: \\?\C:\Windows\system32\inetsrv\config\redirection.config

Line Number: 13

Description: Cannot log on locally to \\somesharedpath\\sharedfolder  as user DOMAIN\Username with redirection.config password

. )

This error occurs when the password stored for the shared configuration is not correct.

Resolution:

================================

Opened the file redirection.config from C:\windows\system32\inetsrv\config

You will see a node like:

<configurationRedirection enabled=”true” path=”<path to shared config>” userName=”username″ password=”[enc:IISRsaProvider:57686f6120447564652c2049495320526f636b73:enc]” />

This node enables the shared configuration with the credentials to use.

Now, you have two choices,

Choice 1: You do not have a requirement to use shared configuration. To disable sharedconfiguration,change the node from:

<configurationRedirection enabled=”true” path=”<path to shared config>” userName=”username″ password=”[enc:IISRsaProvider:57686f6120447564652c2049495320526f636b73:enc]” />

to

<configurationRedirection/>

After making the change, the configuration will look like

 
<configuration>

            <configSections>
                         <section name=”configurationRedirection” />
           </configSections>

<configProtectedData>
           <providers>
                         <add name=”IISRsaProvider” type=”" description=”Uses RsaCryptoServiceProvider to encrypt and decrypt” keyContainerName=”iisConfigurationKey” cspProviderName=”" useMachineContainer=”true”  useOAEP=”false” />
           </providers>
</configProtectedData>

<configurationRedirection />

</configuration>

Restart IIS.

Choice 2: You require shared configuration on your web server. In this case, the easiest way to resolve it is to follow the choice 1(above) and setup the shared configuration from the article:

http://learn.iis.net/page.aspx/264/shared-configuration/ using the the user account with the correct set of username and passowrd information.

Restart IIS.

Besides hurting your application's performance in production house, it turns website lifecycle into a vicious circle.

Here is my understanding of using <compilation debug="true" /> on your application's web.config file:

When <compilation debug=”true” /> is switched on within the application’s web.config file, it causes a number of non-optimal things to happen including:

1) You will see a lot more files in Temporary ASP.NET files folder when you use debug=true.

2) Your pages will not timeout when you have debug=“true” which is no an ideal production scenario.

3) Batch compilation will be disabled even if the batch attribute is true in the <compilation> element.

4) The System.Diagnostics.DebuggableAttribute gets added to all generated code which causes performance degradation. Basically, when you have debug=true, the DebuggableAttribute gets added to all generated code.

5) All client-javascript libraries and static images that are deployed via WebResources.axd will be continually downloaded by clients on each page view request and not cached locally within the browser.  This can slow down the user experience quite a bit for things like Atlas, controls like TreeView/Menu/Validators, and any other third-party control or custom code that deploys client resources.  Note that the reason why these resources are not cached when debug is set to true is so that developers don’t have to continually flush their browser cache and restart it every-time they make a change to a resource handler (our assumption is that when you have debug=true set you are in active development on your site).

6) When <compilation debug=”false”/> is set, the WebResource.axd handler will automatically set a long cache policy on resources retrieved via it – so that the resource is only downloaded once to the client and cached there forever (it will also be cached on any intermediate proxy servers).  If you have Atlas installed for your application, it will also automatically compress the content from the WebResources.axd handler for you when <compilation debug=”false”/> is set – reducing the size of any client-script javascript library or static resource for you (and not requiring you to write any custom code or configure anything within IIS to get it).

7) When the debug attribute in the Web.config file is set to true, it generates symbolic information(.pdb information) every time the compiler compiles your .aspx pages as well as disables code optimization. If the application is not being debugged, you should change this attribute to false.

While the debugger is attached and in break mode, no requests to pages in the application execute. Therefore, you should not debug an application on a production Web server while it is in use.

Only one debugger can be attached to the Aspnet_wp.exe process at a time.

The CLR Debugger only debugs managed code, and it only debugs applications on the computer on which the CLR Debugger is running. If you need to debug remotely or if you need to debug code other than managed code, you should use the Visual Studio .NET debugger.

Please refer:http://support.microsoft.com/kb/301058

Now, let's see how can you turn OFF this flag at the server level ?

As obvious as this, please use the following configuration feature on the machine.config file:

<configuration>
    <system.web>
          <deployment retail=”true”/>
    </system.web>
</configuration>
 
You will disable the <compilation debug=”true”/> switch and this will disable the ability to trace output in a page, and turn off the ability to show detailed error messages remotely. Note that these last two items are security best practices you really want to follow (otherwise hackers can learn a lot more about the internals of your application than you should show them).
For more information on this, please refer: http://msdn.microsoft.com/en-US/library/ms228298(VS.80).aspx

And, now let us see in what scenario you might want to turn on Debug=True:

ASP.NET supports compiling applications in a special debug mode that facilitates developer troubleshooting. Debug mode causes ASP.NET to compile applications with extra information that enables a debugger to closely monitor and control the execution of an application. Applications that are compiled in debug mode execute as expected. However, the performance of the application is affected.
To avoid the effect on performance, it is a good idea to enable debugging only when a developer is doing interactive troubleshooting. By default, debugging is disabled, and although debugging is frequently enabled to troubleshoot a problem, it is also frequently not disabled again after the problem is resolved. So, the best option would be to turn debug=“true,” fix your problem and turn debug=“false” back again.

Please refer following article:
http://support.microsoft.com/kb/815157

Because many parts of an ASP.NET application (such as .aspx, .asmx and .ascx pages) are dynamically compiled at run-time, you need to configure the ASP.NET run-time process to compile the application with symbolic information before the application can be debugged. To do this, set the debug attribute in the configuration section of the Web.config file that is located in the root of the application folder to true, as follows:

<configuration>
    <compile debug=true/>
</configuration>

Alternatively, you can set the Debug attribute of the Page directive to true in your .aspx pages, as follows:

<%@ Page Debug="true" %>

Let's do a small exercise to illustrate why do we really need to set debug=true in your application's configuration.

Add the following code snippet in Page_Load method of Default.aspx of your sample web application. This code will cause a divide-by-zero(as expected) error message whenever you request the page.

Code Snippet:

protected void Page_Load(Object sender, EventArgs e)
(
     int32 i = 0;
     i = i/0;
)

Check the output if you have debug="false" (first) and the same page with debug="true" (second) in Code above.

Output when debug="false" 
 [OverflowException: Arithmetic operation resulted in an overflow.]
   _Default.Page_Load(Object sender, EventArgs e) +18
   System.Web.UI.Control.OnLoad(EventArgs e) +99
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061
 Output when debug="true"
 
 
 [OverflowException: Arithmetic operation resulted in an overflow.]
   _Default.Page_Load(Object sender, EventArgs e) in C:\My Documents\Visual Studio 2010\WebSites\DebugTrue\Default.aspx.vb:8
   System.Web.UI.Control.OnLoad(EventArgs e) +99
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061

Notice that with debug=“true”, you get a more detailed stack output and it even tells you that the problem happened on line number 8 in a page located at C:\My Documents\Visual Studio 2010 Websites\DebugTrue\Default.aspx.vb:8.

If you are a debugger freak and have some knoweldge about WinDbg dump analysis, you should agree with me in my following notes:

To find out if any of the applications on your server run with debug=true you can run a nifty command in sos.dll called !finddebugtrue which will list out all applications where debug=true in the web.config
  
0:016> !finddebugtrue
 
Debug set to true for Runtime: 61b48dc, AppDomain: /SampleApplication
 
Debug set to true for Runtime: 1f50e6d8, AppDomain: /MemoryIssues
 
Total 16 HttpRuntime objects
  
And to find out if you forgot to compile some of your assemblies in release mode run !finddebugmodules
 
0:016> !finddebugmodules
 
Loading all modules.
 
Searching for modules built in debug mode...

SampleApplication.dll built debug
 
MemoryIssues.dll built debug
 
fl4sq-9i.dll built debug
 
wepr1t3k.dll built debug
 
r9ocxl4m.dll built debug
 
zmaozzfb.dll built debug

Done Seaching
 
 
The dlls above with weird 8 character names are the dlls generate when JITing the aspx pages, so they will go away when debug=false.

ScottGu has written an excellent blog on this issue, have a look at the below blog from him:

http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx

Have a happy read and share your thoughts.

Let me know if you have any questions and issues on this, I will be happy to answer them.

Uploading files via the FileUpload control gets tricky with big files. The default maximum filesize is 4MB - this is done to prevent denial of service attacks in which an attacker submitted one or more huge files which overwhelmed server resources. If a user uploads a file larger than 4MB, they'll get an error message: "Maximum request length exceeded."

Here is what needs to be considered for larger file uploads:

You can upload files with a combined size of up to 2GB, but it requires some modifications in your application configuration files.

Web.config settings:

The following attributes can be assigned to the <httpRuntime> tag in the <system.web> section of the Web.config file.

1. maxRequestLength : Specifies the limit for the input stream buffering threshold, in KB. This limit can be used to prevent denial of service attacks that are caused, for example, by users posting large files to the server. The default value is 4096 (4 MB). To enable large file uploads you need to change the value of this attribute to the largest allowed combined file size for your application. If someone selects and uploads files with total size larger than maxRequestLength, this will result in a "Page not found" error (which is the default error of the Framework).

2. executionTimeout : Specifies the maximum number of seconds that a request is allowed to execute before being automatically shut down by ASP.NET. The value of this setting is ignored in debug mode. The default in .NET Framework 2.0 is 110 seconds. In the .NET Framework 1.0 and 1.1, the default is 90 seconds.

To enable large file uploads, which can take large periods of time, increase the value of this property(executionTimeout).
 
For example: The configuration, allowing uploads of files up to 100MB and upload periods up to 1 hour, should look like the following:

<configuration>

...

<system. web>

<httpRuntime maxRequestLength="102400" executionTimeout="3600" />

...

</system .web>

</configuration>

IIS7 Settings:

You need to add the following lines in the web.config file:

<system.webServer>

...

<security >

<requestFiltering>

<requestLimits maxAllowedContentLength="1024000000" />

</requestFiltering>

</security>

</system.webServer>

Open the applicationHost.config(C:\Windows\System32\inetsrv\Configs) file and set the overrideModeDefault property to Allow for the section name = requestFiltering. So now the line should look like:

<section name="requestFiltering" overrideModeDefault="Allow" />

To know more about requestLimits, please refer: http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering/requestLimits

Machine.config settings:

The following attributes can be assigned in the <processModel> element of the machine.config file. They must be set at the machine level, not the application level in web.config. 

These properties affect any response deadlock in ASP.NET, not just the application that uploads large files, and should be used with caution.

responseDeadlockInterval

Specifies the time interval, in the format HH:MM:SS, after which the process is restarted if the following conditions are met:

* There are queued requests.

* There has not been a response during this interval. The default is 3 minutes. To allow very large uploads, you may have to increase this value.

responseRestartDeadlockInterval

Specifies the time, in the format HH:MM:SS, that must elapse after the last restart to cure a deadlock before the process is restarted to cure a deadlock again. This prevents thrashing on processes that require a relatively long startup time. The default is 9 minutes. To allow very large uploads, you may have to increase this value.

IIS Metabase Settings:

There is one property on IIS 6.0 metabase called AspMaxRequestEntityAllowed to allow larger file uploads.

The AspMaxRequestEntityAllowed property specifies the maximum number of bytes allowed in the entity body of an ASP request. If a Content-Length header is present and specifies an amount of data greater than the value of AspMaxRequestEntityAllowed, IIS returns a 403 error response. This property is related in function to MaxRequestEntityAllowed, but is specific to ASP request. Whereas you might set the MaxRequestEntityAllowed property to 1 MB at the general World Wide Web Publishing Service (WWW Service) level, you may choose to set AspMaxRequestEntityAllowed to a lower value, if you know that your specific ASP applications handle a smaller amount of data.

I had one such case in my recent past where the customer was getting "HTTP 404: Page Not Found" error when uploading large files on Windows Server 2003 machine.

The exact issue was: Sometimes the upload of large files on a Windows 2003 server does not succeed even though the maxRequestLength configuration property is set to a very large value. The browser displays
"Page Not Found" error.

Resolution that worked in my case: Set the IIS Metabase property AspMaxRequestEntityAllowed to 200000000
(~200MB)

Now, let’s talk about some scenarios where we get such stuffs:

Error message when you visit a Web site that is hosted on a server that is running Internet Information Services 7.0: "HTTP Error 404.13 - CONTENT_LENGTH_TOO_LARGE"

Consider the following scenario. You have a Web site that is hosted on a server that is running Internet Information Services (IIS) 7.0. When a user visits this Web site, the user receives an error message that resembles the following error message:

Server Error in Application "application name"

HTTP Error 404.13 - CONTENT_LENGTH_TOO_LARGE

HRESULT: 0

Description of HRESULT # The operation completed successfully

This problem occurs because the client request contains a Content-Length header that is larger than the value that is specified for this header in the maxAllowedContentLength property in the ApplicationHost.config file.

To resolve this problem, follow these steps:

1. Click Start. In the Start Search box, type Notepad.
   Right-click Notepad, and then click Run as administrator.
   
   Note If you are prompted for an administrator password or for a confirmation,
   type the password, or click Continue.
2. On the File menu, click Open. In the File name box,
   type %windir%\system32\inetsrv\config\applicationhost.config, and then click
   Open.
3. In the ApplicationHost.config file, locate the
   <requestLimits> node.
4. Remove the maxAllowedContentLength property. Or, add a
   value that matches the size of the Content-Length header that the client sends
   as part of the request. By default, the value of the maxAllowedContentLength
   property is 30000000.
   
   For example, modify the following configuration data inside the
   <requestFiltering> section.

           <requestLimits maxAllowedContentLength = "<length>" />

1. Save the ApplicationHost.config file.

Courtsey: http://support.microsoft.com/kb/942074

You can get some scenarios in the below article, please refer this;

http://forums.iis.net/t/1066272.aspx