0

I am working on an installer where I tried to add an execution of a custom action. I wanted the CA to be executed before the installFiles step but yet it the CA was called after the files was installed, which is too late. So I replaced the CA call to the right place according to the specifications but the CA was still called on the old moment as well, even though I replaced it. I couldn't figure out why the CA was still called on the old moment and in the attempt to fix it, I did a complete rollback, removing the CA on all places and also remove the CA itself. I even did a complete undo on all the code changes after I shelved them (we are using source control) and still the CA is called but since the CA doesn't exists anymore, it now gives an error with the code/number 2721, stating the CA failed to execute because it could not be found in the binaries.

I checked and searched (find all in visual studio) the code several times now but I cannot find the code part which tries to execute the CA. And given the fact that I did a complete undo on all my code changes, there shouldn't be any location. Yet the installer keeps on trying to execute the CA. To check if I am executing the right installer I even changed the text of a label and I see the text changed so I am executing the right installer.

My wildest guess is there is some weird partly caching going on but I have no clue if this is actually happening and how to figure it out. Did anyone else have this issue? Can anyone point me in the right direction for how to fix this issue?

PhilDW
  • 20,260
  • 1
  • 18
  • 28
Cornelis
  • 1,729
  • 5
  • 23
  • 39
  • 1
    Did you clean up all *.wixobj files before rebuilding? Maybe you have deleted a WXS file but the corresponding WIXOBJ file still exists and gets linked. – zett42 Jul 25 '18 at 10:30
  • Yes, I deleted the obj and bin folder several times before rebuilding but this didn't fix the issue. – Cornelis Jul 25 '18 at 11:19
  • Just shooting from the hip to verify, you wouldn't happen to have set a hard coded package GUID? Have you checked all include files? (if any). Inspect the MSI with Orca after compilation, what is in the `CustomAction` table and what is in the `InstallUISequence` and `InstallExecuteSequence` tables? Sort by Sequence column. – Stein Åsmul Jul 25 '18 at 14:31
  • The compiled MSI is the starting point for debugging I think. Make sure all post-build steps (if any) are done too, before you inspect it. Are you checking installation on a clean virtual by the way? Your main box might have gotten into a problematic state as you have worked on your installer. It certainly happens. – Stein Åsmul Jul 25 '18 at 14:39
  • @SteinÅsmul I installed Orca and checked the tables you mentioned. I couldn't find any weird things in those tables and certainly not the CA that is being called. I used the find functionality as well, but no results were returned. And what do you mean with my main box? What is the main box in this context? Also, I haven't checked it on a vm environment yet, but a collegue of mine doesn't has the issue. Obviously because the code that caused it, wasn't on his machine yet. – Cornelis Jul 26 '18 at 07:05
  • With your main box I mean your main development machine. It is possible that you have a package code duplication problem ([potentially similar issue](https://stackoverflow.com/a/29872236/129130) - also see actual question with the WiX markup). Do you hard code the package code in your WiX source file? There could be other causes, but please try to check that first. – Stein Åsmul Jul 26 '18 at 09:46
  • [I wrote about cleaning up your box if you have a package GUID duplication problem a while back](https://stackoverflow.com/a/50283003/129130). A bit too verbose, but I think you should find the information you need if a cleanup is needed. – Stein Åsmul Jul 26 '18 at 10:20
  • I am not quite sure what you mean with package code. The installer does have a Property_UpgradeCode (which is used for the UpgradeCode attribute in the Product Element) and I changed the guid which was set in the define. I also changed the Guid in the component element and either one of them or both removed the error. So my guess is now that in windows keeps a record of guids which are linked to installers and therefor knows which earlier executed installer is executed again and also caches the installer. Am I somehow thinking in the right direction? – Cornelis Jul 26 '18 at 12:52
  • Windows has a full record of what you have installed, were it was installed and by what MSI it was installed. Each MSI has **package code** (identifies an MSI file), **product code** (identifies a version of a product), and **upgrade code** (identifies a family of related products). It is very important that all MSIs have different package codes, or very weird errors can results. Maybe have a look at generating [a list of installed packages using the VBScript in this answer](https://stackoverflow.com/a/50283003/129130). Then look for duplicated package codes by opening the CSV file in Excel. – Stein Åsmul Jul 30 '18 at 04:20
  • Couple of ideas how to identify the problem: 1) Try to copy your sources to another folder build them and see if the issue persists. 2) Download the sources from online repository to another folder build them and see if the issue persists. 3) Try to install it on another drive and see if the issue persists. 4) If possible try to execute these steps (or at least run the installer) on another PC and see if the issue persists. – Mykhailo Seniutovych Aug 19 '18 at 07:04
  • If the issue is not fixed in all of these steps, then something is wrong with your code. If it is fixed (and especially on step 3) one of my assumptions is that you messed up with your system somehow, I would delete all the registry key-values for you `ProductName` from `HKEY_LOCAL_MACHINE\SOFTWARE` (or `HKEY_CURRENT_USER\Software` if your installer is user specific) and see if that helps. I've had some very weird situations with WIX and clearing the registry helped me couple of times. – Mykhailo Seniutovych Aug 19 '18 at 07:05

0 Answers0