In .NET, one often refers to other assemblies that contain specific modules that you can use in your application. Say, you reference a DLL that contains some classes that you will use in your application. Suppose the application is deployed. Now, suppose you want to move one class of the DLL to another assembly. What can you do in this situation with old coding methodoligies? The old methodologies say,
- Remove the class from the existing DLL.
- Create another DLL (assembly) using that class.
- Recompile both the DLLs.
- From your application, add a reference to the new DLL.
- Recompile the application.
- Re-deploy the whole thing.
Wouldn't it be nice to leave the deployed application untouched, and make whatever changes are needed in the DLLs? Obviously, that would be nicer. That's where theTypeForwardedTo attribute comes into the scene. By using this, you can move your necessary classes out to a new assembly. Now, when your application looks for the class in the old DLL, the old DLL tells your application (the JIT compiler—to be precise), "Well, the person (class) who lived here has moved to another location; here is the address." It gives in the address, your application follows the address, there it finds the class, and things go on as is.
So, simply you will create another assembly (DLL) and move the class to the new assembly. Then, you have to compile the new DLL and add a reference to it from the previous DLL. Then, you will add a TypeForwardedTo attribute in the previous DLL to mean a specified type is forwarded to some other assembly. Then, you have to recompile the old DLL and, as a result, you will have two DLLs in the release folder of the previous DLL. Now, you just have to place both the DLLs in the root of the deployed application (or wherever the old DLL is).
Article taken from here
Article taken from here
Comments
Post a Comment