Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Custom burn application throws exception when accessing .NET dll when uninstalling #5308
If I uninstall the first installation manually the second installation installs without any problems.
I believe that the font exception happens because my custom dll can't access the .NET system.drawing.dll. It just happens that creating a font is one of the first things that my dll does.
When I originally moved to Wix version WiX v3.10.2 I had exactly the same exception trying to run the exe at all. The installer exe simply failed to start. After some internet searching it seemed to be related to the new security changes, specifically this change: wixtoolset/wix3#351. Updating to v188.8.131.5224 fixed the problem of the exe not starting at all, but then had the problem described above.
As far as I can work out the dll which throws the exception is my custom burn dll for the original installation. It appears that when the new installer runs the old installer to uninstall it, the old installer exe fails to start, in exactly the same way as the original problem I had with WiX v3.10.2 I.
If you want to try my installers they can be downloaded from here:
If you want to create your own application to reproduce the problem create a burn exe with a custom dll, which creates a font using system.drawing.dll. Install that, which will succeed. Then increase the version number in the burn Bundle.wxs and try installing that. The second installation will fail when it tries to uninstall the first installation.
I've attached a zip containing the two log files. They are both from the same install of FramePro_x64_setup_1_2_4_0. The larger log shows the main installer. I believe the smaller log shows the old installer running when it tries to uninstall. The log terminates because my custom burn dll throws the font exception as soon as it starts. I've also included my bundle.wxs
The machine I'm installing on is a clean Win7 SP1 install, installed on a VirtualBox VM and updated with (KB3020369) and (KB3125574).
Please let me know if there is anything else that you need.
referenced this issue
May 28, 2016
I've just checked updating an install that was built with 10.3.3007 and it does seem to work. Will the fix that was made only apply to updating installs that were made 10.3.3007? For people who have installed my product with v184.108.40.20624, they are still going to be hit by the problem when they upgrade to the fixed version. Is there any way around this?