.NET 2.0 System Types and Collections - part 1(a) of 4

• Attributes
• Exception classes
• TypeForwardedToAttributes class

I didn't finish off these last concepts in my previous post, so I will do them now.

The TypeForwardToAttribute class is not well documented. A search of MSDN returns no results! A search of both Google and Yahoo returns mostly results related to the certification, not the class itself. That is a shame. If this is such an important topic, they would have more on it. Is this one of those questions one must simply learn to pass a test? I hope not.

UPDATE - Microsoft's exam prep guide spells this wrong! The correct class name is TypeForwardToAttribute (without an 's' making it plural). That mistake distracted me for a couple of hours.

TypeForwardToAttribute allows you to move a type declaration to another assembly without disrupting users of a previous version of the assembly.

As an example, if you had an assembly named Animal with a Dog class in it, but later decided to move the Dog class to a new assembly called Canine you could do that without impacting applications that refer to the Animal assembly when looking for the Dog class.

I stole this, so don't give me credit for this example:

1. Move the type declaration to the new assembly
2. In the old assembly, add a reference to the new assembly
3. Add the following to the old assembly:

THIS
namespace Animal {

   public class Dog {
     }
  }

BECOMES

using System.Runtime.CompilerServices;

[assembly : TypeForwardedTo( typeof (Canine.Dog ) )]
namespace Animal
{
}

YOU MUST ADD DOG CLASS TO THE CANINE ASSEMBLY

namespace Canine {
  public class Dog {
     }
  }

TODO
• Attributes
• Exception classes

.NET 2.0 System Types and Collections - part 1 of 4

I am going to do one section a night. I haven't done the math, but suspect this will put me in under 45 days. So let's kick this off. Most information will come from the Professional C# 2005 wrox book, and some will come from MSDN.

Manage data in a .NET Framework application by using .NET Framework 2.0 system types. (Refer System namespace)

Types
The two basic types are value types and reference types. A value type is stored on the stack and a reference type stored on the heap. Value types are simple data types – and you don't need to create new instances of them when declaring variables. A description of the heap and stack can be found in this link.

Value types are those data types that are allocated in the stack. They include:

• All built-in types except string
• Structs
• Enums

Reference types are allocated on the heap and are garbage collected when they are no longer being used. They are created using the new operator, and there is no delete operator for these types, unlike in C++, where the user has to explicitly delete the types created using the delete operator. In C#, they are automatically collected by the garbage collector.

Reference types include:

• Classes
• Interfaces
• Collections
• Strings

Nullable types
The only type that is nullable is a reference type - ie a variable that is an instance of a class, collection, or String. Objects no longer in use are garbage collected, however setting an object to "null" or "Nothing" doesn't trigger garbage collection.

Example
VB: x = Nothing
C#: x = null;

Boxing and Unboxing
Boxing means to convert a value type to a reference type. UnBoxing means to convert a reference type to a value type. This has to do with where data is stored - on the heap or in the stack. Boxed types are stored on the heap, where unboxed are stored on the stack. Everything in .NET is an object. You can always cast anything as an object, but problems can manifest themselves when casting objects as other types.

There is also a performance cost to boxing and unboxing. Boxing is required when using collections so Microsoft created a new type of collections called Generics, which address this problem. More on this in the next point.

Boxing can cause type safety issues - instead of compile time errors you can get run-time errors. For example:

double i = 20.55;
object o = i; //this is boxing
double j = (double)o; //this is unboxing

int k = (int) o; //Causes a runtime error, not compile time

The problem with boxing and unboxing is that you could also introduce unsafe code that won't be caught at compile time. In this instance, you could compile the application with no warnings. This bug may slip through the cracks as a result, and cause big problems later on.

TODO
• Attributes
• Exception classes
• TypeForwardedToAttributes class