I have come to see an Installer class item in Visual studio. Why they have maintain an seperate item for Installer. Do they create any custom installers ?
The Installer class can be used to configure items such as performance counters and message queues as part of the installation of your code. They can be included with any assembly and the most basic way to install components related to an assembly is to use InstallUtil yourassembly.dll which would contain your code and custom installers. It is good practice to provide an uninstall option for anything added in this manner.
See here fore more information http://msdn.microsoft.com/en-us/library/z3xc61bs(VS.80).aspx
I also use them to override behavior in the base installer class, such that I can run validations based on input in the MSI wizard, create files and folders, etc.
For Windows Services, I think they are required.
One thing I use an installer class is for NGEN (native images) which speed up startup. The installer class calls NGEN.exe to put it in the native images.
http://dotnetperls.com/Content/NGEN-Installer-Class.aspx
Related
I have a redistributable msi my program needs to be able to run. So far I've created a launch condition. The condition it uses is under "Search Target Machine". This needs a component ID.
This page suggests I can only determine the component ID via MSI Spy, a tool that as far as I can tell is no longer available: https://msdn.microsoft.com/en-us/library/1s08hzfe(v=vs.80).aspx
I must use a Visual Studio Setup Project, and I must distribute the 64 bit end user runtime of slimdx from http://slimdx.org/download.php.
How can I successfully get a component ID, or alternately how can I bundle an msi as a prerequisite?
MSI Spy seems an odd choice! The "standard" tool for looking in MSI files is Orca, supplied in the Windows SDK/Kit, install from Orca.msi. There are others if you search.
Look in that MSI and go to the Component table, look for a component id that is always installed (if that can be determined) and use that guid.
Ths might help with the custom prereqs:
Adding Custom prerequsites to visual studio setup project
and support for custom prerequisites in setup projects has never bneen particularly good, even when the Bootstrap Manifest Generator was around.
This might be useful if you can figure out how to alter the manifest file to add your custom prerequisite, which is what the BMG tool did.
How to install redistributable with visual studio setup?
I'm trying to figure out how to get a single-file generator installed on VS2010. Previously I got it sort-of working on VS2013 after many hours of head-banging; in both cases the primary difficulty is setting up the registry entries. Apparently VSIX files don't allow registry settings:
You can use the VSIX format to package project and item templates,
Visual Studio Integration Packages, Managed Extensibility Framework
(MEF) components, toolbox controls, assemblies, and custom types. The
VSIX format uses strictly file-based deployment and does not support
writing to the Global Assembly Cache (GAC), or to the system registry.
VSIX is the preferred deployment method for the extension types that
it supports.
My VS2013 solution involves the CodeGeneratorRegistrationAttribute and ComVisible(true) on the assembly, but after install, the extension doesn't work until the user runs devenv.exe /setup in Administrator mode. In VS2010, CodeGeneratorRegistrationAttribute does not exist in any of the SDK DLLs and simply adding the source code of CodeGeneratorRegistrationAttribute.cs to the project (as the Single File Generator sample does) doesn't seem to work (and I don't understand why the sample seems to expect it to work; .NET doesn't use structural typing, after all, so how could this attribute possibly have any effect?)
If a VSIX cannot add registry settings directly, I think a reasonable substitute is to include some code that automatically runs on VS startup. That code could find out the path of the registry hive of the running VS version and add the necessary registry settings at that time. So I have three questions:
How can I cause a method written by me, inside my extension, to run when VS starts?
How can I get the path of the current VS registry hive?
Is there any other way to add the registry information?
Eventually I gave up on making a VSIX to hold my single-file generator. I made a CodeProject article about what I did instead.
But back when I was still trying to make a VSIX file, this blog post came in handy.
What is wrong with MSI-deployment? You can do anything from there. WiX has option to install VSIX packages pretty simply, just use the embedded element <VSIXPackage>. It also offers you to create new registry keys + you get registry key unistall for free. Note that you can elevate privileges, if needed.
does your vsix have a class that extends Package?
Add code in your Package's Initialize method that runs when your package is initialized.
To get to VS based registry stuff, see Microsoft.VisualStudio.Shell.VSRegistry
I'm trying to create a NuGet package that contains both managed (assemblies) and unmanaged (native DLLs) binaries, and also support several platforms (x86, x64).
To have a better understanding of how to handle that properly, I had a look at several packages that share similar requirements, published on the official nuget feed. One of them is Microsoft.SQLServer.Compact.
Seeing what is done in the Install.ps1, Uninstall.ps1 PowerShell scripts and in the VS.psm1 PowerShell module is very helpful.
The VS.psm1 module contains definitions for a few functions allowing to control Visual Studio from within the package installation script (notably, through the $dte object). These functions are based on the Visual Studio Object Model, which I don't know yet and that is (in my opinion) not very well documented.
I was wondering if you know about a PowerShell module that would allow to easily handle the Visual Studio Object model from a NuGet PowerShell script. Alternatively, any pointer to books, blog posts, articles, ... showing a few examples about how to properly use that object model from PowerShell would be very welcome. The only examples I have found on the net usually illustrate very basic functionality.
Also, if you know about other NuGet packages dealing with both managed and unmanaged libraries that I could use as examples, that would be nice.
I could of course start from what I have seen in the files mentioned above and roll my own module, but I would rather concentrate on my package itself if there is already something available.
Thanks for your help.
Take a look at StudioShell. It is a system for bringing PowerShell automation into VS.NET and is available as an installer but also as a NuGet package to enable the sort of scenario you describe. PluralSight course "Everyday PowerShell for Developers" course has an intro to the system and there are some examples on the project site.
This may not be directly related to your post. The Package Manager Console in my opinion should be called the PowerShell Console. It gives you full access to the DTE.
I have a trivial example of using it, pure PowerShell, no t4 or extensions, to add several files to Visual Studio to automate adding Command Pattern classes.
http://github.com/jefflomax/vs-package-manager-console-cmdlets
We could certainly use a more complete library of PowerShell cmdlets to handle simple Visual Studio tasks in this environment.
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
I have an app that on first installer run needs a boostrapper where you can choose the language of the installed app, install .net framework if it's not there yet and some other prerequisites.
I've taken a look at the WiX How To: Install the .NET Framework Using a Bootstrapper
but I don't see how to use this for other custom prerequisites.
What's the best bootstrapper to use for this?
After the app is installed we have an update check on the app startup. if a new version exists we need to download it and upgrade the software.
This wouldn't be a silent upgrade because the EULA and some other stuff might change in the meantime so we still need a GUI for those checks in the updater msi. So i'm considering different options on how to do this.
My first thought was to have 2 separate installers.
The first one would be with the bootstrapper and full GUI, the other would be with minimal GUI for updates.
Is there a better option?
I'd also like the access to the update installer on the to be limited to only users that have the software actually installed.
i'm not quite sure of the best way to do this.
I'm familiar with the WiX upgrade process itself with the upgrade code etc... so that's not the issue.
I'm just looking for a way to design all this in the best way possible.
Any ideas are appreciated. I'm using WiX 3.0.5419.0 from Visual Studio 2008.
I've taken a look at the WiX How To:
Install the .NET Framework Using a
Bootstrapper but I don't see how to
use this for other custom
prerequisites.
You can use the same technique (i.e. the msbuild GenerateBootStrapper task) to install custom prerequisites, but you'll have to author your own bootstrapper packages.
One way to do this is to study the existing bootstrapper packages in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\ (or the ones in the Windows SDK) and read the documentation of the Bootstrapper Manifest XML format. The bootstrapper generator tool might also be helpful.
As for auto-updating your application: it's not supported by wix. I believe there were once plans to add this functionality under the name clickthrough, but I don't think those plans ever matured. If they did, I can't find any documentation about it.