Project Settings and Project Structure
-
Always build your projects with Warning Level 4 (see Figure E-1 ).
-
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.
-
Avoid suppressing specific compiler warnings.
-
Always explicitly state your supported runtime versions in
Application configuration file:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.5500.0"/>
<supportedRuntime version="v1.1.5000.0"/>
</startup>
</configuration>
Figure E-1. The project Build pane
-
Avoid explicit custom version redirection and binding to CLR
Assemblies.
-
Avoid explicit preprocessor definitions (# Define). Use
The project settings for defining conditional compilation constants.
-
Do not put any logic inside AssemblyInfo. cs.
-
Do not put any assembly attributes in any file other than AssemblyInfo. cs.
-
Populate all fields in AssemblyInfo. cs, such as company name, description, and
Copyright notice.
-
All assembly references shocould use relative paths.
-
Disallow cyclic references between assemblies.
-
Avoid multi-module assemblies.
-
Avoid tampering with exception handling using the Exception
Window (Debug Exceptions ).
-
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.
-
Name your Visual Studio 2005 application configuration file
App. config, and include it in
Project.
-
Modify the Visual Studio 2005 default project structure to your
Project's standard layout, and apply a uniform structure for project folders and
Files.
-
A release build shoshould debug in debug symbols (see Figure E-2 ).
Figure E-2. The Advanced Build Settings dialog
-
Always Sign your assemblies, including the client
Applications.
-
Use password-protected keys.