Can WiX be set to automatically include all generated satellite assemblies?
The goal is to have a single English language MSI that installs an application with localized strings available for ~10 languages.
I found this existing SO quetsion:
How do I include Satellite Assemblies(Localized Resources) in an MSI built with WiX?
However that solution suggests that new component and directory definitions needs to be manually added for each culture variant.
Is that the only way, or can WiX somehow automatically learn about each language from the Visual Studio project definitions?
(Running VS2010 and WiX 3.8)
You can use HarvestDirectory task to automatically collect files to be included in installer. You just need to point it to folder with your satellite assemblies and on each build of installer - target folder will be rescanned and file list will be regenerated.
For example:
1) Place in .wixproj harvest task inside beforedBuild target (it will be commented by default)
<Target Name="BeforeBuild">
<HeatDirectory OutputFile="SatelliteAsm_Files.wxs" Directory="$(SolutionDir)PathToYourAssemblies" DirectoryRefId="MODULELOCATION" ComponentGroupName="Modules" SuppressCom="true" SuppressFragments="true" SuppressRegistry="true" SuppressRootDirectory="true" AutoGenerateGuids="false" GenerateGuidsNow="true" ToolPath="$(WixToolPath)" PreprocessorVariable="var.ApplicationModuleDir" SuppressUniqueIds="True" />
2) Build your installer first time. After that you will find SatelliteAsm_Files.wxs file inside your WIX project. It will have structure similar to this:
<Fragment>
<DirectoryRef Id="DIRVARIABLE">
<Directory Id="dir8B97956DEA791D69AB336941C9163652" Name="x64">
<Component Id="cmpE72E1056FC8A2AE97260E772A6386763" Guid="{481FF1F3-7AFF-4C17-9AE0-5347BEEB3726}">
<File Id="filACCD137532BB3AE1F4B3BC207018585B" KeyPath="yes" Source="$(var.ApplicationLibDir)\x64\name.txt" />
</Component>
...
<Fragment>
<ComponentGroup Id="GroupName">
<ComponentRef Id="cmpE72E1056FC8A2AE97260E772A6386763" />
...
3) Add it as link (it's important you don't want source control to set this file to read only, coz WIX will fail on build) to your project.
4)Reference this ComponentGroup in any of your features
<Feature Id="MyFeauture">
<ComponentGroupRef Id="GroupName" />
Finally it's ready! Now files collected from folder you specified in harvest task will be included in your installer. But don't expect this to work out of box because it's royal pain to setup this and you may need to try different combinations of task keys or even XSD transformations to leave only needed files (yes WIX can do XSD transforms, and no there is no easy and agile way to filter files or folder harvested by WIX)
Note: you can use it not only for satellite assemblies - it's ok to harvest entire bin, 3rd party libs or whatever you want, so you don't need to update installer project by hand every time you add new assembly to your solution.
Related
this is my situation:
I have VS2010 solution with X projects included.
Wix project that can create msi from all compiled artifacts.
I have build machine \ Jenkins that first compile (MSBuild .Net 4) all the solution, then compile the wix to package it to msi.
What\how can I inject to all artifacts\dlls the number of the product (e.g 11.2.0.4789) - as simple as possible?
Is there and command line arguments that can be passed while compiling the solution?
There are tools, such as several extensions for MSBuild, that do version stamping but each assumes a particular workflow. You might find one that works for you but a DIY method would help you evaluate them, even if it isn't your final solution.
You can add a property to the MSBuild command-line like this:
msbuild /p:VersionStamp=11.2.0.4789
Note: I assume you are going to parameterize the Jenkins build in some way or generate the number during a preceding build step. Here is a simulation of that:
echo 11.2.0.4789 >version.txt
set /p version=reading from pipe <version.txt
msbuild /p:VersionStamp=%version%
Now, the work is in getting each project to use it. That would depend on the project type and where you want VersionStamp to appear.
For a csproj, you might want to use it as the AssemblyVersion. The simplest way is to move the attribute to a cs file by itself and rewrite it every time. I would leave a comment in AssemblyInfo.cs as a clue to where it now comes from. You can include the cs file in your project either dynamically or permanently. I prefer dynamically since it is effectively an intermediate file for the build. So, in your .csproj add the following in a text editor (e.g. Visual Studio. Unload and Edit project):
<Target Name="BeforeBuild">
<PropertyGroup>
<AssemblyVersionPath>$(IntermediateOutputDir)AssemblyVersion.cs</AssemblyVersionPath>
</PropertyGroup>
<ItemGroup>
<Compile Include="$(AssemblyVersionPath)" />
</ItemGroup>
<WriteLinesToFile
File='$(AssemblyVersionPath)'
Overwrite="true"
Condition="'$(ProductVersion)' != ''"
Lines='using System.Reflection%3b;
[assembly: AssemblyVersion("$(VersionStamp)")]' />
</Target>
This is sufficient but a more thorough solution would include adding the file to a list so it is cleaned with other files and only writing the file if the version changed to prevent unnecessary rebuilds, etc.
Use a similar technique for other project types.
The Microsoft AJAX Minifier provides a build task which can be used in TFS or local build definitions.
I have succsfully used this in both a local project file (building to seperate files) and in TFS build definitions (overwriting the existing JS files).
I'd like to move to using Visual Studio 2010's 1-click publish feature rather than a TFS build definition, however adding the minification task as an AfterBuild target in the project file doesn't appear to effect the 1-click publish feature.
Using information found in this thread and these articles, I tried creating a file named '[ProjectName].wpp.targets in my WAP root directory, and used the following XML:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\Microsoft\MicrosoftAjax\ajaxmin.tasks" />
<Target Name="Minify" BeforeTargets="MSDeployPublish">
<ItemGroup>
<JS Include="**\*.js" Exclude="**\*.min.js;**\*vsddoc.js;**\*debug.js" />
</ItemGroup>
<ItemGroup>
<CSS Include="**\*.css" Exclude="**\*.min.css" />
</ItemGroup>
<AjaxMin JsSourceFiles="#(JS)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".min.js" CssSourceFiles="#(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".min.css" />
</Target>
</Project>
This doesn't appear to have any effect, and unfortunately Visual Studio doesn't give much in the way of feedback or debugging info for these tools.
Has anyone had any success minifying JavaScript / CSS using the Visual Studio 2010 1-click publish feature?
I just wrote a detailed blog entry on how to do this at
http://sedodream.com/2011/02/25/HowToCompressCSSJavaScriptBeforePublishpackage.aspx and http://blogs.msdn.com/b/webdevtools/archive/2011/02/24/how-to-compress-css-javascript-before-publish-package.aspx.
Here are the contents
Today I saw a post on stackoverflow.com asking Using Microsoft AJAX Minifier with Visual Studio 2010 1-click publish. This is a response to that question. The Web Publishing Pipeline is pretty extensive so it is easy for us to hook in to it in order to perform operation such as these. One of those extension points, as we’ve blogged about before, is creating a .wpp.targets file. If you create a file in the same directory of your project with the name {ProjectName}.wpp.targets then that file will automatically be imported and included in the build/publish process. This makes it easy to edit your build/publish process without always having to edit the project file itself. I will use this technique to demonstrate how to compress the CSS & JavaScript files a project contains before it is published/packaged.
Eventhough the question specifically states Microsoft AJAX Minifier I decided to use the compressor contained in Packer.NET (link in resources section). I did this because when I looked at the MSBuild task for the AJAX Minifier it didn’t look like I could control the output location of the compressed files. Instead it would simply write to the same folder with an extension like .min.cs or .min.js. In any case, when you publish/package your Web Application Project (WAP) the files are copied to a temporary location before the publish/package occurs. The default value for this location is obj{Configuration}\Package\PackageTmp\ where {Configuration} is the build configuration that you are currently using for your WAP. So what we need to do is to allow the WPP to copy all the files to that location and then after that we can compress the CSS and JavaScript that goes in that folder. The target which copies the files to that location is CopyAllFilesToSingleFolderForPackage. (To learn more about these targets take a look at the file %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets.) To make our target run after this target we can use the MSBuild AfterTargets attribute. The project that I created to demonstrate this is called CompressBeforePublish, because of that I create a new file named CompressBeforePublish.wpp.targets to contain my changes.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="SmallSharpTools.Packer.MSBuild.Packer"
AssemblyFile="$(MSBuildThisFileDirectory)..\Contrib\SmallSharpTools.Packer\SmallSharpTools.Packer.dll" />
<!-- This target will run after the files are copied to PackageTmp folder -->
<Target Name="CompressJsAndCss" AfterTargets="CopyAllFilesToSingleFolderForPackage">
<!-- Discover files to compress -->
<ItemGroup>
<_JavaScriptFiles Include="$(_PackageTempDir)\Scripts\**\*.js" />
<_CssFiles Include="$(_PackageTempDir)\Content\**\*.css" />
</ItemGroup>
<Message Text="Compressing JavaScript files" Importance="high" />
<!--
Compress the JavaScript files.
Not the usage of %(JavaScript.Identity which causes this task to run once per
.js file in the JavaScriptFiles item list.
For more info on batching: http://sedotech.com/resources#Batching
-->
<Packer InputFiles="%(_JavaScriptFiles.Identity)"
OutputFileName="#(_JavaScriptFiles->'$(_PackageTempDir)\Scripts\%(RecursiveDir)%(Filename)%(Extension)')"
Mode="JSMin"
Verbose="false"
Condition=" '#(_JavaScriptFiles)' != ''" />
<Message Text="Compressing CSS files" Importance="high" />
<Packer InputFiles="%(_CssFiles.Identity)"
OutputFileName="#(_CssFiles->'$(_PackageTempDir)\Content\%(RecursiveDir)%(Filename)%(Extension)')"
Mode="CSSMin"
Verbose="false"
Condition=" '#(_CssFiles)' != '' "/>
</Target>
</Project>
Here I’ve created one target, CompressJsAndCss, and I have included AfterTargets=”CopyAllFilesToSingleFolderForPackage” which causes it to be executed after CopyAllFilesToSingleFolderForPackage. Inside this target I do two things, gather the files which need to be compressed and then I compress them.
1. Gather files to be compressed
<ItemGroup>
<_JavaScriptFiles Include="$(_PackageTempDir)\Scripts\**\*.js" />
<_CssFiles Include="$(_PackageTempDir)\Content\**\*.css" />
</ItemGroup>
Here I use an item list for both JavaScript files as well as CSS files. Notice that I am using the _PackageTempDir property to pickup .js & .css files inside the temporary folder where the files are written to be packaged. The reason that I’m doing that instead of picking up source files is because my build may be outputting other .js & .css files and which are going to be published. Note: since the property _PackageTempDir starts with an underscore it is not guaranteed to behave (or even exist) in future versions.
2. Compress files
I use the Packer task to compress the .js and .css files. For both sets of files the usage is pretty similar so I will only look at the first usage.
<Packer InputFiles="%(_JavaScriptFiles.Identity)"
OutputFileName="#(_JavaScriptFiles->'$(_PackageTempDir)\Scripts\%(RecursiveDir)%(Filename)%(Extension)')"
Mode="JSMin"
Verbose="false"
Condition=" '#(_JavaScriptFiles)' != ''" />
Here the task is fed all the .js files for compression. Take a note how I passed the files into the task using, %(_JavaScriptFiles.Identity), in this case what that does is to cause this task to be executed once per .js file. The %(abc.def) syntax invokes batching, if you are not familiar with batching please see below. For the value of the output file I use the _PackageTempDir property again. In this case since the item already resides there I could have simplified that to be #(_JavaScriptFiles->’%(FullPath)’) but I thought you might find that expression helpful in the case that you are compressing files which do not already exist in the _PackageTempDir folder.
Now that we have added this target to the .wpp.targets file we can publish/package our web project and it the contained .js & .css files will be compressed. Note: Whenever you modify the .wpp.targets file you will have to unload/reload the web project so that the changes are picked up, Visual Studio caches your projects.
In the image below you can see the difference that compressing these files made.
You can download the entire project below, as well as take a look at some other resources that I have that you might be interested in.
Resources
http://sedotech.com/content/samples/CompressBeforePublish.zip
http://sedotech.com/resources#batching
MSBuild BeforeTargets/AfterTargets
WebDeploymentToolMSDeployHowToExcludeFilesFromPackageBasedOnConfiguration.aspx
Packer.NET
For this to work in visual studio 2015, we have to change the "AfterTarget" from
<Target Name="CompressJsAndCss" AfterTargets="CopyAllFilesToSingleFolderForPackage">
to the following
<Target Name="CompressJsAndCss" AfterTargets="PipelineCopyAllFilesToOneFolderForMsdeploy">
enjoy!!
I'm using the project reference feature of WiX to harvest a project automatically using Heat. This is particularly useful since the WiX installer is being built both locally and on a TFS2010 build server, and when it's built on the build server the output is redirected to a different location meaning that if I don't automatically harvest the projects, it gets very messy trying to reference the correct location for recently compiled items.
I have the following WiX "code" to install and start the service:
<ServiceInstall Id="MyService"
Type="ownProcess"
Vital="yes"
Name="MyServiceName"
DisplayName="My Service Display Name"
Description="My Service Description"
Start="auto"
Account="[SERVICEACCOUNT]"
Password="[SERVICEPASSWORD]"
ErrorControl="ignore"
Interactive="no" />
<ServiceControl Id="StartService" Name="MyServiceName" Start="install" Wait="no" />
<ServiceControl Id="StopService" Name="MyServiceName" Stop="both" Wait="yes" Remove="uninstall" />
So far, so good... I get a problem when the installer tries to install and start the Windows Services however saying "Service 'MyServiceName'(MyServiceName) failed to start. Verify that you have sufficient privileges to start system services". If I choose the "Ignore" button, the installation completes "successfully", but when I check the services installed on my machine, the new service isn't listed.
From my investigations online, I believe that the problem is that the service isn't actually getting installed correctly because I need to set the KeyPath to the executable that should be run as the service, but since I am harvesting the files using Heat, I can't find a way to do this... unless I create a custom action which will install the service for me allowing me to specify the executable name once all the files have been installed... but that doesn't sound like it should be the right solution...
Does anyone have any advice or have they encountered the same problem and come up with a solution?
Thanks
UPDATE 07/10/10: In my WiX script, I have the following:
<Directory Id="INSTALLLOCATION" Name="Dolphin Transfer Service Server" ComponentGuidGenerationSeed="AF89976D-CD66-4b94-911B-1D27F969BC14">
<Component Id="ServiceComponent" Guid="F55415F7-803C-4a83-A677-C0F882699374">
<ServiceInstall Id="DolphinTransferService" Type="ownProcess"...
and the target directory for my harvested files is the INSTALLLOCATION directory.
Looking at the msi using Orca, I can see my ServiceComponent and all the generated components for each harvested file. Looking in the File table, there are no files associated with this component (since they have a component generated for each file...). Looking in the ServiceInstall table, the component that it is trying to install is ServiceComponent.
So I think that I need to somehow get the ServiceInstall element to be inside the component that is generated for the service exe so that it installs this component as a service and not the empty "ServiceComponent" component? But since this component is generated at build time by heat I've not managed to make any further progress...
The output of heat is a WXS authoring with one file per component. This is the default behavior and can't be changed using standard heat switches. This was done to natively follow the component rules.
If a component contains a single file, this file is automatically a KeyPath. Hence, if you don't transform the output of heat and keep to the rule "one component - one file", this must not be the reason of the error you get.
I would suggest investigating the verbose log and see if it contains more detailed description of the failure you face with.
I have some content files that I would like to share between a number of projects in Visual Studio.
I have put these files in their own project, set the build action to "Content", and the copy to output directory to "Copy if newer". I would like all these files to be copied to the bin/debug directory of the projects that reference them.
I can get it to work by including a reference to the "contents" project in each of the projects that need the files, but that requires that a minimal assembly be generated (3K). I assume there is a way, using MSBuild, to make this all work without creating the empty assembly?
Thanks to everone who took the time to make a suggestion about how to solve this problem.
It turns out that if I want my compiled content files to be treated like content files (in that they get copied to the output directory of any other project that references my project), I need to create a target which runs before GetCopyToOutputDirectoryItems, and add the full path of the compiled content files to the AllItemsFullPathWithTargetPath ItemGroup. MSBuild calls GetCopyToOutputDirectoryItems for projects on which the current project depends, and uses the resulting file list to determine the files that are copied along with the assembly.dll. Here is the XML from my .csproj, just in case someone else has a similar problem.
I have a custom task called "ZipDictionary", and I accumulate all the files that I am going to compile in an ItemGroup called DictionaryCompile. My target, "FixGetCopyToOutputDirectoryItems" is executed before "GetCopyToOutputDirectoryItems". I don't do the actual compilation there, since this target can be called multiple times by referencing projects, and it would hurt performance. The target does some transforms to get the post-compilation file names, and then returns the full paths to all the files, since relative paths will not work when copy is called from the referencing project.
<ItemGroup>
<DictionaryCompile Include="Dictionaries\it-IT.dic">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</DictionaryCompile>
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<UsingTask TaskName="ZipDictionary" AssemblyFile="..\LogicTree.DictionaryCompiler\bin\Debug\LogicTree.DictionaryCompiler.dll"/>
<Target Name="BeforeCompile">
<Message Text="Files #(DictionaryCompile)" Importance="high" />
<ZipDictionary DictionaryFiles="#(DictionaryCompile)" OutputDirectory="$(OutputPath)">
<Output TaskParameter="OutputFiles" ItemName="DictionaryOutputFiles" />
</ZipDictionary>
</Target>
<Target Name="FixGetCopyToOutputDirectoryItems" BeforeTargets="GetCopyToOutputDirectoryItems">
<ItemGroup>
<_DictionaryCompile Include="#(DictionaryCompile->'$(OutputPath)Dictionaries\%(FileName).ltdic')" />
</ItemGroup>
<AssignTargetPath Files="#(_DictionaryCompile)" RootFolder="$(MSBuildProjectDirectory)\$(OutputPath)">
<Output TaskParameter="AssignedFiles" ItemName="_DictionaryCompileWithTargetPath" />
</AssignTargetPath>
<ItemGroup>
<AllItemsFullPathWithTargetPath Include="#(_DictionaryCompileWithTargetPath->'%(FullPath)')" Condition="'%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'" />
<_SourceItemsToCopyToOutputDirectoryAlways Include="#(_DictionaryCompileWithTargetPath->'%(FullPath)')" Condition="'%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='Always'" />
<_SourceItemsToCopyToOutputDirectory Include="#(_DictionaryCompileWithTargetPath->'%(FullPath)')" Condition="'%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'" />
</ItemGroup>
</Target>
A better possible solution would be to
place a common directory in the solution dir and place your common content files there.
in VS, in each project that should share this content, right-click add existing item, browse to the desired item(s), select, click the down-arrow on the add button and select add as link. In the project, you will notice the files are added with a 'shortcut' overlay.
In the project, select the newly added links and right-click->properties and select Build Action: content, Copy To Output Directory: Copy Always.
This is a simple solution to the problem given.
I use this technique for things like SQL scripts and partial config files (using configSource) with great success. This allows me to make changes to these files in a single location with the assurance that they will be propigated throughout the solution.
A more robust solution would be to create a project with embedded resources. This requires a bit more work to manage the content on the receiving end but may be worth it in the long run as having a bunch of loose artifacts flying about can become problematic.
Hope that helps.
A similar solution like the one Sky suggested can be found in my answer to "Is there a way to automatically include content files into asp.net project file?".
It allows to share your content but you must not touch the folder or its content inside VS because this breaks the recursive path.
This approach works best for auto-generated content - you don't have to bother about including new content files to your solution.
And of course you can reuse this in multiple solutions/projects.
We do something similar where we have "...ReleaseBuilds" that reference dlls and content we require for specific projects. Compiling copies everything to the bin debug folder and indeed creates the empty assembly.
Within Visual Studio we have a post-build event in the "...RealeaseBuild" (in project properties) that copies/deletes or run batch files to make sure we have all the files (configs, services etc etc) required and to delete the empty assembly.
HTH
What is the purpose of the Source attribute? Have a look at this snippet:
<Component Id="MyComponent" Guid="123456789-abcd-defa-1234-DCEA-01234567890A">
<File Id="myFile" Name="myFile.dll" Source="myFile.dll"/>
</Component>
Since Name and Source have the same value, what does Source add? The code does not compile without it.
Where can I find documentation that explains these attributes? I have tried MSDN for MSI but did not find an answer.
Thanks.
WiX and MSI are not the same. Hence no reference in the MSDN documentation ;)
You need to refer to WiX.CHM where you installed WiX, or the online WiX documentation.
Assuming you're talking about File/#Name and File/#Source, this is optional if your source files are laid out in the same way as your WiX directory structure.
The nifty part comes in when you use multiple -b arguments to light and SourceDir in the File/#Source attribute. For example...
<File Id="example.dll" KeyPath="yes" Source="SourceDir\example.dll" DefaultLanguage="0" />
I usually specify 4 folders with -b in my standard build. One for various installer specfiic resources, one for where I store merge modules, one for common resources between all my installs and one for my source files. Now WiX will look in every directory specified on the command line, which makes things a lot more portable if I'm building on a different system with a different directory layout.
As per the documentation, if (in your example) myfile.dll was in the current directory, you could omit the File/#Source attribute.
File/#Source provides the location to get information about the file (size, language, hash) and to copy it to the correct location (either in a cabinet or laid out in a directory relative to the MSI file).
File/#Name is optional if you do not want to install the file with a different name. In other words, if the file exists with the right name on your build machine, just refer to it using the File/#Source and leave off File/#Name.
File/#Id is also optional as long your file name is unique. You cannot have two files with the same File/#Id so add File/#Id when you have collisions.
In WiX v3.5 I often just do:
<Component>
<File Source="my.exe"/>
</Component>