In the original Star Wars movie there is a classic scene where Obi-Wan and Luke enter the Tatooine Space-port.
Storm trooper: Let me see your identification.
Obi-Wan: [with a small wave of his hand] You don't need to see his identification.
Storm trooper: We don't need to see his identification.
Obi-Wan: These aren't the droids you're looking for.
Storm trooper: These aren't the droids we're looking for.
Obi-Wan: He can go about his business.
Storm trooper: You can go about your business.
Obi-Wan: Move along.
Storm trooper: Move along... move along.
Obi-Wan uses the “Jedi Mind Trick” on the Storm trooper to “suggest” what he should do.
Sometimes we need to do the same thing in .NET.
Consider the scenario where you have developed a class – MyClass - in a Library that you distribute - MyLibrary. You want to reorganize your libraries and create a new – MyNewLibrary - and move MyClass to the new asembly. The problem is that all your existing applications expect MyClass to be in MyLibrary not MyNewLibrary.
In .NET 2.0 a new assembly level attribute was added – TypeForwardedTo(typeof(MyClass)). This can be applied to the “old” version of the Library, and your applications will not break.
The procedure is as follows:
- Move the MyClass code from MyLibrary to MyNewLibrary .
- Put TypeForwardedTo(typeof(MyClass)). in MyLibrary for the MyClass type.
- Compile the newly created MyNewLibrary .
- Add a reference of MyNewLibrary into MyLibrary .
- Recompile MyLibrary (because MyClass used to be located in that).
When your application attempts to get a reference to MyClass from MyLibrary – it will be redirected to the correct MyNewLibrary.
Or as Obi-Wan would say - “This is not the assembly you’re looking for.”
There is one corollary to this. In .NET 2.0 MyLibrary cannot be a VB.NET assembly – this has been fixed in .NET 3.5 (VB9).
I am currently investigating whether this could be an approach to the “Breaking Changes” issue, as we move forward with DotNetNuke development.
349132d4-bf07-4fc4-bcfd-510b4fe75f52|0|.0