3

In particular, we've created an .msi installer that installs assemblies to the GAC, and has a built-in DoRegisterTypeLib operation on msxml3.dll. However (and somehow), the bad msxml3.dll version (8.70.1104.0, which Microsoft knows about) still exists on some end-users' PCs. And that DoRegisterTypeLib fails (with error code 11) if the msxml3.dll is that bad version. We tell our end-users to "Repair" their .NET installation, and boom, everything works.

So again, what does this "Repair" do? Does it update certain/any Microsoft .dlls?

And even if we shouldn't make that DoRegsiterTypeLib on that (or any .dll), I still really want to know what "Repair .NET" does under the hood. Any insight anyone has would be appreciated!

branrigg
  • 31
  • 2
  • It rewrites a gazillion registry keys. Which includes fixing anything that could be affected by an installer dropping a bad DLL or wonking the registry, the kind that Microsoft needs to deal with every day. Never consider doing this yourself, you won't get it right. You are exposing yourself to such bad installers by having a dependency on msxml3, you need to move to msxml6. – Hans Passant Jan 29 '15 at 00:49
  • Almost certainly you shouldn't be doing that DoRegisterTypeLib call. Apart from the potential issues of doing it separately from just using (for example) the merge module, your custom action might run during a repair of your product if the condition isn't correct. It's just a mess if you register some incorrect Dll typelib, then the NET repair fixes it, then your repair runs your custom action again. – PhilDW Jan 29 '15 at 17:55

1 Answers1

1

It goes through each component and checks that its KeyPath is present and correct.

It will register dll and components, and copy missing corrupt files to the INSTALLDIR

You could activate the LOG for the repair The first step is to turn on logging for windows installer. You can either do this when you run the MSI (assuming you're directly running the MSI file, not using control panel) or use a registry setting to turn on logging globally. See http://support.microsoft.com/kb/223300 for details.

CheGueVerra
  • 7,849
  • 4
  • 37
  • 49
  • I'll look at the specific relevant registry keys then. We call our .msi from a command line and turn on as much logging as we can, but good suggestion for logging the .NET Repair itself. I'd +1 if I could... – branrigg Jan 29 '15 at 00:03
  • Post your finds, it's always a good way to say thanks ;) You can always vote later on – CheGueVerra Jan 29 '15 at 00:05
  • Actually there is a higher level activity going on. .NET Framework isn't a single MSI. It's an EXE bootstrapper that chains a number of packages together depending on your OS and bitness. The repair calls the EXE repair which then calls repair on the various MSI's. It may or may not be checking keyfiles. It may just do a REINSTALL=ALL. – Christopher Painter Jan 29 '15 at 12:28
  • To be more specific, a repair typically runs with a REINSTALLMODE of pocmus, so files that are missing OR have a lower version will be repaired back to the original version from the MSI. – PhilDW Jan 29 '15 at 17:58
  • If someone has a solid need to know of exactly what is going on (versus an academic question) the guys to ask are Heath Stewart and Aaron Stebner. Their blogs are easy to find. – Christopher Painter Jan 29 '15 at 20:18