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.

"I can't believe Microsoft didn't make [Enter API Name Here] public"

David Kean — Tue, 09 Dec 2008 15:00:00 GMT

Jeremy Miller takes a dig at the BCL team with his post, I love Ayende (and OSS):

From one of Ayende's many OSS projects.
/// This class actually already exists in the System.Core assembly...as an internal class.
/// I can only speculate as to why it is internal, but it is obviously much too dangerous
/// for anyone outside of Microsoft to be using... 
And dear MS BCL team, since so many people are already using Reflector to go get the ExpressionVisitor code, would you just make this public? 'K, thx.

This seems like an oversight that this wasn't public in first place. It would just be a couple minutes of a single developer's time to change the accessibility from internal to public, right?

Well, actually, it's a lot more complicated than that. There's very good reasons we don't make things public and virtual by default; Eric Lippert summarizes it pretty well with his post, How many Microsoft employees does it take to change a lightbulb?

One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.
One program manager to write the specification.
One localization expert to review the specification for localizability issues.
One usability expert to review the specification for accessibility and usability issues.
At least one dev, tester and PM to brainstorm security vulnerabilities.
One PM to add the security model to the specification.
One tester to write the test plan.
One test lead to update the test schedule.
One tester to write the test cases and add them to the nightly automation.
Three or four testers to participate in an ad hoc bug bash.
One technical writer to write the documentation.
One technical reviewer to proofread the documentation.
One copy editor to proofread the documentation.
One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc.
Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem.
A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.

In addition to the excellent reasons that Eric lists (and the one that often gets forgotten) is compatibility. Despite what appears to be evidence to the contrary, the compatibility bar between versions of the Framework is extremely high. Every single public member and type and its behavior needs be maintained indefinitely. The more APIs that are public and/or virtual, the more baggage that needs to be brought forward into future Framework versions so as to not break compatibility.

Developing good APIs is extremely difficult, especially the first time around. When we get things wrong (and we do get things wrong), trying to maintain backwards compatibility often stifles innovation as we try to correct these scenarios. Unfortunately, unlike others, we don't have the luxury to make only 95% of our new versions backwards compatible with our previous versions.

It is for these very reasons, we try to make our extension points deliberate and designed.

Dave's Box : Compatibility, API Design

Moving a type from one assembly to another using TypeForwardedToAttribute

"I can't believe Microsoft didn't make [Enter API Name Here] public"