Project Settings and Project Structure
1.Always build your projects with Warning Level 4
2.Treat warnings as errors in the Release build (note that this is not the default of Visual Studio). Although it is optional, this standard recommends treating warnings as errors in Debug builds as well.
3.Avoid suppressing specific compiler warnings.
4.Always explicitly state your supported runtime versions in the application configuration file:
< ? xml version="1.0" ?>< configuration> < startup> < supportedRuntime version="v2.0.5500.0"/> < supportedRuntime version="v1.1.5000.0"/> < /startup>< /configuration>
5.Avoid explicit custom version redirection and binding to CLR assemblies.
6.Avoid explicit preprocessor definitions (#define). Use the project settings for defining conditional compilation constants.
7.Do not put any logic inside AssemblyInfo.cs.
8.Do not put any assembly attributes in any file other than AssemblyInfo.cs.
9.Populate all fields in AssemblyInfo.cs, such as company name, description, and copyright notice.
10.All assembly references should use relative paths.
11.Disallow cyclic references between assemblies.
12.Avoid multi-module assemblies.
13.Avoid tampering with exception handling using the Exception window (Debug Exceptions).
14.Strive to use uniform version numbers on all assemblies and clients in the same logical application (typically, a solution). Use the SolutionInfo.cs technique from Chapter 5 to automate.
15.Name your Visual Studio 2005 application configuration file App.config, and include it in the project.
16.Modify the Visual Studio 2005 default project structure to your project's standard layout, and apply a uniform structure for project folders and files.
17.A release build should contain debug symbols
18.Always sign your assemblies, including the client applications.
19.Use password-protected keys.
No comments:
Post a Comment