What kind of custom action was that in the original VS 2010 setup project? If it was managed code, VS 2010 inserts a C++ Dll to load a framework and run your code via reflection. If so, you'd need to migrate that to a DTF custom action. You should also check that there isn't already a custom action that you could use in the WiX custom action library. --------------- Phil Wilson
On Tue, Apr 15, 2014 at 10:56 AM, Michael Turner <mcturner...@gmail.com> wrote: > Chris, > > This looks like a bad design choice in the previous version. Most of the > time, you're going to want to embed your custom action DLL as a Binary in > the MSI package rather than installing it on the target machine as a File in > a Component. I.e., put the custom action DLL on a Binary rather than File > element, and use the BinaryKey rather than the FileKey attribute on the > CustomAction element. If you are able, you should definitely change this in > subsequent versions, although it's too late to change this for previous > versions that you've already delivered or installed somewhere. > > The most likely problem is that the uninstall custom action is scheduled to > run after the RemoveFiles standard action, so it is failing because by the > time it tries to use the custom action DLL during uninstallation, the DLL > has already been removed. Unfortunately, you can't change the > uninstallation behavior (or anything in the MSI database or embedded CAB) of > an MSI package that is already installed, so it's always a good idea to test > uninstall and upgrade behavior BEFORE you ship. Since you can't change the > old installation now, you'll have to outsmart it instead. > > If you are in this situation, here's a workaround you can try. What we are > going to do is create a dummy installer whose sole purpose is to increment > the reference count of the MSI Component that contains the custom action > DLL, to prevent it from being removed when you install the first product. > > 1. Start with the source code of the original product installer, and make a > duplicate copy. > 2. In the duplicate copy, generate a new Product ID (GUID) and a new > UpgradeCode (GUID). The Package ID (GUID) should be omitted or set to "*" > if it isn't already (i.e., anything but hard-coded). Also give it a new > Product Name and Output File Name, at your discretion. (And if you really > want to be thorough, you should edit the .wixproj file as XML and give it a > new ProjectGuid as well.) > 3. Strip away everything except the Component that contains the custom > action DLL, the Directory structure that contains it, and a single Feature > to reference it. When you're done, these should be all you have left (plus > enough bare-bones UI for it to run). I.e., no launch conditions, no custom > actions, no merges, no other components. > 4. Make sure that you have the exact same target path (key path) and the > exact same Component GUID as the original -- this is vital, because the > Component GUID needs to match in order for the reference count to be > incremented properly. If you are using auto-generated Component GUIDs per > the recommended practice, then it should be enough to ensure that the target > path (key path) stays the same. (If the Component contains something more > than just the custom action DLL's File, you'll need to duplicate that as > well, since you want it to be the exact same Component in every way.) > 5. Build and install the new "dummy installer". > 6. Try uninstalling the original product. > 7. If that worked, then uninstall the "dummy installer". > > If this works out, then you should distribute this dummy installer to anyone > who has the previous version installed, and instruct them to (1) install > dummy, (2) uninstall old main product, (3) uninstall dummy, and (4) install > new version of main product, in that order. > > Hope this helps, > Mike > > > > Arthur, Christopher wrote >> One of our custom Installer has got an CustomAction during Uninstall. >> When I try to Update this installer the Custom Action is called, but it >> fails. The CustomAction.dll could not be found. >> >> While searching within the Installation.log I've found an entry which trys >> to find the CustimAction.dll of the previous Installer at the default >> TragetDir of new one. >> How can I fix this ? > > > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Strange-Beahaviour-while-installing-previous-Version-tp7594117p7594129.html > Sent from the wix-users mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
