I just realised I can not run my vdproj file from msbuild without calling Visual Studio.
What a showstopper for atomated builds!
Can you recommend another installer, that allows to compile your setup for a .NET 2.0 Winform-application from commandline?
WIX see:
http://wix.sourceforge.net/
Established, open source MSi based installer. Better still you can migrate buildt msi's from the output of your vdproj. Plus you not longer need to have visual studio to do your builds.
Most any other installer tool can. Inno Setup, NSIS, etc.
We have an automated build setup that uses calls .vdproj files from TeamCity. One key component is that we had to automate generating a new GUID every time we do a deployment build. (Perhaps that is the "showstopper" you were referring to.) Here is a workaround that supports it:
http://www.codeproject.com/KB/install/VersionVDProj.aspx
It parses your .vdproj file and updates the Package and Product codes. Here are some relevant snippets from our MsBuild file that do the deployment setup:
<Target Name="Update-Vdproj-Version">
<Exec Command="Tools\VersionVDProj\VersionVDProj.exe -msi Deployment\KillerAppSetup\KipperAppSetup.vdproj version=$(Release)" />
</Target>
<Target Name="Build-Setup">
<Exec Command="$(DevenvPath) KillerAppSetup.sln /build Release" WorkingDirectory="Deployment\KillerAppSetup\" />
</Target>
So, it can be done, and it is being done!:) Granted that Visual Studio Setup and Deployment projects are fairly primitive, but if they are all you need, this works.
Related
I have a dll project which I need to install into the GAC, on our Production machines.
(I wish I didn't have to use the GAC but SSIS insists)
gacutil.exe is not available on the target machines and using "Enterprise.Services" from PowerShell does not work (I don't know why)
My understanding is I should created a msi installer project.
However after installing the Setup and Deploy Extension to Visual Studio (2015 soon to be 2017), I discovered those projects cannot be built by our Build Server because it uses MSBuild, and MSBuild can't build vdproj project files.
What is the correct way, using a CI build pipeline (MSBuild), to create build artifacts, which can install dlls to the GAC, of a Production Environment?
Note: there are several partial answers on SO, but I could not find any, which were up to date/answer my whole question. Please keep that in mind when answering.
You need to break this down into several user stories. You aren't finding partial answers, you are finding actual answers for specific questions. What you ask is more like an epic.
In general I would create an MSI using Windows Installer XML. WiX/MSI can install files to the GAC without using GACUTIL. If you use the WiX Visual Studio extension "Votive" you can create a .SLN / .WIXPROJ / .WXS that can be built using MSBuild. You can then put this into a source control system such as Git/TFVC/Subversion and use a build system such as VSTS V.Next Build, XAML Build, Concourse, Jenkins to automation the pipeline to build the MSI.
Background: We've got a single .NET solution which contains multiple projects, some of them are compiled against the .NET Framework, some against .NET Core (UWP). We use Visual Studio Team Services (was Visual Studio Online) to build our solution continuously.
Challenge: The UWP projects require different MSBuild arguments and platform settings. We created a build definition as per screenshot below: the solution is built first using the .NET arguments. Then, for every UWP project, we have an MSBuild step.
Problem: Every time we add, remove, or rename a UWP project we have to update the build definition. We would like to somehow select the UWP projects automatically, ideally using a Visual Studio Build Step and no custom scripting. Any ideas?
Working alternative: Originally, we split the solution into two (one solution per platform) and had two different Visual Studio Build events running against each solution. We prefer to work in one single solution though.
There isn't any easy way to achieve this without custom script.
You may trying creating a MSBuild project file and add your projects in it with separate arguments like following:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<MSBuild Projects="Project1.csproj" Properties=Arguments1/>
<MSBuild Projects="Project2.csproj" Properties=Arguments2/>
</Target>
</Project>
Then you just need to build the project file in your build definition. But this will require you to update the MSProject file when you have project added/changed.
The Msbuild step supports wildcards, so you could set it to build **/*.uwp.csproj if your projects follow this naming pattern.
I've adopted a Visual Studio solution that contains a number WiX projects. We build the solution from an MsBuild script to generate the product's installer msi.
The problem I'm experiencing is that if I build (and don't rebuild), even if exe's and dll's get updated that need to be put in the installer, the WiX build system doesn't seem to detect this and skips building the installer as it thinks it's already up to date.
How do I work out what the dependencies are that are needed to build a WiX project, and how do I tell the Wix build system to watch out for them changing so it knows to build instead of skip?
Thanks.
This facility was added to WiX 3.6 with little fanfare - in the WiX 3.6 release notes it simply says ".wixproj MSBuild projects support incremental build."
The WiX MSBuild targets don't currently support payloads as inputs into the build process, so nothing tells MSBuild that the WiX targets need to be called. Feel free to file a feature request at wix.sf.net; a couple of us have been talking about ways to do it.
If you can include the projects that create the exe's and dll's into the solution containing the wix projects, you can add project references from the wix projects to the appropriate application projects. Then wix should properly perform incremental builds.
I configure my wix projects to only be included in the release configuration so that the apps can be quickly built and run without creating the install in the debug configuration.
We want to create an .MSI package from a web deployment project in Visual Studio 2008.
Now we want to use continuous integration and we would need the .MSI package build in the nightly builds.
Till now we used standard Visual Studio Web Setup project, but this is not compatible with the MSBuild. So we decided to use WiX.
The problem is that I have not found any good tutorial/documentation about this.
Is there a way to do a WiX installer package from a web deployment project? If yes, how?
Also, I tried to use heat.exe to create the XML for the WiX project .wxs file, but it seems that heat.exe doesn't recognize the web deployment project format.
Thank you for your responses.
Regards,
V.
I wrote a blog post about this recently - http://www.chrissurfleet.co.uk/post/2011/07/01/Using-Packaged-Project-Output-in-WiX-and-Visual-Studio.aspx
In short, its fairly easy to use msbuild to package up your web app and then pass it to heat to generate your installer from.
Hope this helps.
You've probably long since found a solution for this, but to elaborate on Tom Cabanski's answer, you can invoke Visual Studio to build the msi on the command line using "devenv.com" via an external process from within your build. It's not a pretty as using msbuild, but it gets the job done. Below is an example of how to invoke Visual Studio:
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.com" your.sln /build Release
Where your.sln is the solution file for the solution you wish to build, and Release is the configuration you wish to build, ensuring that the configuration you choose actually builds the vdproj project.
Following the successful execution, you can grab the msi from the appropriate configuration's bin, and do what you want with it.
I'd appreciate your response to this with your findings/approach, as I'm trying to decide whether to adopt WiX or InstallShield as the approach to building msi's for Web Applications within TFS Build, or to continue with the approach I just described. I haven't had to opportunity to try WiX out, and my very limited exposure to InstallShield suggests that this is far to involved for my need, which is to produce a simple deployment aid for some relatively straight-forward web applications to the company intranet via TFS Build.
We used WIX on the installers for our last couple of projects and ended up regretting it. I would stick with the VS built-in projects and just invoke the VS IDE from the command line in the CI build.
Background:
I always try to ensure the following tenet in my projects:
After a fresh checkout a developer should be able to do all project related tasks with solely the contents of the combined folders.
Obviously, this isn't always possible (e.g. Visual Studio for Windows development). However, I really dislike having to install any third-party libraries or tools that are specific a project like log4net, NHibernate, NUnit, etc. There are number of reasons for this including:
For a given development machine, you may work on several different projects, all which leverage different versions of the same third-party library or tool.
Minimizing the environment setup requirements makes setting up new developers or machines much easier
Facilitates easier maintenance of automated builds
Assumptions/Contraints
I am currently using WiX 3 beta, but if there is way for either 2.0 or 3.0 please respond
I am using Visual Studio 2005
The IDE syntax highlighting is not a requirement.
Question:
Is it possible to avoid local installation of the WiX toolset and use flat files instead? If so, please explain how.
See Also:
First, build your WiX installer:
Create a new WiX Installer Project in Visual Studio 2005.
Build your WiX XML accordingly.
Now, to integrate the WiX toolkit into your source tree:
Copy c:\Program Files\Windows Installer XML v3\bin to a sub-directory in your source tree. I used WiX\bin relative to my .wixproj file.
Copy c:\Program Files\MSBuild\WiX\v3.0\ to a subdirectory in your source tree. I used WiX\v3.0 relative to my .wixproj file.
Either add the following code or replace the line that follows:
<WixTargetsPath Condition=" '$(WixTargetsPath)' == ''>$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets</WixTargetsPath>
With the following lines:
<WixToolPath>$(MSBuildProjectDirectory)\WiX\bin\</WixToolPath>
<WixTasksPath>$(MSBuildProjectDirectory)\WiX\v3.0\WixTasks.dll</WixTasksPath>
<WixTargetsPath>$(MSBuildProjectDirectory)\WiX\v3.0\Wix.targets</WixTargetsPath>
As you can see, the WixToolPath, WixTasksPath and WixTargetsPath directives reflect the location of the folders I've instructed you to copy.
Rename your .wixproj to .csproj. This ensures that Visual Studio does not get confused by the .wixproj file but because the .wixproj is a valid MSBuild project, Visual Studio will be able to work with it.
Using this method, the WiX directory as described is about 9MB large.
I know with WiX 2, you can just download the executable files and the dll's to whatever directory your project is in. Then you create a .bat file to run candle.exe and light.exe with the parameters you need to build your installer.
That way, all your projects can have their own version of WiX with a disk drive hit of only about 4 megs each.
I'm not positive, but I think you can do the same with WiX 3.