FxCop and ASP.NET

In general, using FxCop with ASP.NET applications is no different than using it with any other kind of application. You build your application and run FxCop on the generated assemblies. However, it is worth observing that FxCop can analyze code and resources only that are in an assembly. This means that if you have used the SRC attribute in your page directives, the resulting assembly will not contain your code and FxCop will be unable to analyze it. In addition, in case you needed any further justification for separating your code from your user interface, it should be obvious that any code you have in script tags in aspx files will not be included in the assembly built by Visual Studio. The solution is to move such code into a codebehind file.

Another issue for you to consider is how much of your application you want FxCop to analyze. Your aspx files make up a considerable part of your application, but these files are not compiled into the assembly built by Visual Studio (and, therefore, they are not analyzed by FxCop). These files are typically compiled at runtime. The aspx files are converted to code, and the code is compiled into an assembly. The general attitude to such code and its resulting assemblies is that it should not be analyzed by FxCop. The reasoning behind this is that a large part of the code is generated, and there is no clear distinction between the code that is generated and the HTML in the aspx files. Consequently, analyzing such assemblies generates numerous false errors and noise. For this reason, the ASP.NET 2 compiler (and other .NET Framework 2.0 code-generation tools) generates code that includes a Generated-CodeAttribute to show that the code is generated. FxCop ignores code that is marked with this attribute. At the time of writing, there is no way around this attribute, but this is an issue that is important to the FxCop team and a workaround might be introduced in a future release of FxCop.

If you are using ASP.NET 1.1 or a workaround for analyzing ASP.NET 2.0 generated assemblies is found, you might consider analyzing them on an occasional basis, as they do throw up FxCop errors that would not be caught otherwise. If you do want to analyze such assemblies, you will need to find them. In ASP.NET 1.1, the only way to get at the assemblies is to find them in ASP.NET's temporary folder in a series of mangled directory names. The mangling of the directory names and assembly names makes automating this process difficult. In ASP.NET 2.0, you have an alternative solution: You can precompile your Web site using the .NET Framework ASP.NET compiler. Open a .NET Framework command prompt and, from the .NET Framework folder, type:

 aspnet_compiler -v /WebSite1 C:\WebSite1\PreCompiled -d 

This command compiles a Web site from the WebSite1 virtual directory and places the compiled output and debug files (PDBs) in the C:\WebSite1\Pre Compiled directory. This approach is marginally better than the ASP.NET 1.1 approach because the output is placed in a known location. However, the assembly names are still mangled, so there is still some work to be done. A better solution to this problem is to use a Web Deployment Project. Web Deployment Projects are MSBuild projects for ASP.NET 2 Web sites. You can find out more about Web Deployment Projects and download the Web Deployment Project add-in package at http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx.