Cannot run standard VS.NET web install when darked to WIX.

[wixbot]

Create a standard .NET Web Setup project to deploy a web service. Dark it and the candle and light it. Run the installer. It fails. When I logged the results and looked more carefully, the following was recorded:

Action start 8:15:40: CreateFolders. Action ended 8:15:40: CreateFolders. Return value 1. MSI (s) (34:A8): Doing action: WEBCA_GatherWebFolderProperties MSI (s) (34:A8): Note: 1: 2205 2: 3: ActionText Action start 8:15:40: WEBCA_GatherWebFolderProperties. MSI (s) (34:A8): Creating MSIHANDLE (123) of type 790542 for thread 3496 DEBUG: Error 2769: Custom Action WEBCA_GatherWebFolderProperties did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: WEBCA_GatherWebFolderProperties, 1, Action ended 8:15:41: WEBCA_GatherWebFolderProperties. Return value 3.

The installer created by VS.NET works. If you comment out the WEBCA_GatherWebFolderProperties custom action in the execution sequence, it works but does not record web properties for the virtual folder.

bq. Originally opened by @jjdajadams@ from "http://sourceforge.net/p/wix/bugs/104/":http://sourceforge.net/p/wix/bugs/104/

[wixbot]

Ah I see this has been closed. I think an opportunity might have been missed if at least some documentation isn't produced as a resolution to this bug.

I think many people will approach WiX for the first time by decompiling a Visual Studio generated msi file. They will then use candle/light to recreate the msi and expect it to work just like the original. In my opinion, Dark should strive to achieve that even if it generates non-optimised/non-perfect source code.

The two known issues that have prevented this in the past are non-preservation of empty custom tables and non- preservation of explicit sequence numbers. If the E switch preserves the custom tables and now the Z switch preserves the explicit sequence numbers then the barrier to achieving this has been removed.

In my opinion, this bug could be legitimately closed simply by documenting, in WiX, the recommendation that the E and Z switches should always be used when decompiling Visual Studio generated msi files. I haven't studied the operation of the VSI switch but hopefully that doesn't remove stuff that would break a clean dark/candle/light cycle. It would be useful if the specifics of what the VSI switch does could be documented in WiX as well.

A further possibility is for Dark to automatically detect that it is decompiling a Visual Studio msi file and engage the E and Z switches automatically. I'm sure a Visual Studio msi file has characteristics that make it detectable. This would cater for those people who don't read the proposed documentation at the cost of making Dark very slightly 'Visual Studio specific'.

I hope this helps to think through the solution approach for this bug.

[wixbot]

Given the comment says the problem here is a missing table, and the -e switch will preserve a missing custom table, that is the expected workaround.

Generally, the work done by a VSI package is non- transaparant (at least for me) so adding extra switches to get a better decompile is the expected path.

The VSI switch does try to purge some known problems (launch conditions) but there is no clear path right now to doing a full conversion to WiX based constructs (specifically the WiX server custom actions rather than the VSI custom actions)

[wixbot]

Thanks for the observations ferrysoft.

The proposition described here (I call 'roundtripping' or sometimes 'dawn') is legitimate evolution of expectations but different than the original role envisioned for Dark: fire once with the expectation all decomilations will require hand tweak.

I've been cautious setting this level of expectations as my mastery of commercial solutions (VSI, InstallShield, Wise, ZeroG) is limited (mainly by time). Writing out blank tables by default is an approach I'll have to avoid because a key differentiator in WiX is building clean and correct MSIs. From my dark work to date, far too many authoring tools overrepresent the tables in the MSI which bloats the binary and makes for confusing XML when decompiled, particularly for the uninitiated.

This is not the only instance that users are expecting roundtrip to "just work" as the fact the -x switch is off by default has tripped up a number of folks recently.

I'll continue to think more about this and look for opportunities to improve the roundtripping fidelity when a WiX user starts with Dark.

Thanks again.

[wixbot]

Example file

[wixbot]

On the face of it, this looks like another example of dark not preserving sequencing information when decompiling VS.NET originated .msi files. In other words, this is a specific case of bug 935799 and so a resolution is dependent on resolving that issue first.

However, there is an additional issue with VS.NET web installs in that the custom table _AppMappings isn't being extracted to the .wxs file because it is empty in the original .msi file. This missing table triggers the error condition described above. One solution is to add the following manually to the .wxs file to ensure the table is created:

I don't know whether the -e option of dark extends to custom tables but it might be worth trying to see if the above source would be created automatically.

It is difficult to see how a future version of dark could resolve this issue other than doing something special with VS.NET web installs or possibly encapsulating the above in some documentation.

[wixbot]

Thanks for the observations ferrysoft.

The proposition described here (I call 'roundtripping' or sometimes 'dawn') is legitimate evolution of expectations but different than the original role envisioned for Dark: fire once with the expectation all decomilations will require hand tweak.

I've been cautious setting this level of expectations as my mastery of commercial solutions (VSI, InstallShield, Wise, ZeroG) is limited (mainly by time). Writing out blank tables by default is an approach I'll have to avoid because a key differentiator in WiX is building clean and correct MSIs. From my dark work to date, far too many authoring tools overrepresent the tables in the MSI which bloats the binary and makes for confusing XML when decompiled, particularly for the uninitiated.

This is not the only instance that users are expecting roundtrip to "just work" as the fact the -x switch is off by default has tripped up a number of folks recently.

I'll continue to think more about this and look for opportunities to improve the roundtripping fidelity when a WiX user starts with Dark.

Thanks again.