Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wix V4 Merge Module IDs are restricted by Windows restricted file names #7783

Open
MddMBorg opened this issue Oct 13, 2023 · 0 comments
Open
Assignees
Labels
Milestone

Comments

@MddMBorg
Copy link

Bugs

If this issue is a bug:

  • Which version of WiX are you building with?

Wix Toolset 4.0.2

  • Which version of Visual Studio are you building with (if any)?

VS 2022 17.6.5

  • Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?

Heatwave for VS2022 V 1.0.1 (also have Wix v3 - Visual Studio 2022 Extension V 1.0.0.22 installed)

  • Which version of .NET are you building with?

4.8

  • If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?

N/A: Can't build the package

  • Describe the problem and the steps to reproduce it.
  • Create a Merge module in either Wix v3 or Wix v4 (Default Merge Module project template from Heatwave extension is fine)
  • Create a Package using Wix v4 (Default package project template from Heatwave extension)
  • Build the MSM in the merge module project and copy the output .msm into the Package project files
  • Add the following lines to the Package.wxs in the Package project:
<DirectoryRef Id="INSTALLFOLDER">
			<Merge Id="COM1" Language="1033"  SourceFile="{MergeModuleName}.msm" />
		</DirectoryRef>

		<Feature Id="Main">
			<MergeRef Id="COM1" />
			<ComponentGroupRef Id="ExampleComponents" />
		</Feature>
  • Build the package, the following error will result:
    WIX0001 System.IO.FileLoadException: The system cannot open the device or file specified.
  • Describe the behavior you expected and how it differed from the actual behavior.

The package should build without issue

Wix V3 did not have this issue, I could give the Merge element any ID without issue.
Using V4, if I have build output set to Detailed, I can see the exact issue (mergemod.dll call to IMsmMerge2::ExtractCAB) which fails, producing the output:
WIX0001 System.IO.FileLoadException: The system cannot open the device or file specified. (Exception from HRESULT: 0x8007006E) Package1 C:\Users\MichaelMassiah\source\repos\ConsoleApp2\Package1\wix.exe 1
which throws with a stack trace :

1>       at WixToolset.Core.Native.Msm.IMsmMerge2.ExtractCAB(String fileName)
1>       at WixToolset.Core.WindowsInstaller.Bind.ExtractMergeModuleFilesCommand.ExtractFilesFromMergeModule(IMsmMerge2 merge, WixMergeSymbol wixMergeRow) in D:\a\wix4\wix4\src\wix\WixToolset.Core.WindowsInstaller\Bind\ExtractMergeModuleFilesCommand.cs:line 200
1>       at WixToolset.Core.WindowsInstaller.Bind.ExtractMergeModuleFilesCommand.Execute() in D:\a\wix4\wix4\src\wix\WixToolset.Core.WindowsInstaller\Bind\ExtractMergeModuleFilesCommand.cs:line 78
...

I'm guessing V3 has a different way to extract the msm file which doesn't have this issue. Looking at source for V4, the command uses the Id to create the file name of the cab to extract to, so "COM1.cab".

I think it's fine if there are restricted IDs in this case, but Wix should notify the user of an illegal/restricted Merge ID.

Context: I noticed this after upgrading one of our projects from V3 to V4. The "COM1" Merge module is a merge module we use for our COM objects (dlls exes etc), hence the ID COM1. This never caused an issue with V3 for us. I only managed to fully resolve the issue while writing up the repro steps here and changing the ID.

Extra context: list of restricted file names in Windows : https://learn.microsoft.com/en-gb/windows/win32/fileio/naming-a-file#naming-conventions

@barnson barnson added binder and removed triage labels Oct 17, 2023
@barnson barnson added this to the v5.0.0-preview.1 milestone Oct 17, 2023
@robmen robmen modified the milestones: v5.0.0-rc.1, v.Future Mar 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants