Moving a type from one assembly to another using TypeForwardedToAttribute

David Kean — Fri, 19 Dec 2008 15:00:00 GMT

One of the problems that we’re facing today in the Framework, mainly stemming from the red bits/green bits design of .NET 3.5, is that certain ‘core’ types are located in the wrong assemblies.

For example, the extremely useful ObservableCollection<T> and ReadOnlyObservableCollection<T> types both live in WindowsBase.dll, which is a part of the Windows Presentation Foundation. For low-level assemblies (such as my team’s very own System.ComponentModel.Composition.dll), this means that to use types such as these, they need to take a reference to assemblies either at a higher level to themselves, or to technologies outside of their own. This is in turn leads to scary dependencies, such as the server assembly System.Web.dll’s current direct dependency on the client assembly System.Windows.Forms.dll in .NET 2.0.

Going forward for .NET 4.0, the Framework Architecture team will be leading an effort (being pushed by my colleague Mitch Trofin) to move these and other core types to lower-level assemblies such as mscorlib.dll and System.dll.

Now, as I’ve mentioned previously, Microsoft takes compatibility very seriously, so you might be thinking ‘how can they move these types without runtime breaking changes’?

Luckily, there’s already a solution for this; type forwarding. Introduced in .NET 2.0, type forwarding allows assembly writers to move types into other assemblies without needing existing consumers to recompile their applications. This done via the TypeFowardedToAttribute.

To move a type, do the following:

Move the type from the original assembly to the assembly that will become the type’s new home.
In the original assembly, add a reference to the new assembly if it does not already have one.
Apply the following assembly-level attribute to the original assembly, replacing MyType with the type you moved in step 1:
```
[assembly: TypeForwardedToAttribute(typeof(MyType))]
```
Compile both assemblies and that’s it.

A couple of things to note:

The type must have the same name and namespace in the target assembly.
This is considered a source breaking change; that is, users recompiling their application against the new versions of the assemblies, will be required to add a reference to the assembly that now contains the type.
While fully supported by C# and C++/CLI, Visual Basic does not support moving types using the TypeForwardedToAttribute. It does, however, support consuming assemblies written by other languages that have had their types moved.
Starting in .NET 4.0, a new attribute called TypeForwardedFromAttribute should be applied to types that have been forwarded indicating which assembly they came from. This allows runtime serialization to serialize these types correctly when interoping with previous versions of these assemblies.

Breaking changes to the String class

David Kean — Wed, 12 Nov 2008 15:00:43 GMT

You may have already read Justin Van Patten's post about the upcoming breaking changes to the String class for .NET 4.0. This change will affect the behavior of the String.StartsWith, String.EndsWith, String.IndexOf and String.LastIndexOf methods by changing them to perform an ordinal (byte-for-byte) comparison by default instead of a culture-sensitive comparison using CultureInfo.CurrentCulture. In addition, the default overloads of String.ToUpper, String.ToLower, Char.ToUpper and Char.ToLower will be changed to use CultureInfo.InvariantCulture instead of CultureInfo.CurrentCulture.

How does this change affect me?

If you are using an overload of one of the above methods that does not take a StringComparison or CultureInfo as a parameter, then your application or library will be affected when you move it to .NET 4.0. String.Compare and String.CompareTo are not being changed.

An example of the kind of behavior change you could expect, is the following:

static void Main()
{
    int index = "encyclopædia".IndexOf("encyclopaedia");

    Console.WriteLine(index);
}

On versions previous to .NET 4.0, this will output 0 when the user's current locale is set to some cultures, such en-AU, English (Australia), and -1 when the user's current locale is other cultures, such nn-NO, Norwegian, Nynorsk (Norway).

However in .NET 4.0, the above comparison will always output -1, regardless of the user's current locale.

Why was this change made?

The comparison methods on the String class have always been a little schizophrenic; some methods, ==, String.Equals and String.Contains for example, perform an ordinal comparison by default, whereas the above methods, as well String.Compare and String.CompareTo, perform a culture-sensitive comparison. Because they use the current culture, the default culture-sensitive comparisons can also vary between systems, users and even during the same application session. Which, as pointed out in Justin's post, can lead to security vulnerabilities in applications that make security decisions using the default overloads. The planned breaking changes bring the majority of these methods inline with each other to have the same default behavior.

How do I find and fix these comparisons?

To start, you should run FxCop or Visual Studio Code Analysis over your code base. The rules Specify StringComparison and Specify CultureInfo will fire on call sites that do not explicitly specify a StringComparison or CultureInfo. Specify ordinal StringComparison will fire when you use invariant culture instead of ordinal to compare, which is almost always wrong.

To help determine the correct StringComparison or CultureInfo to use, you cannot go past the excellent article New Recommendations for Using Strings in .NET 2.0. In particular, the section under Choosing a StringComparison Member for Your Method Call provides a table detailing common operations and comparisons to use.

Dave's Box : BCL, .NET 4.0

Moving a type from one assembly to another using TypeForwardedToAttribute

Breaking changes to the String class

How does this change affect me?

Why was this change made?

How do I find and fix these comparisons?