Some .NET Framework Best Pratices

Hi all, here are some .NET Framework Best Pratices for you...

Optimizing performance with built-in types
The runtime optimizes the performance of 32-bit integer types (Int32 and UInt32), so use those
types for counters and other frequently accessed integral variables. For floating-point operations,
Double is the most efficient type because those operations are optimized by hardware.

Garbage collection
Garbage collection occurs only when needed or when triggered by a call to GC.Collect. Automatic
garbage collection is optimized for applications where most instances are short-lived, except for
those allocated at the beginning of the application. Following that design pattern will result in the
best performance.

Boxing and unboxing
Boxing and unboxing incur overhead, so you should avoid them when programming intensely
repetitive tasks. Boxing also occurs when you call virtual methods that a structure inherits from
System.Object, such as ToString. Follow these tips to avoid unnecessary boxing:

• Implement type-specific versions (overloads) for procedures that accept various value types.

It is better practice to create several overloaded procedures than one that accepts an Object
argument.

• Use generics whenever possible instead of accepting Object arguments.
• Override the ToString, Equals, and GetHash virtual members when defining structures.

Version Compatibility
To ensure proper versioning behavior, follow these rules when modifying a custom
class from version to version:

• Never remove a serialized field.
• Never apply the NonSerializedAttribute attribute to a field if the attribute was not applied to the field in a previous version.
• Never change the name or type of a serialized field.
• When adding a new serialized field, apply the OptionalFieldAttribute attribute.
• When removing a NonSerializedAttribute attribute from a field that was not serializable in a previous version, apply the OptionalFieldAttribute attribute.
• For all optional fields, set meaningful defaults using the serialization callbacks unless 0 or null as defaults are acceptable.

Waiting forever
Instead of using overly long millisecond timeouts for infinite timeouts (where you are willing to wait
as long as it takes), you should use the Timeout class’s static Infinite property.

Working with files
Applications running in the Internet and LocalIntranet zones do not receive the FileIOPermission,
and as such, cannot directly access files. They do, however, have FileDialogPermission. Therefore,
assemblies in the Internet zone can open files by prompting the user to select the file using an
OpenFileDialog object. Assemblies in the LocalIntranet zone can also save files by using the Save-FileDialog object. To access files without FileIOPermission, call the ShowDialog method of either
OpenFileDialog or SaveFileDialog. If the user selects a file, you can use the file handle returned by the OpenFile method to access the file.

Use SecurityAction.RequestOptional assembly declarations
There are whole books about writing secure code, and you should always follow secure coding
best practices. We’re just human, though. Sometimes, you might simply forget to validate an input or to use strong typing. Other times, you might be rushing to finish a project and just get careless.
Using SecurityAction.RequestOptional assembly declarations is the one security best practice that you should always follow. These declarations take very little time to write because it’s just a couple lines of code, they’re easy to debug because the runtime will throw an easily identifiable exception, and they offer protection for every line of code in your assembly. As an assembly grows in size, this projection decreases some.

Avoid redundant demands
Most classes in the .NET Framework use demands to ensure that callers have the permissions
required to use them, so also calling Demand is redundant. For example, if you’re reading a line
from a text file using a StreamWriter object, the object itself will demand FileIOPermission. Generally, use demands to protect custom resources that require custom permissions.

When not to implement IIdentity
This code shows how to implement a custom identity based on IIdentity. However, if you want to add properties to a Windows logon while still using the Windows token or other Windows security properties, base your custom identity on the WindowsIdentity class instead. The same applies for IPrincipal and WindowsPrincipal.

Choosing a symmetric key algorithm
Use the Rijndael algorithm whenever both the encryptor and decryptor are running on Windows
XP or later operating systems; otherwise, use Triple DES. Out of all symmetric-key algorithms supported by the .NET Framework, the U.S. government–approved Rijndael algorithm is considered the most secure. This algorithm supports 128-, 192-, and 256-bit keys. Another reason to choose Rijndael is that it is the only implementation that is natively supported by the .NET Framework. The other algorithms must make calls to unmanaged code.

Avoiding optional parameters
There are many reasons to avoid Visual Basic’s optional parameter feature, although this is an area that’s frequently disputed. The primary reason to avoid them, in my opinion, is that they aren’t supported in all .NET languages. Developers who didn’t know Visual Basic and were trying to translate the code would have a difficult time—they’d wonder why something worked in one context and not the other. Similarly, many argue that optional parameters are remnants of the previous non .NET Visual Basic and, as such, should be avoided.

StringBuilder objects are preferable to String objects in P/Invoke calls
When using Platform Invoke, use a StringBuilder object instead of a String. A StringBuilder is a
reference type with no atypical behavior and is needed because of the way P/Invoke internals
work.

These tips are from 70-536 - Application Development Foundation book.

See yaa!