-
Notifications
You must be signed in to change notification settings - Fork 176
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
The directory Id generated can be too long #1244
Comments
Unfortunately, this cannot be a good choice of behaviour as it implies that the path of the folder consists only of unique names. If it is a problem in your case I suggest you assign IDs explicitly in the constructor. |
... Not really it's done like that with the default gen for other objects already. |
Actually, you are right. The id-algorithm in question was a legacy routine that was designed a long time ago and the later phase of id-generation simplification accidentally overlooked I have fixed it on b64ae4e. To ensure a minimal impact the old id-generation algorithm is also available via The new behaviour: var project =
new ManagedProject("My Product",
new Dir(@"%ProgramFiles%\My Product",
new File("myapp.cs"),
new Dir("bin",
new Dir("help",
new Dir("settings",
new Dir("icons"),
new Dir("settings",
new File("myapp.exe"))))))); <Directory Id="bin" Name="bin">
<Directory Id="help" Name="help">
<Directory Id="settings" Name="settings">
<Directory Id="icons" Name="icons">
</Directory>
<Directory Id="settings.1" Name="settings">
</Directory>
</Directory>
</Directory>
</Directory> The old behaviour with <Directory Id="INSTALLDIR.bin" Name="bin">
<Directory Id="INSTALLDIR.bin.help" Name="help">
<Directory Id="INSTALLDIR.bin.help.settings" Name="settings">
<Directory Id="INSTALLDIR.bin.help.settings.icons" Name="icons">
</Directory>
<Directory Id="INSTALLDIR.bin.help.settings.settings" Name="settings">
</Directory>
</Directory>
</Directory>
</Directory>
|
Marvelous |
- Issue #1244: The directory Id generated can be too long - Issue #1223: Non LegacyDummyDirAlgorithm creates C:\ProgramFilesFolder empty folder - Issue #1220: ElevatedManagedAction issue - Feature #1204: Feature - RegisterCom class to ease the registration of COM files - Issue #1203: SilentBootstrapperApplication - Issue #182 (extended solution): RegistrySearch has "Win64=no" when building x64 installers - Added Self-executable_Msi sample - Added WixBootstrapper_EmbeddedUI to demonstrate how to show managed UI if the bundled MSI - Added sample for customization of the stock Burn UI. Triggered by #1219 - Added sample for "Issue #1218: Dynamic custom UI sequence" - Resurrected setting user input from BA UI and passing it to the msi. RegistrySearch input is also retained. - Added validation for `Issue #1075: [FEAT] Add error if LaunchApplicationFromExitDialog using in common Project` error. - Fixed problem with RegKey being placed in the x86 root XML dir for the x64 project
After couple directories in the path the Dir ID becomes too long, breaking reference counting and stuff.
It should default to something like:
Dir.{Name}(.{Number})
Example:
Before -
CommonAppDataFolder.SomeLongDomainName.SomeLongApplicationName.Settings
After -
Dir.Settings
wixsharp/Source/src/WixSharp/Compiler.cs
Line 3445 in 5f8508a
The text was updated successfully, but these errors were encountered: