TypeForwardedToAttribute
-
What is the good point of using this attribute? this said,[[^](http://this said,)], 1. Code a new assembly (A2). 2. Move type T1 to from A1 to A2. 3. Remove T1 from A1. // Note by Michael Sync: We can't change the original namespace. 4. Reference A2 from A1 5. Add a TypeForwardedTo attribute to A1, pointing at T1 (now in A2) 6. Recompile A1 and A2. 7. Replace the original A1 with the new A1 and A2 (in the locations used by APP) Since we have to reference A1 and A2, I didnt see any advantage of using this attribute.. Did I miss something here? It would be great if anyone explain me about the advantage of using this attribute with some examples. Thanks in advance.
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
-
What is the good point of using this attribute? this said,[[^](http://this said,)], 1. Code a new assembly (A2). 2. Move type T1 to from A1 to A2. 3. Remove T1 from A1. // Note by Michael Sync: We can't change the original namespace. 4. Reference A2 from A1 5. Add a TypeForwardedTo attribute to A1, pointing at T1 (now in A2) 6. Recompile A1 and A2. 7. Replace the original A1 with the new A1 and A2 (in the locations used by APP) Since we have to reference A1 and A2, I didnt see any advantage of using this attribute.. Did I miss something here? It would be great if anyone explain me about the advantage of using this attribute with some examples. Thanks in advance.
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
only use is when you have some legacy application (no source available, or cannot recompile for any other reason) referencing the type T1 originally located in A1 and for whatever reason you need to move the type out from that assembly. Then you can do that mumbo-jumbo and you'll have your type happily moved out of A1 to A2, legacy binary still referencing the A1, but using type T1 from A2. At least that's the reason for the attribute from my understanding. Modify: Yes! And you need to know it for MS exams (the second reason why this attrib exists ;-) ).
-
only use is when you have some legacy application (no source available, or cannot recompile for any other reason) referencing the type T1 originally located in A1 and for whatever reason you need to move the type out from that assembly. Then you can do that mumbo-jumbo and you'll have your type happily moved out of A1 to A2, legacy binary still referencing the A1, but using type T1 from A2. At least that's the reason for the attribute from my understanding. Modify: Yes! And you need to know it for MS exams (the second reason why this attrib exists ;-) ).
thanks a lot for reply. geo_m.
geo_m wrote:
some legacy application (no source available, or cannot recompile for any other reason)
We need to add A2 as a reference in Window Application after moving T1 from A1 to A2. isn't it? So, how to do that if that window application has no source code.. I think it can be done without this attribute.. right? We will move T1 from A1 to A2. Then, we will add A2 as a reference in window application. so, it's not necessary to have this attribute..
geo_m wrote:
Modify: Yes! And you need to know it for MS exams (the second reason why this attrib exists ).
:) haha.. Yeah...
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
-
thanks a lot for reply. geo_m.
geo_m wrote:
some legacy application (no source available, or cannot recompile for any other reason)
We need to add A2 as a reference in Window Application after moving T1 from A1 to A2. isn't it? So, how to do that if that window application has no source code.. I think it can be done without this attribute.. right? We will move T1 from A1 to A2. Then, we will add A2 as a reference in window application. so, it's not necessary to have this attribute..
geo_m wrote:
Modify: Yes! And you need to know it for MS exams (the second reason why this attrib exists ).
:) haha.. Yeah...
Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net)
Okay. geo_m. I got you.. The main advantage having this attribute is that it's easy to move the type without recompiling the main application. 1. Code Class1 in (ClassLibrary1) assembly. 2. Add this ClassLibrary1.dll to Window application 3. Use ClassLibrary1.Class1 in window application 4. Code a new assembly (ClassLibrary2). 2. Move type Class1 to from ClassLibrary1 to ClassLibrary2. // Note by Michael Sync: We can't change the original namespace. So, we have to keep "ClassLibrary1.Class1" in ClassLibrary2 3. Remove Class1 from ClassLibrary1. 4. Reference ClassLibrary2 from ClassLibrary1 5. Add a TypeForwardedTo attribute to ClassLibrary1, pointing at ClassLibrary2(now in A2) eg: in assembly.cs under properties of project view
[assembly: TypeForwardedTo(typeof(ClassLibrary1.Class1))]6. Recompile ClassLibrary1 and ClassLibrary2 . 7. Copy new ClassLibrary1.dll and ClassLibrary2.dll. Replace the old ClassLibrary1.dll. Paste ClassLibrary2.dll We dont need to touch Window application for adding ClassLibrary2.dll. Window application keep using ClassLibrary1. ClassLibrary1 will forword to ClassLibrary2. So, it's not necessary to recompile the window application.. Yeah. That's great... Thanks again. geo_mThanks and Regards, Michael Sync ( Blog: http://michaelsync.net)