CODEWITHSUNDEEP
.netngen
Dabblernl
Dabblernl

Reputation: 16121

New dll's are not used with precompiled code using NGen

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.

Upvotes: 1

Views: 718

Answers (2)

Lex Li
Lex Li

Reputation: 63173

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

https://blogs.msdn.microsoft.com/clrcodegeneration/2010/04/27/ngen-getting-started-with-ngen-in-visual-studio/

Upvotes: 1

Hans Passant
Hans Passant

Reputation: 941455

There are too many possible mistakes you could have made, your question doesn't help narrow it down. You could have forgotten to update the type library reference in your VB6 project, a type library only supports a major.minor version number, a copy might exist in the GAC, there might be stray registry entries, your manifest might not be used at all, it could be a simple deployment oops, you might have incremented the wrong assembly attribute (like AssemblyFileVersion). Etcetera.

You need to use diagnostic tools to see what is really going on so you can narrow down the possible reasons:

  • The sxstrace.exe utility shows how the manifest is getting parsed.
  • The fuslogvw.exe utility shows you how assemblies are located. Configure it to log all binds in this case since you don't get a bind failure.
  • Also with fuslogvw.exe, you can see it binding the native images. Select the "Native Images" radio button in the Log Categories groupbox.
  • The SysInternals' Process Monitor utility is the weapon of choice to diagnose registry and file system mishaps. You'll see exactly how the VB6 app reads keys and locates files.

Upvotes: 1

Related Questions