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.
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'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.
I'm trying to get IDEA to recognize its own workspace, project and module files as XML files so that I can expand/collapse tags. However, when I try to modify the XML file type to add any of those extensions, IDEA complains that those are reserved. Now, if it knows about those extensions, why doesn't it let me expand/collapse tags? Is there a way to do that?
The support for tag expand/collapse is just not there, because these files are not supposed to be edited (or frequently viewed) by people, it's just some internal information. If you have a specific use case when it's really needed, please describe it in a new issue at http://youtrack.jetbrains.com/dashboard
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.
From this page,
http://www.yiiframework.com/wiki/23/how-to-create-a-breadcrumb-widget/
It seems it suggests that we should put the files in the component folder. But if my widget contains javascript and css files, where should these files be placed?
By the way, is this a good idea that I create it as an extension? If I go this way, all widget files are more self-contained in a folder inside the extension folder. But since the widget I am going to work on is very customized, it's unlikely that it will be useful to other people or my other projects. Making it an extension seems a little bit strange.
I understand that it does not really matter where I put these files as long as the paths I am using in the codes are correct but I would like to know the common practice.
I think the common practice is to put the widget in extensions folder with js & css files in an folder named asset. In the php class file, you do initialization first by publishing the asset with yii asset manager.
The file structure may be like
extensions/
widget_name/
widget.class.php
assets/
plugin.js
style.css
I would join the recommendation to put the widget under /protected/extensions.
I put the assets in a slightly more detailed manner: /protected/extensions/WidgetClassName/assets/ and the widget view files in /protected/extensions/WidgetClassName/views/...
Don't forget to edit your /protected/config/main.php and add a row in the 'import' section (for autoloading of the widget): 'ext.WidgetClassName.WidgetClassName.*'