We have a hybrid VB6/Net application in which the Net dll's are hooked up to the VB6 code using a Com Visible Net wrapper. This wrapper in its turn is activated using RegFreeCom with manifests. This setup is working for us for over 2 years. To reduce application startup time we precompile the Net dll's using NGen after installation. This takes easily a minute to complete. Now we have a new VB6 executable, with new dll's and new manifests, but it seems that the new dll's are not used when we install the program to the existing location, thereby replacing the dll's. A new installation to a different folder does use the new dll's. I checked both the program folders and the new dll's and manifestss are there in both locations. How is it possible that the new dll's are not picked up in the existing program location and Windows seems to keep using the pregenerated code from the previous version?
I did notice that NGenning completes in just a few seconds with the statement that the compiled images are up to date, which they obviously are not. Is changing the version number of the dll's not enough to trigger the creation of new images? Currently we do not digitally sign the dlls.
After calling NGen to process an assembly, .NET Framework leaves a cached version in the native image cache that the program tries to load by default, instead of your assembly. Thus, replacing the old assembly with a new one won't affect your program.
By calling NGen to uninstall the cached version, your new assembly can be seen by the program and everything starts to work.
More technical details can be found over the internet, such as