I'm using a VS 2008 Setup and Deployment project to deploy a mixed managed / unmanaged application. I've had trouble registering mixed-mode DLL's using the built-in registration property ("vsdraCOM" enumerated value of the "Register" property.) As a workaround, I've added a .NET custom install assembly (with a class that derives from System.Configuration.Install.Installer.) I'm certain that that class is running and a number of operations successfully install and uninstall through code in that assembly, including executing the Dll(Un)RegisterServer entry point of a number of assemblies.
However, one DLL is not successfully registering. It is the only DLL that depends on some 3rd-party redistributable assemblies that want to be installed to the GAC. I have those assemblies installed to the GAC thanks to the built-in support for that in VS 2008's setup and deployment projects, and I know that is working. I've confirmed that what is happening is that the custom action is executing before the installer executes the GAC installation.
Whew. So my question is, is there a way to force the installer to execute the GAC installation before executing the custom action? Is there a way to use the "Condition" property of the custom action to do this? If not, what's my best alternative? Capturing the registry entries from the DLL and adding them to the registry settings for the installer (don't like this because someone may add new COM servers to the class in the future)? Using .NET code to install the assembly into the GAC manually (don't know how to do that yet)?
Thanks,
Dave
The setup projects you can create in Visual Studio are very limited. It only allows custom actions to be scheduled at 4 points. However, MSI allows custom actions to be scheduled at any point in the process with some restrictions on what they can do.
My first solution is to stop using Visual Studio 2008 as your setup development tool. The Visual Studio team has tried to abstract away all the complexity of creating an install. However, in the process they have also taken away all the flexibility of MSI. Wix, InstallShield, or Wise are much better products for anything but simple installs. I started off using Visual Studio for our installs and it ended up being too much work. There was always one more workaround to be implemented and its side effects to be dealt with.
If you can't switch technology, then you will need to learn how to manually modify the resulting MSI file. In your case you will need to modify the InstallExecuteSequence table, http://msdn.microsoft.com/en-us/library/aa369500(VS.85).aspx. You can do this manually through Orca, http://msdn.microsoft.com/en-us/library/aa370557(VS.85).aspx or through the MSI API http://msdn.microsoft.com/en-us/library/aa372860(VS.85).aspx. Make sure to download Orca and run the validation scripts against your install. The scripts point out numerous problems that fixing will save you countless hours when deploying to customer machines.
Related
I have created a Windows Installer for a windows service with VS 2017. The windows service has a project installer and service installer class inside it. When I cancel the uninstallation process midway, the process removes the windows service but does not update data, so the next time I run the setup , I get the option to Repair or Uninstall the windows service. Attempting to uninstall the windows service now gives an error that "the specified service does not exist", and hence the uninstall process rolls back. Now the system is in a state where the service can neither be installed nor uninstalled. To be able to remove the service completely, it must be installed once again from the command line, so that it can be properly uninstalled. Is there a way around this issue? I thought of using the service install table to make sure that the service is properly removed even on cancel, but then I get the error that service is already installed when trying to install the service [The Project Installer/Service Installer classes do this installation, I think]
First make sure that you've done all the custom action service installer nodes, in particular have the Commit and Rollback node custom actions populated. These custom actions all work together, so if you have missed one of them that could cause the problem. In theory, canceling the uninstall should have noted that the service is no longer installed, and it should be re-installed.
If that's not the issue, then it's probably a bug. The most useful thing you can do to fix it is to override base.Uninstall() in the installer class and add some code to check the service is actually installed before calling base.Uninstall().
Visual Studio setup projects are the only ones that use code to install services, and they are custom actions to call installer class methods. Everyone else uses the ServiceInstall and ServiceControl tables supplied by Windows Installer.
Some of the options you can use if you don't want to completely switch to another tool such as WiX are:
The ServiceControl and ServiceInstall tables aren't too complicated if you know something about services. If you scroll down from here to the paragraph about Visual Studio and installing services there's an article and a program to help with that:
http://www.installsite.org/pages/en/msi/tips.htm
You could dive into WiX enough to create a merge module that will install the services, together with any start/stop actions required. Then merge that merge module into your Visual Studio setup. No custom actions are required (and install classes are custom actions so you don't need them).
MSVS Installers & Custom Actions: You are using the Microsoft Visual Studio 2017 Installer Projects? They are very limited. The use of custom actions for service installation is one symptom of this. The use of custom actions in general is a very error prone approach (might be an over the top write-up), and for service installation it is almost never the right approach. Get rid of custom actions whenever you can and your deployment failure rate will drop.
Built-In Service Installation Features: You should use the built-in service installation features of Windows Installer (ServiceInstall and ServiceControl tables - which you seem familiar with), and there are a number of tools that can help you do this. Here are some alternative tools (free and commercial) that you can use. WiX does the job nicely, but does have a learning curve.
Service State: I would reboot in your case, to get rid of the service's current error state. It might be in some odd state pending deletion that could cause weird test results. I never take the time to investigate such issues properly, instead prefering to try and eliminate them by a simple reboot to get rid of the error state. Then do the deployment right with built-in features and that error state should never occur. A problem removed is ten problems solved? ( wishful thinking :-) ).
Visual Studio Publish Project Into One Simple Installer
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
I'm developing a Visual Studio application with WPF, but right now is the moment where I have to choose my installer.
I need my project to be able to write on the GAC and on registry, but I'm not sure if I should use Visual Studio installer or Wix... I can't find on Google information that says exactly the differences between both of them.
I found that Wix is more complete, but I can't find any article that specifies real differences between one or another...
Can anyone help me to find more specific information or to choose between both of them?
EDIT: Sorry, I specify:
I'm using Visual Studio 2010 professional.
The end product is the same, a windows installer msi.
It's just different how you get there. With the old vdproj there wasn't much other than setting up files to be copied and registry keys as far as I remember. Anything else and you would have to create a custom action in C++ or VBS, not a particularly easy task if you are .net developer.
However with the advent of Wix there are a lot more in-built custom actions which enable you to create a rich installation experience and if you need to create your own custom action you can use .net. Also it is much easier to create a bootstrapper which can install dependencies along with your msi as well as being able to create a front-end in WPF.
As #nvoigt said the old vdproj type is not supported in VS2012 and it also cannot be built by a build server without doing some nasty setup (you have to install VS).
All in all there really should be no question of what to use, Wix is the way forward.
Caveman_Dick wrote:
"Anything else and you would have to create a custom action".
And that in a nutshell is the difference. Visual Studio Deployment Projects heavily abstracts you from the underlying windows installer and seals away a great deal of it's ability. This goes against the very design of Windows Installer which is supposed to be a declarative, transactional programming model.
Take installing a Windows Service as an example? Windows Installer has the ServiceInstall table. VDPROJ fails to expose this so you are off writing brittle custom actions resulting in a less elegant and less robust installer.
WiX on the other hand is a very thin abstraction. It's all about XML XSD elements and attributes that represent the underlying Windows Installer table data. The build process simply transforms the XML to SQL tables. If MSI can do it, WiX can (99%) do it.
VDPROJ was a horrible mistake and Microsoft has finally owned up to it and killed it. Now WiX doesn't have UI designers ( I've written one on CodePlex though) so you might also want to consider InstallShield Limited Edition (FREE).
Using a combination of ISLE and WiX I can get the best of both worlds.
With Setup projects no longer shipped with current versions of Visual Studio, you might want to use Wix. Otherwise, you will have to write it again once you switch to a current version of Visual Studio.
I have created a winforms app and a setup and deployment project for that app (VS 2010).
All I need is this:
When a user runs the msi, right after he selects the installation folder I want to check if the main executable of the application already exists in that folder. In that case I want to break the installation and prompt the user to either uninstall the existing application or choose a different folder.
I would like, if possible, to not use any custom installer action. At first, a launch condition (with a file search) seemed to be the right way, but it seems launch conditions (since they are 'launch') run at the beginning of the msi execution and not after folder picking.
Visual Studio Setup and Deployment Projects don't support this type of authoring. It's one of the many reasons that Microsoft removed that project type from Visual Studio 2012.
The only way to do it using this tool would be to build an MSI and then use ORCA to create a transform authoring the validation custom action and scheduling it into the UI as a gating control event. You could then write a postbuild script to apply the transform to the MSI every time it gets built.
Very advanced stuff and frankly not worth the effort. It would be far more beneficial to switch to a tool that supports doing this such as Windows Installer XML (FOSS) or InstallShield 2012 Professional. ($$)
Greetings!
I have a solution in VS2010 that defines 3-4 individual applications.
These 3-4 apps are individual (but related) components that I need to have individually installed on our production servers during deployment. I toyed with using WIX mondo to generate a multi-feature WIX installer, but found that it would be more beneficial to allow that these applications be able to be installed individually as well as via a single-source for all of them, preferably configurable to choose which to install during an installation.
I noticed that there is a WIX project type called "Bootstrapper Project" but I cannot find much documentation around it on the web, and do not know if it is a project type that will actually assist me in creating a deployment installation bootstrapper for my projects. (i.e. a setup.exe file that will install, one after the other, each project as either defined in the installer, or optionally selectable via the installer as it runs)...
what is the best method to do this within WIX, using pre-existing WIX installers for individual programs?
In Wix, the support to create a bootstrapper is through a tool called "Burn". Burn has been pushed out to v4.0 (or version 3.6). So that isn't much help.
You can use an open source tool like dotNetInstaller: http://dotnetinstaller.codeplex.com/
Here is an overview on how to create a setup installer that checks for the .NET Framework (which in and of itself is not very useful, but shows you how to work with dotNetInstaller):
http://www.lostechies.com/blogs/gabrielschenker/archive/2010/05/19/creating-a-bootstrapper-with-dotnetinstaller.aspx
Or you can follow the instructions here: http://msdn.microsoft.com/en-us/library/ms165429(v=VS.100).aspx
And use the Bootstrapper Manifest Generator here (although there appear to be 64-bit issues): http://code.msdn.microsoft.com/bmg
I am working on a project that consists of installing some Visual Studio templates. Part of the requirement is that the VS executable must be called during Commit and Uninstall phases to make VS aware of the templates. I don't have much information or any proper examples to go on, and I'm pretty new to setup and deployment projects. So, my question is:
How, within the context of a Custom Action in a Setup and Deployment project, can I determine the location of the VS 2008 executable and call "devenv.exe /setup"? I know that this information exists in the registry (and I've located it), however I have no idea to add this as logic within a custom action.
Additionally, if anyone has any experience in this area and has any good links or any advice on the subject of things to know and be aware of, please feel free to chime in.
Two methods i used to simplify complex operation in deployment projects, which I believe can assist you:
Create a external DLL, with Install/Uninstall methods, that will be called. example.
Use Wix as an alternative.
With an installer class, you can easily check the registry for devenv location:
HKLM\Software\Microsoft\VisualStudio\X.X\InstallDir