Is it possible to use wix commands from the command window? I have the wix 3.6 toolset installed and although the Wix Project is available, it seems that the project template does almost nothing to help you create a project. From my understanding, all the helpful tools are command based and are not accessible from the command window (at least they aren't for me). Am I missing something? It would seem rather unhelpful to have a visual studio project where you have to type all the xml by hand and then leave the IDE to use any of the useful tools.
You can call executables from the command window. For example, to call Heat with the /? param:
Tools.Shell /o /c heat.exe "/?"
Note that I have the WiX Toolset bin directory set in my Path.
You can also create code snippets to speed up entering repetitive xml.
Related
I'm trying to automate obfuscation by using post-build commands in Visual Studio 2015. I've followed the steps from this article on MSDN.
I've added the post-build command as mentioned in steps and created Dotfuscator.xml, placed in root directory i.e. where vbproj file is located.
Once I build the project I get following error message.
Here is the post-build command:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\PreEmptive Solutions\Dotfuscator and Analytics Community Edition\dotfuscator.exe" /q /p=SourceDirectory=$(TargetDir),SourceFile=$(TargetFileName) $(ProjectDir)Dotfuscator.xml
Any hint or solution will be appreciated.
You need to quote those paths you are passing...
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\PreEmptive Solutions\Dotfuscator and Analytics Community Edition\dotfuscator.exe" /q /p=SourceDirectory="$(TargetDir)",SourceFile="$(TargetFileName)" $(ProjectDir)Dotfuscator.xml
Or Perhaps
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\PreEmptive Solutions\Dotfuscator and Analytics Community Edition\dotfuscator.exe" /q /p="SourceDirectory=$(TargetDir),SourceFile=$(TargetFileName)" $(ProjectDir)Dotfuscator.xml
Test it by running the exe from the command prompt to see how the thing handles that argument.
Now that you've sorted out the quoting issue as Trevor described, I think the next issue is that you're probably running a version of Dotfuscator that doesn't have command-line support.
Visual Studio 2015 Update 3 (and VS 2017) includes a version of Dotfuscator Community Edition (CE) that has command-line support. (You have to register to enable it.) If you're using an earlier version of VS 2015, you can download a version of Dotfuscator CE that has command-line support from PreEmptive; see the instructions here for details.
Full disclosure: I work for PreEmptive Solutions.
With the help of answers from #Trevor and #Nathan, here I'm able to achieve what was desired.
First I created the Dotfuscator.xml file using Dotfuscator.exe. Providing input files and generated obfuscated DLL once.
Once it's confirmed that the XML file working fine, I then added following post build event build command
dotfuscatorCLI.exe "$(ProjectDir)Dotfuscator.xml"
Another way to achieve same results
Above solution will work but it would be specific to one computer. So if you are working in a team and there are chances that you build your solution on multiple machines then I would prefer the approach defined in the article whose link was shared in my Question. However that approach requires a minor tweak.
Here is the post build command that will work:
dotfuscatorcli.exe /q
/p=SourceDirectory="$(TargetDir)\",SourceFile=$(TargetFileName)
"$(ProjectDir)Dotfuscator.xml"
Please note here the Dotfuscator.xml is the one that is referred in the MSDN article, not the one generated by dotfuscator.exe as mentioned in previous solution. Also note, if your TargetFileName contains spaces then put double quotes around it.
Hope this would help others.
Can someone help me understand how WiX works? I have a directory structure which I would like to create an installer for. I have generated the for the directory structure with heat.exe and when I build the setup project it generates an .msi file but I don't think it installs anything.
Maybe someone can walk me through the steps of generating a .msi installer.
Any advise is appreciated,
Thank you
If you're using Visual Studio:
Install the WiX Toolset V3 Visual Studio plugin.
Install the Wax interactive editor.
Build your project if you haven't already.
Add a new project to the solution containing the project you want to create an installer for.
Choose the template Setup Project for WiX v3.
Name the installer. A personal convention is the name of the project plus ".Setup"
A Product.wxs file will open up. Change the Manufacturer="" value to something like your company name or your name. Keep the file open.
Go to Tools -> WiX Setup Editor
On the left under Root Directory choose InstallFolder
Under Projects to install, choose the project you want to install.
In the red area to the right, you'll see a list of files. These are the output results of your build from step 3.
Click the plus sign next to files you want to copy. They should turn white and change to a Resolved state.
This might look daunting, but you're just telling it what to copy--which would be your project's executable, configs, dll libraries, and images it's dependent upon.
You typically want to copy everything. If there are dll's you know you don't need, it's better to remove them as a dependency from the Visual Studio.
Notice the Product.wxs has changed. It now has the files you checked off in the Setup Editor GUI added to the <Wix><Fragment><ComponentGroup> section. Save that file.
Close the Setup Editor.
Build the setup project you just configured.
Open Windows explorer and go to that project's bin/Debug or bin/Release folder, depending on what mode you built in. There you'll see the .msi that you can copy to where you need.
To make an update, make the necessary changes and then change the version number in that project's Properties -> Application -> Assembly Information. Then also change it in Product.wxs <Wix><Product.Version>. Then just build your setup project again.
Good tutorial here:
http://wix.tramontana.co.hu/
http://www.codeproject.com/Tips/105638/A-quick-introduction-Create-an-MSI-installer-with
They should get you started.
If you learn something about the MSI log that will also help - install the MSI with a command line that includes /L*vx
And "doesn't install anything" should be easy to check - are there are any files installed, or did it create an entry in Programs&Features?
WiX is a language (XML/XSD) that serves as a way of authoring (compiling) Windows Installer (.MSI) databases. WiX doesn't install anything, MSI does.
I maintain an open source project called IsWiX. The concept is simple. IsWiX provides additional WiX project templates (scaffolding) and graphical designers to assist you in creating installer. Then as you gain knowledge of WiX and MSI you can make additional tweaks of the WiX XML by hand and go beyond what IsWiX currently knows how to author.
Here's a video showing how to author, build and test an MSI to deploy an IIS website in a mere 3 minutes.
Update: IsWiX has tutorials now.
After a few 'false starts' trying to learn WiX from online tutorials I noticed that on http://wixtoolset.org/ there is a link to the book "WiX 3.6: A Developer's Guide to Windows Installer XML". You can buy it pretty inexpensively in E-book form from Packt, or also Amazon if you like the easy interface with Kindle.
I found this book to be VERY helpful with every little step regarding the .msi creation process. The book will guide you to create your first .msi in the very 1st chapter! Granted, you have to continue a little more to have a fully functioning .msi, but given the complexity of Wix, this book is terrific. It may not be for the gurus among us, but for those of us who need a little more help to understand the material it's wonderful. I've seen many posts speak to the 'steep learning curve' regarding WiX and it is a complicated process to create a valid .msi, but this book goes a long way toward making that learning curve very bearable.
If you are using the build system 'cmake', then you can use cpack to generate .msi file by setting the cpack generator to wix.
What worked for me best, was this fantastic tutorial video: https://www.youtube.com/watch?v=6Yf-eDsRrnM
Its best selling points for me was
independent of visual studio version
it describes deploying a .NET (Core) app also
it focuses on what an average app's installer should be capable of (including heat, icon, background image and banner)
you don't have to learn another layer on wix
it gives you good practices on easy package generation and future maintenance
it gives an installer project template which you can reuse: https://github.com/angelsix/youtube/tree/cecd38ea3d5eea11cc75fc0123297ffc3b5e662b/C%23%20General/Windows%20Installer%20Wix%20DotNet%20Core/ConsoleApp1.Installer
I've got a .msi file produced by WiX which is working great, and now I want to wrap it in a bootstrapper. Previously I used setupbld, but as that is now deprecated I'm experimenting for the first time with burn from WiX 3.8.
However, every time I run burn from the command line nothing happens, regardless of parameters. I connected a debugger and got the following output if I run burn.exe with no parameters:
The program '[0x1380] burn.exe: Native' has exited with code -2147024883 (0x8007000d).
Does anybody know what is wrong here?
Note, I am literally running "C:\Program Files (x86)\WiX Toolset v3.8\bin\x86\burn.exe". I notice that burn.exe has an icon resembling an msi package (despite being an exe) so I'm not sure whether this is the installer for burn, or whether it is burn itself.
Tbh, I'm finding that although there is lots of documentation on writing the XML files needed by burn, there seems to be precious little on actually invoking it, and what to expect when one does.
Burn is the bootstrapper engine, not the builder. The error is ERROR_INVALID_DATA, which makes sense because burn.exe does have any data attached to it; The builder copies and modifies it to contain and/or point to containers for your bootstrapper's data.
To build a bootstrapper, you create a WiX document with a bundle element and then run candle.exe and light.exe on it.
Many people use a build system to run their tools and an IDE to manage their projects. WiX integrates with MSBuild and Visual Studio (non-free editions). There is a WiX Bootstrapper project template for Visual Studio provided, too. The SharpDevelop IDE has its own WiX templates (but currently not for the Bootstrapper.)
Note: All WiX projects are MSBuild projects so you can hand-write projects and/or build them with MSBuild instead of the IDE.
A while ago I found a packaging tool for visual studio that allowed quite heavy control by means of a build script and was a freebie , problem is I can't remember the name of it. Anyone know of a package/tool that fits those criteria? Failing that I just wanted it as I know I could do completely silent install packages with it. Which is exactly what I want for a central deploy. Oh this is in VB
Anything which produces an MSI file, such as WiX, can be installed silently using the /qn flag and thus matches your criteria.
Another major installer script is NSIS (Nullsoft Install System) - you can write a silent installer using this as well.
Can you remember any of the syntax or anything? WiX is XML-based, and NSIS is it's own stack-based language, although there is a plugin to make it imperative.
Background:
I always try to ensure the following tenet in my projects:
After a fresh checkout a developer should be able to do all project related tasks with solely the contents of the combined folders.
Obviously, this isn't always possible (e.g. Visual Studio for Windows development). However, I really dislike having to install any third-party libraries or tools that are specific a project like log4net, NHibernate, NUnit, etc. There are number of reasons for this including:
For a given development machine, you may work on several different projects, all which leverage different versions of the same third-party library or tool.
Minimizing the environment setup requirements makes setting up new developers or machines much easier
Facilitates easier maintenance of automated builds
Assumptions/Contraints
I am currently using WiX 3 beta, but if there is way for either 2.0 or 3.0 please respond
I am using Visual Studio 2005
The IDE syntax highlighting is not a requirement.
Question:
Is it possible to avoid local installation of the WiX toolset and use flat files instead? If so, please explain how.
See Also:
First, build your WiX installer:
Create a new WiX Installer Project in Visual Studio 2005.
Build your WiX XML accordingly.
Now, to integrate the WiX toolkit into your source tree:
Copy c:\Program Files\Windows Installer XML v3\bin to a sub-directory in your source tree. I used WiX\bin relative to my .wixproj file.
Copy c:\Program Files\MSBuild\WiX\v3.0\ to a subdirectory in your source tree. I used WiX\v3.0 relative to my .wixproj file.
Either add the following code or replace the line that follows:
<WixTargetsPath Condition=" '$(WixTargetsPath)' == ''>$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets</WixTargetsPath>
With the following lines:
<WixToolPath>$(MSBuildProjectDirectory)\WiX\bin\</WixToolPath>
<WixTasksPath>$(MSBuildProjectDirectory)\WiX\v3.0\WixTasks.dll</WixTasksPath>
<WixTargetsPath>$(MSBuildProjectDirectory)\WiX\v3.0\Wix.targets</WixTargetsPath>
As you can see, the WixToolPath, WixTasksPath and WixTargetsPath directives reflect the location of the folders I've instructed you to copy.
Rename your .wixproj to .csproj. This ensures that Visual Studio does not get confused by the .wixproj file but because the .wixproj is a valid MSBuild project, Visual Studio will be able to work with it.
Using this method, the WiX directory as described is about 9MB large.
I know with WiX 2, you can just download the executable files and the dll's to whatever directory your project is in. Then you create a .bat file to run candle.exe and light.exe with the parameters you need to build your installer.
That way, all your projects can have their own version of WiX with a disk drive hit of only about 4 megs each.
I'm not positive, but I think you can do the same with WiX 3.