I've come across a project that builds an MSI package. One of the folders from that package has this name:
%P_%F_%Path%alfa
At install time, during InstallFiles standard action, Windows Installer will resolve the substring %Path% as an environment variable, thus the character ':' appears inside the folder name and the installation errors out (invalid char in folder name).
EDIT: The same error occurs for DuplicateFiles standard action too.
If I create an MSI that creates this folder empty (i.e. during CreateFolders standard action) Windows Installer does not try to resolve the substring %Path% to an environment variable and the installation succeeds, creating the folder with the name presented above.
I never met this situation before. Anybody else did? If yes, can you give more details about what is going on exactly and if there is a workaround available?
Note! I added all the tags of different MSI authoring tools because I suspect this to be a tool independent situation.
I can confirm, using WiX and IsWiX. IsWiX authors a folder with a file like this:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="MergeRedirectFolder">
<Directory Id="owd6248671CA393CCC018715A2FB53AD2D6" Name="%P_%F_%Path%alfa">
<Component Id="owcA59F51CBEAEE88B00B715AF4FEE6BF72" Guid="1619af96-1b2b-64ea-91f5-1a297c3c636a">
<File Id="owfA59F51CBEAEE88B00B715AF4FEE6BF72" Source="$(var.SourceDir)\test.txt" KeyPath="yes" />
</Component>
</Directory>
</Directory>
IsWiX authors an empty folder like this:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="MergeRedirectFolder">
<Directory Id="owd6248671CA393CCC018715A2FB53AD2D6" Name="%P_%F_%Path%alfa">
<Component Id="owc6248671CA393CCC018715A2FB53AD2D6" Guid="071c27cb-0566-40b1-9a50-5672b3fbd5e1">
<CreateFolder />
</Component>
</Directory>
</Directory>
</Directory>
Both create MSI's that compile and pass validation but the folder with a file gives the error you describe while the folder with the CreateFolder element works.
Forbidden Folder Names: Interesting, all sorts of pecularities. This is not as much an answer, as a couple of further pointers for MSI folder name peculiarities. Did you know that you can't create folder names with any of the following names in Windows Explorer? con, prn, nul, aux? The list goes on with lpt0 to lpt9 and com0 to com9.
Device References: This is all for legacy reasons. You can't make folders that have "System Action" or "Device" references. These names are old devices and legacy concepts. Device names were recognized before path names. CON was the console device, AUX was the auxiliary device, PRN was the printer, along with LPR<digit>. COM<digit> refers to a com port. There are others. Note that these names ignored the file extension such that CON.EXE or con.txt still meant the console.
Tool Handling: I believe you can still create such folders with Win32 API calls or even with a command prompt, but they are not valid Windows names allowed in Windows Explorer. Incidentally it seems Advanced Installer and Installshield allow them as MSI folder names, but you get runtime errors whilst installing - or you get a warning that a folder name is invalid on MSI launch. I understand the desire to not add code to disallow such folders in the tools - there are always new bugs possible when you start to protect against things like these - rather people should know about these folders I guess. Actually a compile time warning would be great - just a list of illegal folder names to check, and illegal character sequences. It sure is an odd problem to discover when you don't know what is causing it.
Some Links:
What characters are forbidden in Windows and Linux directory names?
Why can't we make CON, PRN,Null folder in windows?
Naming Files, Paths, and Namespaces
Sources (I copied so much from some of these, that they should be listed for reference):
Why can't we make CON, PRN, Null folder in windows? (SuperUser)
Why can't I save a folder named "con" in Windows? (Quora)
Q: why can't i create a folder with "con" name? (Microsoft Community)
Unable to rename a folder or a file as 'con' (SuperUser)
Related
I am quite new in creating setup project using .wxs file in .NET project. I knew that by default when you run MSI file it creates folder with this project and it's reference files (dll, exe, etc...) in C:\Program Files (x86). My question is, can I change this location in my .wxs file to another using XML.
ConfigurableDirectory: You can use the ConfigurableDirectory attribute of the Feature Element to set a configurable feature directory. See down the page in the screenshot section here: How to assign path value to Directory in WIX?.
Mock-up only:
Note: I am basing myself on the standard WiX Mondo dialog set. To hook up the Mondo dialogs, see this answer. Essentially, add reference to WixUIExtension.dll and insert the <UIRef Id="WixUI_Mondo" /> element. This will compile a default WiX dialog set into your MSI.
<Feature Id="MyFeature" Title="MyFeature" Level="1" ConfigurableDirectory="INSTALLFOLDER"></Feature>
<..>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="InstallDirConfigurableTesting">
Remember Property: Note that you must persist the custom directory location yourself to the registry and read back for major upgrades or else your whole product gets "moved" during upgrades (I know, it is weird). This persisting does not happen auto-magically in any way that I know about. You can persist the property and read it back using the "Remember Pattern" as described by WiX creator and benevolency Rob Mensching here: The WiX toolset's "Remember Property" pattern.
Implementation Tip: Testing the read-back of the directory property for major upgrade scenarios can be a bit fiddly. If you create a test project in Visual Studio using Votive you can use the trick to just compile version 1 of your MSI (now suffix your MSI file in the build output folder with _Version1.0.0.msi or similar), and then kick up one of the first three digits of the version number property and build an upgrade version (suffix with _Version2.0.0.msi or similar). Then you install in sequence selecting a custom installation directory and check whether your second setup correctly detects the modified path. Just use a mockup or test harness project with a single component in it to get this working, or else you could drive yourself mad if you have to compile your whole setup. Then just inject your finished markup into the main project. Obvious, yes - just mentioning.
Some Further Links:
How to use ProgramFiles64Folder in ConfigurableDirectory
What is the meaning of WiX configurable directory?
In my Product, I've defined a custom action that looks like this:
<CustomAction Id="InstallScreensaver"
Directory="SystemFolder"
Return="asyncNoWait"
ExeCommand="rundll32.exe desk.cpl,InstallScreenSaver [#screensaver]"/>
following this blog post: https://ithoughthecamewithyou.com/post/wix-tricks-for-screen-savers
But when I link it (light) I get this error:
error LGHT0094 : Unresolved reference to symbol 'Directory:SystemFolder' in section 'Product:*'.
Why is that?
On Wix's documentation of predefined variables, I can SystemFolder:
SystemFolder - gets the well-known folder for CSIDL_SYSTEMX86 on 64-bit Windows and CSIDL_SYSTEM on 32-bit Windows.
and I also create a shortcut that uses that variable:
<Shortcut Id="Shrt_Install_Screensaver"
Name="Install Screensaver"
WorkingDirectory="SystemFolder" Icon="icon.ico"
Target="[SystemFolder]rundll32.exe"
Arguments="desk.cpl,InstallScreenSaver [#screensaver]"/>
Maybe try to add SystemFolder directly underneath TARGETDIR as a first test (compiles and runs for me with a rushed mock-up):
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="SystemFolder" />
<...>
</Directory>
I think this is enough for the msiexec.exe engine to "fill in the rest", even if you don't specify a real folder name since this is one of the System Folder Properties.
I am not sure whether to call your link problem a WiX bug or not. It should probably be handled auto-magically since the folder in question is a system folder. I would go with calling it a bug or a missing piece of auto-magic.
Is your screen saver 64-bit or 32-bit? For the record System32 contains 64-bit files and SysWOW64 contains 32-bit files, but I guess you already knew that. Only in Windows...
Some links for safekeeping:
How to reference SystemFolder in WiX Icon.SourceFile property?
"SystemFolder" in WIX and C#
Why does the TARGETDIR directory need a name?
In WiX files, what does Name="SourceDir" refer to?
In Wix (3.11) there seems to be an implicit link between a with the Id 'ProgramFilesFolder' and the 'ProgramFilesFolder' variable. That is, a directory with that id will be named according to the property value.
When I try replicating this on my own with a "Test" directory:
<Property Id="Test" Value="Test"/>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="Test"/>
...
I get a warning from WiX, and the installer actually hangs. I've also tried declaring "Test" as a WixVariable, but in that case it appeared the element was simply ignored - iow, no "Test" folder was created.
My question is how does this implicit link work for WiX variables, but not for my own?
ProgramFilesFolder isn't really a WiX variable or Id. It's a Windows Installer standard property that you can't change - it refers to the 32-bit Program Files path on the system that you're installing on. Your Test directory will be beneath the Program Files folder.
There isn't enough of your WiX source to see what's going on, but just declaring those locations and properties won't create the directories if nothing is installed there. A complete working example of the issue would be useful.
You don't need to define a separate property for your directory, the id of the directory doubles as a property because directories are properties. If the property (directory id) is all uppercase, it becomes a public property, and can be set from the command line.
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="TEST" Name="Test" />
...
Setting the install path of the TEST directory from the command line:
msiexec /i A:\Example.msi TEST=c:\Example\Test /qn
The directory id "ProgramFilesFolder" is a bit different because it's one of the System Folder Properties, pre-defined by Windows Installer.
You should probably specify a name for your TEST directory. See Directory Element:
Do not specify this attribute (or the LongName attribute) if this directory represents the same directory as the parent (see the Windows Installer SDK's Directory table topic for more information about the "." operator).
I'd like to parse merge module files into two different locations. Is it possible?
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="MergeRedirectFolder">
<Component Id="LoggerClient" Guid="*">
<File Id="log4net" Name="log4net.dll" Source="..\..\_Release\log4net.dll" KeyPath='yes' />
<File Id="LoggerLibrary" Name="LoggerLibrary.dll" Source="..\..\_$(var.Configuration)\LoggerLibrary.dll" />
<File Id="app.config" Name="app.config.xml" Source="..\..\_Release\app.config.xml" />
<File Id="msvcr110.dll" Name="msvcr110.dll" Source="c:\windows\sysWoW64\msvcr110.dll" />
</Component>
</Directory>
</Directory>
</Module>
<Merge Id ="MergeModule.msm" Language ="!(loc.Lang)" SourceFile ="_$(var.Configuration)\MergeModule.msm" DiskId ="1" />
I want the second file to copy to a different folder than the other files.
There is a concept for that, it is called a retargetable merge module. I have avoided used it - the concept doesn't seem right to me. I have not tried to make one with Wix.
I think you could combine a Wix include file (simple sample) with the new auto-generated component guids to deploy such duplicated files reliably by adding an Include statement where appropriate. You must not hard code the guids in this case, but let them be auto generated by the Wix compiler and linker.
Also have a read of WixLibs (Wix library files): http://robmensching.com/blog/posts/2008/10/10/what-are-.wixlibs-and-why-would-you-use-them/
Wix documentation; http://wixtoolset.org/documentation/manual/v3/overview/files.html
Merge modules are for installing common runtimes and genuinly shared files. Typically C and C++ runtimes and other, similar libraries that should be available in the latest version for all applications.
Your files look like they are part of your application folder, with the exception of msvcr110.dll which you should remove and allow to be loaded from the system folder.
If the remaining files have no per-machine registration (COM for example or COM Interop), you can duplicate them in several folders without interference, yes, but why not load them from a shared location inside your own application folder structure?
%ProgramFiles%\My Company\My Shared Runtimes
%ProgramFiles%\My Company\My Apps\My App 1\
%ProgramFiles%\My Company\My Apps\My App 2\
These sample folders you "own" and you can deploy things here however you like. Not so for shared, system folders. You could make your own merge module for shared components between your applications into "My Shared Runtimes" and make your applications aware of the shared location "....\MySharedRuntimes\"
It depends on what you mean by different locations. You can build a merge module with 4 files, each in their own component and directory. One could go to the CommonFilesFolder; another to the SystemFolder; another to...you get the idea. So it's potentially easy if you make each file its own component in its own directory. However you've got them all under TARGETDIR, so you're going the wrong direction. You just define the other directory and that other component and file and you might be done, unless there's more to the question than meets the eye.
I would suggest contacting me privately for a few 30-60 minute conversation on MSI, component rules, Merge Modules and file set theory. It's too much to write. In a nutshell I would advise more merge modules.
WiX files always seem to include this line:
<Directory Id="TARGETDIR" Name="SourceDir">
What is "SourceDir"? What is it used for? It's not a real directory name. Is it some kind of magical value?
From: https://robmensching.com/blog/posts/2010/1/26/stackoverflow-what-does-namesourcedir-refer-to/
Honestly, it's something that we should have hidden from the developer but didn't. Sorry. The truth of the matter is that the Windows Installer expects the Directory tree to always be rooted in a Directory row where the primary key (Directory/#Id) is "TARGETDIR" and the DefaultDir column (Directory/#Name) is "SourceDir".
During an install, TARGETDIR will default to the largest drive on the machine. SourceDir will be set to the location where the MSI is being executed. Now, SourceDir is tricky after the initial install because it won't be set unless the ResolveSource action is called. However, you don't want to explicitly call the ResolveSource action because it is likely to prompt you to provide the original source media (aka: insert the CD, please).
What we should have done in the WiX toolset is remove the need to specify the TARGETDIR/SourceDir pair and say "Any Directory element that has no parent will automatically be parented to TARGETDIR because that's what the MSI SDK says to do." Instead, you have to do it yourself... and some devs wonder what it all means.
From the wix.chm documentation, topic "How To: Add a File To Your Installer":
The element with the id TARGETDIR is
required by the Windows Installer and
is the root of all directory
structures for your installation
According to the MSDN documentation TARGETDIR is
the root destination directory for the
installation
Also according to MSDN, SourceDir is
the root directory that contains the
source cabinet file or the source file
tree of the installation package
So the SourceDir property points to a real directory: the one where your MSI file sits. You can see this in the installer log when installing with msiexec /lvx* installer.log installer.msi.
However, for some reason SourceDir is completely ignored when resolving the TARGETDIR. The TARGETDIR must be either set explicitly (e.g. on the command line) or else it resolves to ROOTDRIVE. If ROOTDRIVE is not explicitly set then it is the root of the drive with the most free space.
A quick test shows that installing a component to TARGETDIR indeed puts the files at the root of my D:\ drive, instead of the folder where the MSI sits.
None of this was really helpful for me. I found this thread wondering how to make a Debug build, where my source files (the ones going in the installer) could be pulled from either the "Release" build dir or the "Debug" build dir of the project I am trying to make an installer for.
After some grepping, I found the actual path in the wixproj file, there SourceDir is defined as:
<SourceDir>$(SolutionDir)distribution\Release</SourceDir>
which has really nothing to do with installation files and project files. I was able to add another PropertyGroup that mirrored the release group which now pointed to my debug files:
<SourceDir>$(SolutionDir)distribution\Debug</SourceDir>
Hope this helps someone. I know it's a little off topic, but hopefully it helps someone in the future. Not sure why the project plug-in does not expose this value? Or am I missing that?