I'm using wix 3.8 in Visual Studio 2010.
If I have 2 components in a fragment in a wxs file and I only reference one of them in a feature I get an ICE21 error that there are components that are not used.
If I have a wxs file with components where none of the components are part of a feature I get no error, the components are just silently skipped.
Is this the desired behaviour? Is there a way to force an error message in this case?
The reason I'm asking is that I plan to use wix to create an installer where the developers themselves are reponsible for adding new files and components to the installer. It would be nice to have a way to make sure that they (we) didn't forget to include the new components in a feature.
Fragment description from the documentation, I highlighted the part where it should answer your question:
The Fragment element is the building block of creating an installer
database in WiX. Once defined, the Fragment becomes an immutable,
atomic unit which can either be completely included or excluded from a
product. The contents of a Fragment element can be linked into a
product by utilizing one of the many *Ref elements. When linking in a
Fragment, it will be necessary to link in all of its individual units.
For instance, if a given Fragment contains two Component elements, you
must link both under features using ComponentRef for each linked
Component. Otherwise, you will get a linker warning and have a
floating Component that does not appear under any Feature.
So, if any Component is referenced into a Feature then the complete Fragment with all its Components will be pulled into build and give you a warning/error that you have orphan component(s).
In your first case you have two components in a same fragment and you referenced only one and got an error about the second component.
If you have a fragment with many components and you don't reference any of them then Wix will not read that fragment at all.
In your second case all your components are in the same fragment but none of the components are referenced into a Feature therefore there are no errors as that fragment is not used at all.
Related
I am using Wix installer for an application and one of the scenarios I am trying to handle is changes to a .config file when the application is upgraded.
Essentially, I would want to add an Xml Element within another Xml Element.
For instance, the original .config file that was shipped with application looked like this
<root-element>
<sub-element-1/>
<sub-element-2/>
</root-element>
During app lifetime, it was updated to as below at some point.
<root-element>
<sub-element-0/>
<sub-element-1/>
<sub-element-2/>
</root-element>
For handling this case , where I need to add <sub-element-0/> under <root-element>, I tried this Wxs code.
<util:XmlFile Id="MyConfig"
File="[fileidOfMyConfigFile]"
Action="createElement"
Name="sub-element-0"
ElementPath="root-element"
Sequence="1"/>
The above formulation does add the sub-element-0 under root-element , however as the last item under the root-element.
like so
<root-element>
<sub-element-1/>
<sub-element-2/>
<sub-element-0/>
</root-element>
I couldn't find any resources on adding it as first element as I want it to be.
Any suggestions on how it could be accomplished?
Note: The above is a simplified version of my use case. The reason order is important in my case is due to a limitation on the framework that some elements need to occur before other elements in the .config
I am creating a WIX template for my projects to ensure a relatively standard layout.
I have defined a variable to reference the Main Application using <?define MainApp="MyApp"?> where MyApp is the name of the referenced project. I then use the MainApp variable to reference the project's properties in the .wxs and .wxi files.
However, I have an issue when referencing nested properties.
$var.($(var.MainApp).ProjectName) expands to "MyApp" without issue.
$var.($(var.MainApp).ProjectDir)Resources\Main.ico expands to $var.(MyApp.ProjectDir)Resources\Main.ico
$var.($(var.MainApp).TargetPath) expands to $var.(ConsoleApplication1.TargetPath)
etc...
My aim is to create a single definition for my main application, thus eliminating a search/replace, which I find clunky.
As you've found, nested preprocessor variables are not supported by the WiX toolset today.
In our WIX installer project, we need to generate a new file, let's call it FileB, based on a deployed file, called FileA in a managed custom action function. In another word, in the component declaration, I declare the FileA. While in a custom action (which happens at commit phase), I need to generate FileB based on FileA. After that, since FileA is no use anymore, I want to delete it in the same custom action.
And here comes the problem: with the default installation folder, which is Program Files, the normal user is not allowed to add file (generate FileB) into this folder in the custom action (I am not 100% sure I am right, but it is the case in my test. And if I install it in another folder, there is no problem at all). So I think I need to give permission of creating file. In order to do that, I add a CreateFolder element to the component which includs FileA. The whole component declaration is something like this:
<Component Id='COMPONENT_NAME' Guid='MY_GUID'>
<!--OTHER FILES IN THE COMPONENT-->
...
<CreateFolder Directory='INSTALLDIR'>
<Permission CreateFile='yes' User='Everyone' GenericAll='yes' Delete='yes'/>
</CreateFolder>
<File Id='MyFileA' Name='FileA' Source='PATH_TO_FILEA' KeyPath='no' >
<Permission GenericAll='yes' User='Everyone' Delete='yes'/>
</File>
</Component>
The component actually belongs to a component group, which resides in INSTALLDIR. The reason there is other files in the same component element is because I want another File to be the keypath, so that deleting FileA would not cause a problem of that. And now the generation of FileB is working fine. But later in the same custom action, I am experiencing the problem when deleting FileA. It just says that ": Access to the path 'DEPLOYMENT_PATH_TO_FILEA' is denied." I thought the problem lies in the FileA declaration, that's why I added the Delete='yes' in the Permission element under File, hoping to make it OK to delete it (although I am not sure whether this means in the installation it is possible to delete). But still I get this error. Can anyone tell me what I did wrong?
Another question is, I really don't know what is the purpose of those CreatFolder elements. For one thing: if the aim is to create the directory structure, I think the (nested)Directory elements already do that. And why to have such element under Component element when most of the time you probably want the directory structure to be separated with component structure(the components just use directory reference to refer to correct directory). Secondly, the default Directory property of CreateFolder is the parent Directory where the component resides in. But it is common that more than one components reside in the same directory, like what I have here: multiple components are in the same component group, whose directory element references to INSTALLDIR. So only one of these components has the CreateFolder element, whose Directory property in my case is the parent directory of all those components. It is really hard to understand this structure. I guess I have some misunderstanding of the CreateFolder element. Can someone enlighten me to usage of CreateFolder? Thanks!
Thanks!
A number of issues to address here. First, you should know that Commit phase custom actions don't execute if rollback is disabled. You should really have an deferred and rollback custom action.
Second, you can't tell MSI to install a file and then go delete it. That's counterproductive and just causes servicing issues down the road. A better solution ( I'm assuming you are using a WiX DTF managed custom action ) is to include FileA as a content item in the custom action project. This will cause the file to exist in the current (temp) directory of the custom action while it execute. You can then generate fileb. For rollback, you can delete fileb.
You'll also need to author a RemoveFile element to teach MSI to delete the file on uninstall. Otherwise it won't since MSI doesn't know anything about fileb created by your out of process custom action.
Otherwise it'd be useful to know what the contents of fileb are. It would be easier to implement if this was an xml file that could be installed as fileb and then transformed using the xml wix extension.
So I thought it'd be clever of me to split my WIX file up into various smaller files. I did this for a couple reasons. One being that it would make it easier to maintain. Anyway, regardless of my reason, I put the components in one file. But when I compile, I now get a warning that says:
warning LGHT1079: The cabinet 'media1.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please add files to the cabinet or remove it.
Now the Media element is in the main wix file and all of my File components have a DiskId that matches. So I thought I'd just stick the Media element in the same fragments as where I define my components. No dice. I get a warning that says that the installer has no media.
So do I have to define all of my components in the same file? Or am I missing something?
I figured out what I did wrong. I also put the features in a separate file. I needed to add a FeatureRef tag for each feature within the product tag.
Your Feature elements will need ComponentRef or ComponentGroupRef elements to associate the components to the features.
I have never worked with plug-in fragments before. I thought that by creating a new class within a fragment and exporting the package that contains it in the fragment's manifest, I'd be able to access that class from another plug-in that already has a dependency on the host plug-in. However, I cannot seem to make this work. Are the contents of a fragment ever visible to any plug-in besides the host plug-in? If so, is there something special I have to do to allow this?
The problem is not, that the contents of the fragment aren't visible to another plugin: They are - just try loading e.g. a properties file from the classpath, it still works if that properties file is provided by the fragment.
But what you don't have, is compile-time information about the fragment's contents. That's the principle of a fragment: You can't have a dependency on it. And you don't know, if somebody has fragments installed or not.
It's also not only a problem that just "any plug-in besides the host plug-in" has. It's a problem, that even the host-plugin itself has. It doesn't know about the fragment's existence at compile-time.
You also can't reliably use a fragment to override parts of the host plug-in's classes: FAQ Can fragments be used to patch a plug-in? , if that's what you want to do. The page also describes, how it can be done.
Hope this helps.