Visual Studio Setup project:
I have to check certain system requirements before my setup runs. (Read some stuff from a file and then continue or cancel the setup depending on the content)
I tried adding a custom action with BeforeInstall but it gets executed too late. The old setup has already been uninstalled when my custom actions BeforeInstall gets executed.
How can I tell the setup to check certain system requirements before anything else gets executed/installed/changed? Is a custom action the wrong way to do it?
Thanks
Visual Studio Setup Projects abstracts the scheduling of custom actions as Install, Rollback, Commit, Uninstall and doesn't expose the ability to schedule a custom action in the way you'd need it to run.
The only way to do this would be to use a WiX Merge Module to get the control you need and then merge it into your VDPROJ installer.
Also you should know that VDPROJ is so horrible that Microsoft has removed it from Visual Studio 11 and told customers to use InstallShield Limited Edition (Free) instead.
It is possible. I had to do this also, I came up with the following solution:
I've created a custom installer and overwrote the Install() Method.
You can now check the system information via WMI and throw an exception if they dont match your requirements, the installer will perform a clean rollback.
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 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. ($$)
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
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.
During uninstallation of the Visual Studio Integration Package that I am writing, I need to run "devenv.exe /setup" to update the VS UI and remove the package info from the splash/help screen.
However, it must run after all the add-in and package files have been deleted. My current setup (using an Installer class custom action called during the Uninstall step) causes devenv.exe to run too early, before the files have actually been deleted. This means the splash screen info does not update.
Any ideas? I just need devenv to run at the end of install, somehow - I am not bound to custom actions.
You could write your custom action as Commit execution. This means that it will only run after a successful uninstallation. Condition it as REMOVE="ALL" to make sure it's only run on uninstall.
The trick, it turns out, was to use the new Deployment Tools Foundation from MS to wrap my managed functions into an unmanaged DLL, eschewing the Installer class completely. I then use Orca (MSI editor) to add the custom action at a specific time in the install.
The Installer class only supports "deferred" custom actions, which must be run at a specific time.