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.
Related
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'm developing an open source C# application. For awhile now, I've been using a basic .NET installer I coded myself. However, with a recent change, that is no longer practical for me, as I'd have to add a large number of files to the installer - and they may change with each release. A ZIP file is also not practical.
I've done some checking online, I see a lot of MSI, ClickOnce, Self-extracting ZIPs, and (imo the most promising) the NSIS system. None of them seem to exactly fit my needs, so I'm looking for advice on which system to use.
Actual installing of my program is very simple. Basically, I just need to copy the bin\Release directory (and all subdirs) to the client's computer. I've been achieving this somewhat ad-hoc, by embedding every file in my .NET installer, and maintaining a file table of what goes where.
Unfortunately, I just localized my app. I now have 30+ .resx files (Which are compiled to dlls and placed into MORE subdirectories by Visual Studio) and, obviously, it's impractical to add 30+ folders and DLLs to my installer. Hence why I'm on this search.
There's also a few other requirements:
The installer should search predefined directories for a specified .exe. (My app is designed to be a drop in replacement) If the .exe is not found, it should prompt for its location
The installer should verify that "OldApp.exe.bak" exists. If not, it should rename "OldApp.exe" to "OldApp.exe.bak"
The installer should update files. Ie, if "Culture.de.dll" hasn't changed, the installer will leave it alone.
The installer should work with all Windows versions of all .NET IDEs (VS, SharpDevelop, Mono, ect) but does not need to work on other platforms.
When I build the solution, the installer should be automatically regenerated. In other words, it should be run-able for by "Post-build" section.
The installer generation must be able to be added to a source code repo. This is so that anyone who downloads the source of my app can compile the installer as well.
Sorry for the long post, I figured it was better to post more than less.
I'd recommend SharpSetup. It combines WiX and C# for a pretty flexible implementation. Not much I've found it can't accomplish.
We use WIX extensively: http://wix.codeplex.com/
You may have to customize your installers with some exit routines to do things out of the ordinary, but there are hooks in Windows Installer framework that let you do that.
You can put these definition files (XML) in your source control, and you can configure a build to execute the installation. However, anyone that gets your source would need to have the WIX utilities installed.
I would recommend NSIS. From my experience any installer feature that I have required has been covered in NSIS documentation or community examples. I can't comment on NSIS integration with Visual Studio as I use NSIS integrated with my Jenkins build server. There appears to be a free Visual Studio Add-In called Visual & Installer which provides NSIS integration with Visual Studio. I have not personally used it but it appears to be currently actively developed so might be worth checking out.
WIX is a good one. According to Wikipedia, it is used by Microsoft to produce installers for some of their own products.
i wanna deploy a C# Windows Application project using Setup and deployment project technique
but i don know what should i use
after i open File > New > Project > Setup and deployment > ....
then what ,, what should i do next
In the past I've used the Visual Studio Setup Project or Innosetup for my programs. I prefer to build .msi's over exe's so Visual Studio Setup Project has been my goto for a while now. It is however, very lacking in capabilities. The interface is not intuitive either in my opinion. Every time I build an installer there is a lot of trial and error install/uninstall to get it right. Other's have pointed out WIX and I've looked into it. It appears to be very flexible and since it is open source, we should be able to count on it for the long term.
Here is a recent article about WIX. What I found interesting is the article claims (see link in article) that Visual Studio Setup Project is being End Of Life'd in VS 2010 + NEXT_VERSION. This is a little disconcerting to me. Since I don't want to begin to rely on the new Install Shield "Lite" in VS, I'm going to put effort into learning WIX. I hope it'll pay off in more flexible builds for my applications as well.
All that said, when creating a VS Setup project, I usually use the wizard to put in the initial plumbing. You'll point it at the files you want in the .msi. Typically for me this means the "outputs" of one or more programs in my solution. Any managed assemblies referenced in the programs will automatically get picked up as dependencies and included. Unfortunately unmanaged assemblies don't and I usually have to add them manually using the "File System Editor" mode in the Setup Project UI. Adding shortcuts is a little hokey as well. You right click under the start menu and desktop section of the "File System Editor" mode and select create shortcut. This is all by memory so hopefully I'm getting this right. You will certainly have to test your installer multiple times before you get it just how you want. I like to test under a VM as well.
Finally, the VS Setup project produces a setup.exe and .msi file. Setup.exe is used for detecting and installing dependencies (such as .Net) before unpacking the actual DLL.
When u do this File > New > Project > Setup and deployment >
then right click Application folder> Add > File...and add your app's .exe file and also you can add shortcuts of your app in desktop and program's menu
I would recommend you to go for some tool for creating msi.
I am using WIX
What you need depends on... what you need.
For a large percentage of applications, all you need the installer to do is let the user choose an install location, copy files to a directory structure at that location, and create a few shortcuts. For that, a Visual Studio Installer -> Setup Project is fine. It can handle this basic functionality, as well as installing prerequisites like the .Net Framework redistributables, providing custom install options, and/or writing simple registry keys. The Setup Wizard creates a Setup Project as well, but runs you through a wizard to set up the basics. This is a good option if you've never created an installer before.
If you want this application to be controlled by a larger, more custom install, choose the CAB Project; it will simply pack the necessary files into an archive that is easily accessible from another setup project.
If you are publishing a class library, use a Merge Module. Merge Modules work within install programs themselves, providing files needed for the main application to work.
If you need serious customization, or you want to interface with existing InstallShield logic, I'd get a third-party installer. I've worked with InstallShield before, and it's pretty full-featured, but by the same token, the installers it creates are applications in their own right and can take days or weeks of logic programming to "tweak" to your satisfaction.
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.
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.