I will try to make this as clear as I can, but if you have questions or don't completely understand let me know.
I have a program that creates a WXS (WiX source code file) from scratch, and tests it to make sure it is valid. I would like the next automatic step to be the actual building of the WXS using Visual Studio (I am working with VS 2008 Developers Edition/Team Suite Edition). I know that a WiX project (with WXS included in it) can be build from within VS, and the WiX comes with command line utilities for building as well. What I am looking for is the best option to go with. The program is a command line utility with no GUI. I know it is possible to use the command line from within my program, but I don't know how to use it with variable destinations and file names for the created file. A push in the right direction would be greatly appreciated.
build your WIX project in the visual studio and look at the Output window to see what is WiX actually running. then just copy paste those lines into your build proces.
Related
I am working on a WPF project. I have created a Wix project which runs along with the main project and has a program.cs component as well as the XML file.
Although I can see it creates the installer upon re-building the project, what is not clear to me is that why don't I have the actual WPF project inside it or as part of it. So really I don't install anything when I run it. Simply a shell program.cs file which is part of the Wix project.
I don't get the actual project at all. So how do I effectively "add" the WPF project to the WiX project so it generates the .exe or .msi file.
When I used the Windows native build project, I was able to get this however it is really tedious.
Thanks,
Ibrahim
Most of understanding how WiX works is understanding how Windows Installer works. WiX is mainly a language and compiler to author and build Windows Installer (.MSI) database files. It does have some additional extensions and the ability to create a bootstrappper / chainer (.EXE) and that is additional tech to understand.
MSI and therefore WiX should be thought of in terms of declarative programming rather then imperative. You describe the product, the UI experience, the feature/component/resources relationships or the "what" needs to be installed and MSI handles the "how" to install it.
WiX newbie here too. I found that this tutorial to be helpful to get started: Create a simple setup. It walks you through creating a new WiX project in the Visual Studio. It creates a really simple installer (e.g. doesn't even add a shortcut to the Start Menu), but I think it will help with your understanding of how WiX works.
After you get the above example working, I'd suggest reading through this tutorial: How To: Create a Shortcut on the Start Menu. Note: I found that it was easier to copy/paste the entire code sample at the bottom of the page, replace everything in the default Product.wxs file in the WiX Visual Studio Project, and then replace references to your own files as needed.
I am currently trying to automate our .NET builds and have currently run into a snag. When building the project in Visual Studio on a machine with a InstallShield 2016 Professional License, everything builds fine. However, when trying to use MSBuild to build the VS Solution on a machine with InstallShield 2016 Standalone, the resulting MSI does not have a required DLL or a Custom Action. Meanwhile, trying to build the .ism using Iscmdbld results in the inability to find the Primary Output of the csproj's, Even after building in Devenv
If you are using project output groups (like Primary Output), your choices are limited. You have to use either the VS integrated build (via devenv), or MSBuild; iscmdbld is unable to resolve project output groups.
Your other alternative is to change from project output groups to using static (or dynamic) file links that don't require Visual Studio's knowledge. I tend to prefer static links, as it's easy to tell exactly what's in the project. More importantly, with static links you can't silently lose files that you'd previously added, thus it's easier to avoid potentially breaking component or upgrade rules.
Hopefully, this isn't too old to be of use. InstallShield is the absolute worst, I know.
If you edit your .isproj in a plain-text editor, you'll see that it's just a regular MSBuild script. You'll see that there is a lot of commented out stuff that explains (poorly) things you can add to it. Find the ItemGroup that contains the explanation about "ProjectReference items" and add a node of the following form:
<!-- The ProjectReference items refer to any Visual Studio solutions you want to automatically probe for Project Output Groups. -->
<ProjectReference Include="..\Path\To\Your\Proj.csproj">
<Project>{2d3f37cc-0e93-4673-a3df-59c556185f71}</Project>
<Name>Name Of Project As It Appears in VS</Name>
</ProjectReference>
After adding the above to all of my .isproj files, my automated build worked fine. Why the idiots at InstallShield never saw fit to add this capability to the UI, I'll never understand.
Unfortunately, I don't have any answer to the Custom Action problem, if it's not related to the above.
I am using the Sandcastle Help File Builder to output my C# XML-DOC file to the Website format. How can I accomplish the samething from the command line so that I can add this as a build event in Visual Studio when building the actual project?
The end goal is to have the website Help File content built when I build the Visual Studio project.
As Scott Wylie indicated, you need to specify this in the post build event command line in Visual Studio's project properties. However, I would suggest using Sandcastle Help File Builder (SHFB) rather than Sandcastle directly. It makes the command line call short and simple as shown below, but note that first you have to configure the SHFB project with the SHFB GUI, which creates an msbuild-compatible build file with the ".shfbproj" suffix:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
/p:Configuration=Release myProject.shfbproj
However, note that I take the opposite approach from what you are doing: instead of using Visual Studio to interactively launch a build and ancillary actions, I use ant (nant) to launch a build of everything, which includes my Visual Studio solutions and subsequent SHFB action. So this is really the command-line call I make to build the documentation with Sandcastle:
<exec executable="${msbuild}" dir="${csharpdoc}" output="${csharpdoc.log}">
<arg value="/p:Configuration=Release"/>
<arg value="myProject.shfbproj"/>
</exec>
My preference is that the entire build should be launchable from the command line so there are no interactions required (e.g. launching Visual Studio, etc.). That provides the flexibility to run either as a scheduled recurring task or on-demand from the shell.
You could call SandCastle from the post build event command line, in the Build Events section of your project properties. This should work nicely if you are not using any automated build tool.
If you're using MSBuild for your build tool this is the tutorial I used awhile back.
There is also a script on codeplex that you can look into using that might help you out.
Hope this helps!
I found it easiest to just add the *.shfbproj project to the solution. It builds fine (although a bit slowly) inside of VS 2010.
I have inherited this c# solution that includes an ix installer project (a bunch of .wxs files and some c# files). The uninstaller is generating an error message.
I haven't a clue what this installer project is. What are the .wxs files for? I can guess (and have successfully been able to fix some issues with the installer. I have figured out how the custom actions are set up and called etc.
But the bug in question would be so much easier to debug if I could step through it in the debugger - how do I do that?
Generally: How do I hook up the Visual Studio 2008 debugger with the installer project ("Set as Startup Project" is not an option in the Solution Explorer, tried that).?
Specifically: How do I debug the uninstaller? The way I see it, the uninstaller will have to use a dll not residing in the project folder (where?) and thus not really known to Visual Studio at all...
Maybe this article on MSDN will help.
I haven't done it recently but I think that if you add anywhere in the code Debugger.Break() statement, you will get a prompt during the install to debug the process and then you can step through it.
One of the pages that look promising is the WixWiki.
I found this on the wikipedia page for WiX.
I'm a web-guy stuck in "application world" in VS 2005. I created my windows forms program and want to give my end users the ability to install it (and some of it's resources) into a standard Program Files/App Directory location along with a start menu/desktop launcher.
The help files don't give any instructions (that I can find). This seems like such a trivial task to create an installer - but it's eluding me.
Any hints would be greatly appreciated!
You're looking for a "Setup Project" which should be under the "Other Project Types" -> "Setup and Deployment" category in the "New Project" dialog.
I would suggest using something WiX (windows installer XML). Its the toolkit most products from codeplex or OOB code drops use, and its pretty easy to get the hang of.
There's also (in version 3) an IDE add-in called Votive to help make things 'easier'.
Personally I find using WiX more flexible then using the built in Visual Studio installer template, though your means might vary. Take a look at http://wix.sourceforge.net/ and there's also a great tutorial at http://www.tramontana.co.hu/wix/.
If it seems kind of hard to start off with, persevere - I did and now I find it perfect for what I need.
Another option is Inno Setup, a third-party installer which is free, easy to use and excellent:
Inno Setup
The exe file is actually just a boostrap loader, which launches the MSI file. The MSI file is the actual installation file.
Add a "Setup Project" project to your solution. New Project > Other Project Types > Setup and Deployment. You can then choose what is installed and where.
The Setup Project is the way to go. If you're going to be deploying the installer from a web site, I recommend creating an MSI file as the project output (as opposed to a Setup.exe output). Most of my clients block the download of EXE files.