I would like to install an add-on to an application. The application does not create a registry key that I can use to locate it. Therefore the user should specify the directory of the program, the installer should check whether the programs files are in that directory and only if the main program is installed to that directory, install the add-on to that directory.
Can this be done with Visual Studio's Deployment Project?
As far as I can see, the VS Deployment Project checks for dependencies only when starting the installer, not after the installation directory has been specified. Id like to get a second opinion before starting to use more advanced deployment tools.
No, this is not supported by Visual Studio.
What you need can be done by using a custom action on the "Next" button of the folder path dialog:
http://msdn.microsoft.com/en-us/library/aa368322(VS.85).aspx
This custom action can check if the required files exist and set the result in an installer property. This property can then be used to condition the "NewDialog" control event which shows the next dialog. It can also be used to condition another custom action which shows a custom error message.
If you want a free solution you can try WiX. You should be able to define the custom action and DoAction published control event.
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.
How can I change Primary Output Source Path in Visual Studio 2010 Setup Deployment?
Currently the source path is:
C:\VisualC#\Projects\MyApp\Obj\x86\Release\myapp.exe
I want to change the source path to bin\release\
so when I build my setup, it packages bin\release assembly.
You need to specify post build events in your project file.
Follow the steps below:
In Solution Explorer, select the project for which you want to
specify the build event.
On the Project menu, click Properties.
Select the Build Events tab.
In the Post-build event command line box, specify the syntax of the
build event.
In the Run the post-build event box, specify under what conditions
to run the post-build event.
You can use the guide provided by MSDN here:
https://msdn.microsoft.com/en-us/library/ke5z92ks.aspx
And if you'd like to use any common Macros, here is a list provided by MSDN:
https://msdn.microsoft.com/en-us/library/c02as0cs.aspx
I hope it supports your question, please don't hesitate to ask if not.
How do I create a TFS Build which automatically runs a Release (deployment) from Microsoft's Release Management for Visual Studio 2013?
In order to start a release off from your TFS Build, you need to change the Build Definition. Luckily when you install Release Management it creates a Build Template for you to use with an example. In may instances this will be enough to get you going.
Release Management Build Process Template
Release Management Build Process Templates are not installed in TFS by default, so it won’t appear as an available build process template until you add it.
Find the Template in your server install in : C:\Program Files (x86)\ Microsoft Visual Studio 12.0\ReleaseManagement\bin\
TFS 2010 : ReleaseDefaultTemplate.xaml
TFS 2012 : ReleaseDefaultTemplate.11.1.xaml
TFS 2013 : ReleaseTfvcTemplate.12.xaml (or ReleaseGitTemplate.12.xaml if using GIT)
To add the release management build process template, you will need to check it in to your TFS source control in the BuildProcessTemplate folder in your project. Then add the build process file when editing (or adding) a Build Definition. Once the release management template has been added to the list of build templates, you can start using it.
Please ensure you use the above templates from the Release Management Server and not the client directory as I did initially. You will get rather odd errors during your build if so, such as:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (3883): Web deployment task failed. (Unknown ProviderOption:DefiningProjectFullPath. Known ProviderOptions are:skipInvalid.)
Package Pickup \ Path to package.
When you set up your components, Release Management needs to know where to pick up your installation files to do something with them. When you created your Release Template it should be connected to a specific build by selecting the build definition that will initiate it (also tick "can trigger a release from a build?"). When you add the components to install as part of your release you specify their Source. "Builds with application" should be selected. The bit that got me was the big empty box next to the Build Drop location which is a mandatory field. My initial reaction was to fill it with the name of the msi file I was trying to deploy. That makes sense right? wrong. If I queued a build from Visual Studio I kept getting the following message.
Package location '\\blah\blah\Build Name\Build Name_20140707.3\A.Product.To.Install.msi' does not exists or Deployer user does not have access.
The file did exist in the location and the user the deployment agent was using did have access to the drop directory. I had also confirmed it was able to access it using ProcMon. After sleeping on it I decided to hover my mouse over the input box and a nice tooltip pops up saying:
The package path relative to the build drop location is required for
component bound to a Release Template. If the package is directly at
the root of the build drop location, you need to enter the '\'
character.
So, after my eureka moment, I deleted the msi file name and replaced it with a "\" and queued the next build. It worked. In retrospect I think they should remove the mandatory requirement for something to be entered to replace the need to enter a "\". It's a little hidden and not intuitive.
See MSDN Article here for more info
For Modified Build Process Templates
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. ($$)
Folks,
I am creating an installer project in Visual Studio. This is done using a project of type "Setup and Deployment".
I lay out the file structure of my final install in the "File System" View of the project.
Now, some of the files I create as part of my install are updated while my application is used. I would like these files to not be removed during an uninstall of my application. Is there any way in Visual Studio to designate a file as "protected from uninstall"?
Thanks for your help.
In the Solution Explorer window, in the Setup project, click the file. Then in the Properties window, set the Permanent property to True.
I'm not sure how to do it in the installer, but any file that you create from the application will be preserved in the event of an uninstall.
If you can stand it, maybe you could create these files as a first-time initialization in your application.
Of course, this can lead to other problems (permissions to create a file), but it might be easier than fighting with the cryptic installer setup.