I have been referencing the following tutorial for creating a Setup Project for WiX v3, however, most WiX tutorials on the internet are targeting a C# application as its base project. I am currently building a Visual C++17 Win32 application that I want to deploy (i.e. create a setup *.msi installer) using WiX, given how powerful WiX is.
Unfortunately, adding a reference to my C++ project yields a yellow bang exclamation point:
Moreover, when trying to reference an icon file, for example, in the Product.wxs file using $(var.TimeTrack.ProjectDir)\TimeTrack.ico reports that it is an "undefined predecessor variable." I have tried unloading the WiX Setup Project and tried validating that the yellow banged Visual C++ project reference is referring to the correct path in the *.wixproj file. The include path appears to be correct:
<ItemGroup>
<ProjectReference Include="..\TimeTrack\TimeTrack.vcxproj">
<Name>TimeTrack</Name>
<!-- More not shown. -->
</ItemGroup>
I did a bit of digging and I cam across this StackOverflow posting that indicated that WiX is dependent on .NET framework. In addition, there seems to be a lot of very old postings (e.g. example 1) on this topic and I just am not entirely sure if I am just misunderstanding something here. According to this post, the WiX project cannot refer to any C/C++ code, but this appears to be referring to "Custom Actions," which appear to be an entirely different topic (?).
All in all, am I doing something wrong or is WiX not capable of deploying C++ applications? Is WiX only meant for deploying C# applications?
WiX has a development dependency on .NET but not an install time dependency.
Files are files. WiX doesn't care if they are C, C++, VB, PowerBuilder, Delphi, .NET, NodeJS, Electron or whatever.
The main differences for .NET vs C/C++ is:
1) .NET typically requires you to check that .NET is installed or author a bootstrapper to install it.
2) .NET core can typically be packaged with the app privately without a system wide installation of .NET core.
3) C/C++ typically requires installing the VCRedist via a bootstrapper or statically linking the files into your application.
4) .NET is "AnyCPU" where as C/C++ is compiled for the platform. MSI is compiled for the platoform. This means for .NET a single x86 MSI can deploy a .NET app that might run 32bit or 64bit depending on how it was built. For C/C++ you might need to create a 32bit MSI and a 64bit MSI for your app.
I have a FOSS tool that helps with learning and authoring WiX. You can read about it here:
http://www.github.com/iswix-llc/iswix-tutorials
The tutorials only hav C# examples but pull requests are welcome. Create your C/C++ application and use a postbuild copy command to stage the files to the Installer\Deploy folder and everything else is mostly the same.
Related
I am struggling with creating NuGet packages. I am using Visual Studio 2017 Community edition.
I have seen a couple of videos that show a "Pack" option on the menu when right-clicking the project in Solution Explorer. However, I do not have that option. Is this one of the features in the other (non-Community) versions of Visual Studio? I believe I have also seen a "create NuGet package on build" option mentioned somewhere. I cannot find that either.
I have tried various ways of using nuget, dotnet, and msbuild from the command line(s), but haven't had much success. Very frustrating.
Any help is appreciated.
If you really want to use Visual Studio, I would recommend installing an extension that helps you with that problem. For example, this one. The options people have in videos depend on the extensions they have installed. For you, it is the same.
Alternatively, just use the command-line tooling for this as explained here or for .NET Core here or here.
dotnet/msbuild pack is only available for SDK-style projects, but I believe works for all versions of Visual Studio, as well as on the command line. .NET Core introduced these SDK-style projects, which can be identified by <Project Sdk="Microsoft.NET.Sdk">. If your project (.csproj if it's a C# project) doesn't have the Sdk property or import Microsoft.NET.Sdk in either of the two other ways, then it's not an SDK style project and doesn't support packing in this way. Another obvious difference between the two styles of projects is that SDK projects are only a few lines long from the new project template and don't list files in the project, whereas old style projects are typically a full screen long, even from a new project template with only a single class file, and it does list individual files in the project. If you want to continue with this project type, you'll need to use nuget.exe pack and you'll probably want to create a .nuspec file to define some of the package metadata.
However, using SDK style projects is the future, it just takes time for all of Microsoft's existing project types to migrate. It's much simpler to use, so personally I would avoid old style projects unless you're using a project type (like ASP.NET, not ASP.NET Core) that doesn't support it.
All of this is confusing for anyone new to the .NET ecosystem. My recommendation is 1. when you install Visual Studio, when making your workload selections, make sure in the component list that .NET Core is selected, whatever the newest version of .NET Core that is available at the time of installation. When creating a new project in Visual Studio, always select the .NET Core version, or .NET Standard version of any new project template, even if you want to target the (Windows) .NET Framework, in which case you edit the .csproj and change <TargetFramework>netstandard2.0</TargetFramework> to <TargetFramework>net45</TargetFramework>, although I would recommend multi-targeting possible by adding a s to the element name and using a semi-colon separated list: <TargetFrameworks>net45;netstandard2.0</TargetFrameworks>. So, avoid the "Class Library (.NET Framework)" template, instead use "Class Library (.NET Standard)" and then change the target if you have to.
#zivkan led me down the right path. Changing my project types to .Net Core from .Net Framework made all the options I mentioned in my original post available. No extensions were needed.
My .Net Core class library project now has the Pack and Publish options available on the project's context menu. In addition, there is a another tab (Package) on the project properties page. On that page there is a "Generate NuGet package on build" option along with version, name, tags and other properties.
I have done much .Net framework development, but have been ignoring .Net Core and the newer options. I guess I need to dig in and learn about them.
I'm confused. We upgraded our project recently to .NET 4.5.1. We installed .NET 4.5.1 on our servers.
I'm referencing assembly System.Threading.Tasks.Dataflow from the GAC at C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Threading.Tasks.Dataflow\v4.0_4.5.9.0__b03f5f7f11d50a3a\System.Threading.Tasks.Dataflow.dll
CopyLocal is set to false as (I assume) it's part of the Framework, so should be already installed wherever the app is deployed.
The trouble is, when running on the server, it says it can't find this assembly.
I've read here that is is part of .NET Framework 4.5:
but the library is now built-in with .NET 4.5.
...and I've read here that it isn't!
The TPL Dataflow Library (System.Threading.Tasks.Dataflow namespace) is not distributed with the .NET Framework 4.5
What gives? It doesn't look like it is. Is it just part of the 'targetting pack'? Is it me, or are these in-place upgrades more agro than they're worth?!
I'm not sure why that page says it is part of .NET 4.5 -- it's still an out-of-band NuGet release, like Entity Framework, MVC, etc.
I recognize this question is pretty old, but I wanted to add my solution as well. I found adding the below two items to the Visual Studio 2019 install (run Visual Studio Installer > Modify > .Net Desktop Development) the problem went away and it was able to pull System.Threading.Tasks.Dataflow from the GAC.
Edit: Installing Visual Studio 2015 also seemed to be required. Obviously it isn't VS 2015 itself, just something it comes with. But there are too many packages for me to figure out which one easily.
Edit2: This isn't really the best solution, more of a stopgap. MS suggests downloading it through Nuget. https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.dataflow?view=netcore-3.1
The TPL Dataflow Library (the System.Threading.Tasks.Dataflow namespace) is not distributed with .NET. To install the System.Threading.Tasks.Dataflow namespace in Visual Studio, open your project, choose Manage NuGet Packages from the Project menu...
I've created an application in C++ using Visual Studio 2010 as my IDE. I used the QT plugin for Visual Studio to create my GUI and also use the VTK and OpenCV libraries. What is the simplest way to deploy my application? I've already tried pasting the DLLs for QT, VTK, and OpenCV in my exe folder and, although this runs on other computers, the formatting and program speed are wildly different than what I get on my computer.
So, you have 2 possible ways:
Static deploy.
Shared deploy.
Description both of them you can find here
As i see the shared deploy is too difficult for you, because you're using heavy libraries.
So, my advice is that satic deploy will be better :)
Please, try to build Qt, libs, and your app static, and we'll see how it will works.
I have an application which I have built in Visual Studio 2012, one part of which is in C# and one part of which is in C++. The GUI for the application uses a third party GUI control.
Consequently I have three dependencies that need to be checked for and installed with my project:
The Microsoft Visual C++ redistributable
The .NET framework 4.5
The GUI control
My installer for the project is currently built using WiX. Is there a way to make WiX do the following?:
At install time check for the presence of (e.g.) the C++ redistributable and install it if it is not present
Remove these components at uninstall (if and only if they were installed at install time, obviously)
If not, my guess would be that the answer is to create another C# project which can run each msi in turn, but I'd like to be able to do the whole thing through WiX - is it possible? If so, how?
WiX has added to its original purpose of being a Windows Installer toolset. It now has a bootstrapper/chainer/bundler/reboot manager/package manager, sometimes called Burn. In Visual Studio, it is accessible via the WiX Bootstrapper project template.
You'd need to have a WiX Setup project for your application. Then define a chain sequence for the four setups. VC and .NET should be marked permanent because you don't known if and when they should be uninstalled. Same thing probably goes for the GUI control. That leaves your application, which the bootstrapper will uninstall when it is uninstalled.
You could create a bootstrapper to install your application and its prerequisites.
WiX toolset provides all necessary tools for you to create a bundle that contains different packages, one of it would be your own MSI.
Have a look at Burn and the WiX toolset documentation. The How To Guides show ways to achieve exactly what you want, for example there is a tutorial describing how to Install the .NET Framework using a bootstrapper.
Maybe the Standard Bootstrapper Application is what you are looking for. Or have a look at customized Managed Bootstrapper Applications. For example the fancy Visual Studio 2012 installer is a WiX MBA. But be warned, in my opinion a MBA is a lot of work.
Our product currently installs via 4-5 MSI's which are created from .vdproj files which consist are created from the output from vs 2010 projects and additional information in merge modules.
I have been looking at InstallShield and WIX as a possible replacement due to VS2012 no longer supporting VS Setup Projects (oh no!) so we have to find something else.
I've had a little play with InstallShield and I couldn't really get to grips with it, additional to installing the product, the installer also has to take in a few parameters such as a database name and location etc. I couldn't seem to find a way to get this info into the InstallShield project - This was using InstallSHield limited edition for visual studio though
I'm not sure which would be the best to use? Has anybody had experiences with converting to WIX or IS from a VDPROJ?
EDIT
It looks like WIX is going to be the easiest and I am trying to get to grips with it.
I cant seem to find any useful posts that allow me to direct project output into my WIX installer, and how to create variables. (Without using plugins)
It's hard to give a simple answer because you are actually asking really high level questions that require an understanding of your installation needs and a whole bunch of training in the art of creating installers.
Personally I have installers that are 100% WiX, 100% InstallShield ( Both Limited Edition and Premiere Edition ) and a blend of the two.
Limited Edition is limited but it also does some things really well and provides some features that aren't really there and/or easy to implment in WiX.
One good strategy is to use InstallShield LE as a simple container and then do most of your authoring in WiX. I describe that pattern here in my blog:
Augmenting InstallShield using Windows Installer XML - Certificates
InstallShield Professional and above has a tool for migrating VDPROJ projects but I'd use it with caution. Most VDPROJ installers have some horrible authoring and it would be better to refactor rather then migrate.
I strongly suggest looking at Wix#. See http://www.codeproject.com/Articles/31407/Wix-WixSharp-managed-interface-for-WiX.
Also see the CodePlex home page: http://wixsharp.codeplex.com/
For developers primarily coding in C#, Wix# this would probably be the most simple and comfortable skill set to add, and it is free and directly integrates into the Visual Studio environment. I've been using it with great success in Visual Studio 2012 and 2013.
For C# developers needing to create a Windows Installer MSI to deploy their app, Wix# is perhaps the best replacement for the "Packaging and Deployment" project type that Microsoft removed from Visual Studio starting with VS2012. Wix is a C# front end for the WiX (Windows Installer Xml) Toolset. Using Wix# allows building a complete Windows Installer MSI in the C# language.
Wix# is useful for a broad range of installation/deployment scenarios, and lends itself reasonably well to Continuous Integration scenarios. There are Wix# examples for deploying Windows desktop applications, for installing Windows Services, and installing ASP.NET websites, and many more types of installations.
Wix# handles typical installer requirements, and the Wix# installer code for simple projects is indeed simple. For application installs that are more complex, and require advanced features, Wix# can tap into the power of the full WiX Toolset when needed. For example, when installing a .NET application, a typical requirement would be to install the application exe and dll files, and tailor some .NET configuration files and/or registry entries on the target system.
Below is an example of the C# code for a simple Wix# installer that installs an application on a target system, and modifies some configuration files. This example assumes that you have written a utility named "TailorMyConfig.exe", e.g., a simple C# program that uses ConfigurationManager.AppSettings routines, and you are deploying this exe along with your app.
using System;
using System.Windows.Forms;
using System.Diagnostics;
using Microsoft.Deployment.WindowsInstaller;
using WixSharp;
class Script
{
static public void Main(string[] args)
{
var project = new Project("MyProduct",
new Dir(#"%ProgramFiles%\My Company\My Product",
new File(#"Files\Bin\MyApp.exe"),
new File(#"Files\Bin\TailorMyConfig.exe")),
new ManagedAction("UpdateConfigFile"));
project.Id = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");
Compiler.BuildMsi(project);
}
}
public class MyCustomAction
{
[CustomAction]
public static ActionResult UpdateConfigFile(Session session)
{
if (DialogResult.Yes == MessageBox.Show("Config file update ready to run.\n Update config file(s) now?",
"Config Tailoring Utility",
MessageBoxButtons.YesNo))
{
Process.Start("TailorMyConfig.exe", "Run utility to tailor config file to current system");
}
return ActionResult.Success;
}
}
Note that there are "better" ways to modify a config file using WiX XML features. For simplicity, the example above assumed a custom-written C# exe utility for modifying config files. I would suggest using WiX XML capabilities for doing this instead. You can incorporate nearly any WiX XML capabilities directly into your Wix# setup using the Wix# technique of "XML injection".
Remember, Wix# is simply a C# front end that emits WiX XML syntax. After Wix# has emitted the WiX XML (wxs file), that wxs file can easily be post-processed to insert additional WiX XML features. Then the resulting wxs file gets compiled by the WiX Toolset into an MSI.
For an example of using XML Injection to incorporate WiX XML features into a Wix# (C#)installation, look here In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
In that question, see my answer that uses the technique of hooking up a delegate to the "WixSourceGenerated" event.
You could then use this XML injection approach to insert some WiX XML into your installer that would accomplish the config file editing. An example of some typical WiX XML to modify config files is here:
How to modify .NET config files during installation?
Another typical requirement of an installer would be to add or modify Windows Registry entries on a target system. Wix# provides direct support for that using the "RegValue" class. The advantage there is when using Wix# you also get a full "uninstall" capability for free, including uninstalling/reverting registry entries to the pre-install state. This is a natural result of Wix# being built on top of the WiX Toolset and Windows Installer technology. An example of a registry-only Wix# installer is here: In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
The Wix# approach has been very useful in my environment, and it allows use of the familiar C# skillset without having to jump headfirst into the full complexity of the WiX XML installer technology.
The first accepted answer advocated this approach:
One good strategy is to use InstallShield LE as a simple container and
then do most of your authoring in WiX. I describe that pattern here in
my blog:
http://blog.iswix.com/2011/01/augmenting-installshield-using-windows_19.html
While that is a fine and workable approach, the approach I'm suggesting here has the following advantages:
ADVANTAGES OF USING Wix# PLUS WiX APPROACH
No need whatsoever to deal with InstallShield LE or any other proprietary installer product
The entirety of most installers are written in C# code, a familiar skill set
No need to learn the full WiX toolset environment up-front; you can start with C# code and then add the advanced WiX capabilities as you need them, using XML Injection.
The approach would work well in Continuous Integration environments, with all the components lending themselves to being XCopy-deploy installed on build servers, and all components being eminently suitable for automation by scripting, e.g., Powershell scripts.
If Microsoft changes course AGAIN on installer tools bundled with Visual Studio, you will NOT be impacted.
ELEMENTS IN COMMON WITH IS LE + WIX
Built on top of WiX Toolset capabilities, thus all capabilities of WiX XML can be incorporated into an installer
Many excellent "how-to's" for WiX solutions to deployment problems are available on SO and elsewhere
Generates authentic MSI Windows Installers, complete with uninstall capabilities and all the great features of that technology.
You will want to learn more about WiX and Windows Installer technology when creating installers. Advanced capabilities will often require dropping down into WiX XML.
Both are integrated more or less seamlessly into the Visual Studio environment. (If anything, the Wix# approach would have a slight advantage)
So, while the other approach is a workable solution, I recommend Wix# + WiX Toolset as the path of least aggravation, going forward, for VS2012, VS2013, VS201x. Perhaps the biggest advantage is that you are unlikely to ever have to have to change your underlying deployment technology and approach again, to be blindsided by Microsoft again, no matter what no matter what backroom deals Microsoft's marketing managers make to include or pull deployment technology from Visual Studio.
For a free tool WiX is your best choice. If you also are interested in commercial tools, Advanced Installer can help you create/convert the project much faster, without any scripting required. It also has a predefined project template for importing your VDPROJ. For what you need an Enterprise license is required, as you need access to its Dialogs Editor and SQL Scripts features. But you can test all of them in the trial period.
If you want to move to other installation system - NSIS or Inno Setup try this Visual Studio extension: http://visualstudiogallery.msdn.microsoft.com/5e57fe9a-ae5d-4740-a1c3-7a8e278e105b