I'm trying to create a very basic "Setup and Deployment" project using Visual Studio.
What I would like is the ability to choose which components to install. Let's say that each component consists in the primary output of a single class library (i.e. each component is actually a single module or compiled assembly).
I haven't seen such an option in the standard set of available dialogs. But I have seen that with a little effort we can somehow create custom dialogs.
How can I programmatically detect which component are available as part of the setup and deployment project? (i.e. I would like the project to work even when adding or removing a component from the installation)
How do I extend or create a custom dialog that displays the list of available components?
How do I detect which components the end-user has choosen to install?
I'm somewhat familiar with Orca, the tool to manipulate .msi files as well as full blown installer applications like InstallShield, but I would like to make this using only raw Visual Studio and other available open-source tools.
Thanks for your help.
VDP (Visual studio Deployment Project) is not cut out for this kind of stuff (read: use Wix instead):
(I'm guessing you want this at runtime) You can use MsiQueryComponentState but for that you will need to pass the component GUID which in VDP you don't have control over.
This comes out of the box with everything other then VDP.
(I'm guessing you want this at setup time...) You can use Condition in order to execute custom action based upon Component Install State, in VDP you don't have control over the component id (not to be confused with the component guid) which is needed in order to preform component condition.
Related
Background:
I am working on a SDK that allows its users to create custom plugins for an existing product. There is a bit of boilerplate code/file copy/COM DLL registration required for the plugin integration.To ease things for the plugin developer, I have written a Visual Studio custom project template that uses a IWizard to create a new solution, add couple of projects, generate a number of files containing the boilerplate code as well as some batch files that get executed as a post build event.
The wizard has a number of fields (such as the copyright header that needs to be inserted at the top of each generated file) that the user can edit to customize the generated code.
The Question
I'd like to persist some of the customizations and use it across multiple runs of the wizard. I also know the usual recommended places for individual applications to store their settings is under %APPDATA%. I'd like to know if there are any other places where specifically Visual Studio extensions can store their settings or I should just treat this as an standalone application and go with the %APPDATA% folder. The reason I ask is further down the line, I like to allow the plugin developers to share these settings via VS->Tools->Import & Export Settings
You have two options. You can use Visual Studio's DialogPage which will show up your configurations in Visual Studio's Options window. You can also use IProfileManager, if you do not want your preferences to show in Options window but you still want to persist them.
I have written blog post about both of these options. These posts contains complete details and code snippets.
Integration with Visual Studio Options Window using custom controls
Persisting settings without using Options dialog in 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. ($$)
i was in the process of evaluating different tools available for creating the setup package for a newly developed software. i came to know about the visual studio's setup project facility, but couldnt get much help on its capabilities.
Can someone tell me if this tool helps me achieve the below given features
copy/paste files and folders.
create a text file, and input certain values to it.
make/update entries to the registery
check for certain services running on the local/remote system
reading certain environment variables from the system.
running a third party application.
what script language does it support
Other than Visual Studio, I had evaluated InstallShield which does provide support for all the above mentioned actions. But Visual Studio is already available, I was curious to find if it matches InstallShield in capability?
Here is the Visual Studio support:
Supported
Not supported
Supported
Not supported
Not supported
Somewhat supported ( supports prerequisites )
No scripting support
What is not supported can be implemented through custom actions (custom code).
The custom code is in form of custom actions, which can be DLLs, batch files, executables or VBScripts, with DLLs being the method recommended by microsoft, written in C/C++.
Here is some more information on what custom actions are and how such custom actions are integrated with the installer:
Custom Actions
If you want an alternative, you can try Advanced Installer. It supports everything you need and it's cheaper than InstallShield.
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.