When I first heard about this attribute I was excited, the refactoring potential was great!
Then I read a bit more and was disappointed to see that while you could forward types, they had to maintain their full type name, including namespace, only the assembly could change. This was disappointing but acceptable.
Today I discover that you can’t move types to assemblies you don’t reference. This is because the TypeForwardedTo attribute takes a Type, not a string containing a type name. There is no way to define a type which resolves at compile time without referencing the containing assembly. This was a bit surprising to me since the metadata for a custom attribute which has a parameter of type Type, stores the fully qualified type name, not a reference qualified type name, so you don’t need a reference in order to create the required metadata. In fact based on similarities in description I suspect the runtime basically calls the exact equivalent of Type.GetType(string) passing the deserialised metadata directly, during assembly load. The reason I know that it doesn’t use a reference qualified type name is because I have many times in the past disassembled an assembly changed the versions of its references and reassembled it. This usually works quite well, but it doesn’t fix custom attributes, which can occasionally cause problems.
For now I think a work around of referencing a pre-compiled version of the assembly using an alias (to avoid accidental use of that assembly by developers outside of the declaration of the TypeForwardedTo attributes) is going to have to suffice, but I just wanted to post that I think that c# syntax is lacking in the declaration of type based attributes. While I suspect it would be an unusual case, I think that Type.GetType(string) should be considered a compile time constant for attribute parameters, or some other nicer syntax which does the same thing.