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. ($$)
Related
We're working in quite a large project and is having a hard time getting people to configure their Visual Studio correct (tabs instead of spaces etc.). We found a great solution in using the EditorConfig extension for Visual Studio.
However there are still some developers that seems to ignore our request to install this extension to their Visual Studio and hence I'm wondering if there is any way to force an extension to be installed before a solution can be opened, maybe some setting in the .sln file?
No there is no such option built-in. If your machines are domain joined, you could push out the installer through System Center or domain logon scripts.
You could cheat and create a solution level pre-build step. Create a target file named: before.{solutionname.sln}.targets and store it next to your solution file. Check it into source control. In the targets file you can use standard MsBuild to see if the extension is installed (you'll need to check the file system probably) and if not present force the installation by calling vsixinstaller.exe to trigger the install.
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.
I'm working on a Visual Studio Setup project which consist over 10Gb Cab File. My question is: How can I publish this project on the two disk and display a message box prompting the user to insert a next disk?
I don't know if there is a native "Microsoft way" to do this but InnoSetup supports that feature and I use InnoSetup for all my setup projects including VS projects. I usually use silent installation for VS packeges. You can use InnoSetup to split your VS setup into pieces and after merging them at installation time, VS setup can be triggered.
Check this link: http://www.dateiliste.com/en/source-code/17-inno-setup/57-how-to-split-up-large-files-with-inno-setup.html
when I build solutions in Visual Studio, that generates installer files as .exe and .msi, .exe files are useful for what?
The .EXE file that is created by the installer project is a bootstrapper for the .MSI setup file. It is used to launch the .MSI setup file.
Generally, both will launch the setup program and allow the user to install the application. However, sometimes the setup.exe file will run a custom validation routine to determine if the user's computer meets the minimum requirements for installing the software.
For example, if the user does not have Windows Installer, they will not be able to launch the .MSI file, but the .EXE application will still run and inform them that they need to install Windows Installer first. For .NET applications specifically, the .EXE file verifies the presence of the appropriate version of the .NET Framework, and if it is not present, it prompts the user to download and install it.
You can customize the prerequisites that are required for your application in your installer project using Visual Studio. See these MSDN articles for details on how to do that:
http://msdn.microsoft.com/en-us/library/ms165429(v=VS.100).aspx
http://msdn.microsoft.com/en-us/library/7eh4aaa5(v=VS.100).aspx
Others have commented on the how (.exe bootstraps the .msi) but part of the reason why is that users know that .exe files are the things you run. I don't think your average user knows that .msi files are something that you can click on to install an application.
The .exe file is made for installing the prerequisites of your application.
Let's say your application uses the .Net 3.5 framework, you can tell the installer project to include the installation of the needed libraries if they're not already installed.
You may also deactivate it, so only the .msi is being created.
This page shows how to activate and configure the prerequisites setup, just uncheck the checkbox in order to deactivate it.
You also find more details on the process of Bootstrapping on MSDN:
the capability to automatically detect
the existence of components during
installation and install a
predetermined set of prerequisites
.exe files are useful for executing your programs that you've just built in Visual Studio, assuming you're not doing web applications.
Pretty much every Windows program out there is executed using files with an .exe suffix.
Installer exe files are normally just the msi wrapped in a bootstrapper. The bootstrapper can do anything, but normally its purpose is to ensure the user is running a sufficient version of Windows Installer, then extract the msi and invoke msiexec.exe to start installing the msi. Generating installers as exe's is deprecated these days, but some still do it.
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.