Replacing a .NET Dll
-
Hello, I have a .Net executable that calls a .Net Dll, which is strong named and registered in the GAC, so it won't have to be in the same directory as the executable. I made some changes in the Dll (but didn't alter the methods headers) and recompiled it with the same StrongName Key. Then I tried to replace the old Dll with the new one, both in the Dll directory and in the GAC. But now the executable doesn't recognize the new Dll! Any help? Thanks.
-
Hello, I have a .Net executable that calls a .Net Dll, which is strong named and registered in the GAC, so it won't have to be in the same directory as the executable. I made some changes in the Dll (but didn't alter the methods headers) and recompiled it with the same StrongName Key. Then I tried to replace the old Dll with the new one, both in the Dll directory and in the GAC. But now the executable doesn't recognize the new Dll! Any help? Thanks.
If you didn't change the version number, GACUTIL won't do anything. It looks at the metadata, says 'yup, I've already got that one' and doesn't overwrite. The same is true for any other methods of updating the GAC (since the work is done by fusion.dll - all methods of updating the GAC wrap fusion.dll). You need to remove from the GAC first. Note that you shouldn't issue a new DLL with the same version, culture and strong name key as before. You're supposed to either use Publisher Policy (yuck) or configuration (slightly less yuck) to redirect from the old version to the new, if required. If the DLL is tied closely to a particular project, you should not use the GAC. IMO, the GAC is overused. You should only use the GAC if you have a shared DLL that you won't control all the clients of. It's generally safer and cleaner to stick to keeping private DLLs - not strongly named - in the same directory as the executable, or in a
dlldirectory below the executable's directory. You may feel that you need to have certain fixes apply to all clients of your DLL. If you've been able to test the changes to all clients sufficiently, go ahead. But it's generally safer to stick to using the version that the executable was tested with, and update the whole package if a bug is found. Stability. What an interesting concept. -- Chris Maunder -
If you didn't change the version number, GACUTIL won't do anything. It looks at the metadata, says 'yup, I've already got that one' and doesn't overwrite. The same is true for any other methods of updating the GAC (since the work is done by fusion.dll - all methods of updating the GAC wrap fusion.dll). You need to remove from the GAC first. Note that you shouldn't issue a new DLL with the same version, culture and strong name key as before. You're supposed to either use Publisher Policy (yuck) or configuration (slightly less yuck) to redirect from the old version to the new, if required. If the DLL is tied closely to a particular project, you should not use the GAC. IMO, the GAC is overused. You should only use the GAC if you have a shared DLL that you won't control all the clients of. It's generally safer and cleaner to stick to keeping private DLLs - not strongly named - in the same directory as the executable, or in a
dlldirectory below the executable's directory. You may feel that you need to have certain fixes apply to all clients of your DLL. If you've been able to test the changes to all clients sufficiently, go ahead. But it's generally safer to stick to using the version that the executable was tested with, and update the whole package if a bug is found. Stability. What an interesting concept. -- Chris MaunderHi. Thanks very much for your advice. I will describe the steps of what I did in more detail: 1- Compiled the Dll with a strong name key file, and version set to '1.0.*' (what happens here is that the version number changes everytime I compile) 2- Copied the Dll to 'c:\Components\MyComponent.dll' 3- Registered the 'MyComponent.dll' in the GAC 4- In the Client project I added a reference to 'c:\Components\MyComponent.dll' 5- Compiled the Client project and copied it to 'c:\Programs\MyProgram.exe' (At this point all things work properly. A few days later I needed to do some changes in the Dll component) 6- I changed some lines of code in a method of the Dll project, then recompiled it (thus generating a new version number) with the same strong name key file. 7- Removed the old Dll from the GAC and deleted the file 'c:\Components\MyComponent.dll'. 8- Copied the updated Dll to 'c:\Components\MyComponent.dll' and registered it in the GAC. (Now, from this point the client program at 'c:\Programs\MyProgram.exe' stopped working, saying it doesn't find the component.) This component is to be shared between different applications, and I decided to put it in the GAC so I wouldn't have to copy it to all the applications directories everytime there is a change in the component. I expected it was enough to just update the Dll from the 'c:\Components' directory and the changes would reflect to all applications that use it. Am I missing something here?
-
Hi. Thanks very much for your advice. I will describe the steps of what I did in more detail: 1- Compiled the Dll with a strong name key file, and version set to '1.0.*' (what happens here is that the version number changes everytime I compile) 2- Copied the Dll to 'c:\Components\MyComponent.dll' 3- Registered the 'MyComponent.dll' in the GAC 4- In the Client project I added a reference to 'c:\Components\MyComponent.dll' 5- Compiled the Client project and copied it to 'c:\Programs\MyProgram.exe' (At this point all things work properly. A few days later I needed to do some changes in the Dll component) 6- I changed some lines of code in a method of the Dll project, then recompiled it (thus generating a new version number) with the same strong name key file. 7- Removed the old Dll from the GAC and deleted the file 'c:\Components\MyComponent.dll'. 8- Copied the updated Dll to 'c:\Components\MyComponent.dll' and registered it in the GAC. (Now, from this point the client program at 'c:\Programs\MyProgram.exe' stopped working, saying it doesn't find the component.) This component is to be shared between different applications, and I decided to put it in the GAC so I wouldn't have to copy it to all the applications directories everytime there is a change in the component. I expected it was enough to just update the Dll from the 'c:\Components' directory and the changes would reflect to all applications that use it. Am I missing something here?
When a program or DLL references a strongly-named DLL, all components of the DLL's identity are recorded - assembly name, version number, culture, and public key token. Only that version of the DLL will be loaded. The GAC can contain multiple assemblies with the same base name if they have different version numbers, cultures, and/or public key tokens. That last allows different vendors to use the same base name independently, although this will be pretty confusing to a user! When loading a strongly-named DLL, the GAC is searched first, then the application's directories. See How the Runtime Locates Assemblies[^] for more. To cause a different version of an assembly to be loaded from that listed in the referencing assembly's manifest, you have two options: Publisher Policy[^], or <assemblyBinding>[^] elements in the application's configuration file. The former allows all uses of an assembly to be directed to a new version, but the documentation is a bit unclear. The latter has to be applied to every executable that will use the updated assembly. I'll reiterate that for components that aren't going to be released to third-party developers, I'd recommend keeping your class library assemblies private, without strong naming. If the assembly isn't strongly named you can overwrite without regard to version numbers. It does make deployment slightly more difficult, since you have to copy the updated assembly to the directories of every application you want to use it, but then you should probably only update those