1

There are some instances when a file in our application changes names and the developers don't bother telling me until after our product install breaks (usually this happens when a VB6 project breaks Binary Compatibility and the developer has to change file name to avoid DLL Hell). In these instances it would be helpful to me to be able to do some quick testing by dropping the new file into an already deployed copy of our application to see if it works before going to the effort to pull up InstallShield and update the project with the new file (most of the time these sorts of problems come up while I"m doing a smoke test on a clean VM so I have a testing environment readily available). The problem here is that most of the file who's name changed is marked as a key file in the file's component in the MSI, so when I remove the file and run our app it triggers a repair and Windows puts it back negating the value of the test.

After an application is deployed is it possible to remove the Key File status from a file to prevent windows from triggering a repair if it isn't present in the filesystem? Because it's MSI I presume there's a flag somewhere in the registry keeping track of key files?

Alex
  • 343
  • 1
  • 5
  • 13

1 Answers1

0

There are a few options:

You should un-register the COM file you intend to delete before deleting it. Then you register the new one. Note that once you have done so you must never launch the application via its original advertised shortcut (that will put the registration back as before).

  1. Launch Binary Directly: The easiest option is to go to the folder and delete the file you want removed, put the new one in place and launch the main application binary.exe from Windows Explorer instead of via the shortcut. This will bypass most self-repair entry points (there are a few that can still kick in).

  2. Non-Advertised Shortcut: You can also delete the original shortcut to the application binary and then create a new one that is non-advertised (just a regular shortcut - 1) right click and hold main application binary, 2) drag-and-drop to a blank desktop area and release button, 3) Select "Create new shortcut here"). Launching your application via this new shortcut will not invoke a self-repair in most cases. There are still a few ways self-repair can be kicked off anyway (as above). For more on this see: "Self-repair entry points" (things that can trigger self-repair).

Self-Repair: Here is an overview on self-repair and its purpose. There are further links to lots of information on the topic in that answer. Let me inline the most relevant ones here: 1) Explanation of the concept, 2) Finding real-world solutions and 3) Avoiding in your own package.

Registration-Free COM: Some people look at registrationless COM as options for old VB6 applications. This involves keeping all registry settings in a manifest file instead of the registry. Not trivial to implement it seems. Microsoft Docs.

Unregister COM file: In order to unregister a COM file:

  1. DLL and OCX files can be unregistered using regsvr32.exe (troubleshooting):

    regsvr32.exe /u File.dll

  2. EXE files can be unregistered via the /unregserver (if implemented)

    Binary.exe /unregserver

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164