I want to create MSI build package as part of a TFS build.
What options there are?
i know about:
install VS on TFS server (http://geekswithblogs.net/jakob/archive/2010/05/14/building-visual-studio-setup-projects-with-tfs-2010-team-build.aspx)
Use 3rd party software on tfs
I do not wish to rely on 3rd party software or install vs 2010 on server as i have no licence to spare
Wix: http://wix.sourceforge.net/
It can be invoked using MsBuild.
I am using it quite successfully in one of my projects
This page gives some info on what is needed http://wix.sourceforge.net/manual-wix3/authoring_first_msbuild_project.htm
You should create the MSI Build package on TFS Build the same way you do it locally.
If you don't have anything yet, I strongly encourage you to look at Wix and use it. However Wix is mainly lowlevel package generation for MSI.
If you have complex needs for installation wizard you may rely on InstallShield to get the job done.
By using InstallShield (IS) you have two options:
Create a deployment project that will be 100% compatible with Windows Installer (the technology that builds .msi), no more no less. By doing that you can build your IS project pretty easily with Team Build.
Create a deployment project with the IS flavor (with a installation bootstrap) and you'll have to deploy the needed runtimes of IS in order to successfully build.
However I strongly encourage you to not choose the way you'll create your deployment package based on the Continous Integration constraints, if you have to install 3rd parties on your build agent, so be it, it won't be the toughest thing to do. (especially if those are VM you can clone)
Related
How do I integrate InstallShield/Wix/IsWix with TFS? I wish to auto generate setup files during successful TFS checkin/release?
I am comparing InstallShield with Wix and IsWix! to choose the right candidate for upcoming product development.
Tools Used
v.Next Builds
Team Foundation Version Control
Update from InstallShield support team
To integrate InstallShield with Team Foundation Server, install InstallShield on each machine that u want to be able to create, update, or build InstallShield projects.It should also be installed on a machine that is designated as a build agent for InstallShield projects that are stored in Team Foundation Server.
NOTE: The Standalone Build is a build engine that enables you to build InstallShield projects without installing the full version of InstallShield on a build machine.If you have the Standalone Build, you can install it on a machine that is designated as a build agent for Team Foundation Server."
I have very limited experience with InstallShield, but I can advocate for WiX. Recently they added a no-install option that allows you to build WiX project by just adding a few files along to your sources.
WiX code is an XML dialect and it is simple to generate, but the simplest pattern is to write a Product and a Project file and let Heat generating the remaining code you need for a simple install.
At a high level you need to create an .ISPROJ (MSbuild ) and .SLN for your .ISM. In the ISPROJ you'll want to write some code to regex parse the build number and generate a random ProductCode for major upgrades.
You'll add a build vs sln step to your build and tell it to use 32bit MSBuild (InstallShield doesn't support 64bit).
https://learn.microsoft.com/en-us/vsts/build-release/concepts/definitions/build/variables?tabs=batch
http://helpnet.installshield.com/installshield22helplib/helplibrary/MSBuild.htm
You'll need an on-prem build server and install the InstallShield Stand Alone Build engine one it. I'd go ahead and install the Automation Interface also as you don't know when you'll need it some day.
I'm new to using jenkins.I am working on C# project and using jenkins for continuous build and release. I completed creating builds for my project and got the .exe and dll files. But i need to repackage it(create a msi) before deploying to servers. So can anyone give a stepwise information for rePackaging and tool to be used with jenkins for packaging. I want to automate this process in jenkins CI AND CD.
Repackaging implies you have a third party installer that you want to reverse engineer into a new/better MSI. You are just packaging not repackaging.
This is a two part question:
Author an MSI. I recommend using WiX and IsWiX starting with this tutorial.
Build it using Jenkins. WiX supports MSBuild and Jenkins has a MSBuild PlugIn. Standard stuff except not that the .WIXPROJ created by IsWiX templates expects you to pass the MSBuild Property MSIProductVersion. The correct format for this property is 0-255.0-255.0-65535. You can tack on a fourth field if you would like but it will be ignored. The IsWiX project templates are set up for Major Upgrades by default so make sure one of these 3 fields is incremeented with each release. ( 1.0.0, 1.0.1, 1.1.0, 1.1.1, 2.0.0 )
This is more of a packaging issue than a Jenkins issue.
Take a look at WIX Toolset. I used it successfully in the past with various projects. Integration with Jenkins should be easy. There are 2 options I'm aware of:
After installing the WIX toolset, add a new WIX project to your Visual Studio solution. Once configured, commit the new project to your source code repository. Then developers can build .MSI packages on their own development workstation. Assuming you use MSBuild in Jenkins to build your C# project, the new project will "just build" and create .MSI package (remember to install WIX on your Jenkins build server). This is the recommended option.
Use WIX's command line utilities to generate MSI in a Jenkins batch step. This is more cumbersome and difficult to debug.
I am developing a Sitecore solution locally using TDS. Our source control and build server is Visual Studio Team Services (in the cloud). I would like to figure out a way to implement Continuous Integration and get builds to be automatically installed on an Integration server that is an Amazon VM (or it could be some other externally located server). I have the TDS build configuration set up to create a Sitecore Update Package. The build process works great. At the end of the build process I have the Sitecore Update Package sitting in a Drops folder in source control (TFS in the cloud). Now I can't figure out how to automate the process of getting that update package out of source control and downloading it to the Integration server and running the Sitecore command to install it.
In a perfect world you would use something along the lines of a fancy Microsoft Release Management to deploy it to the environment of choice. However, if you are like the majority of us mere mortals without the fancy tools - this should help: https://github.com/adoprog/Sitecore-Deployment-Helpers
With these pages you could just send a get request from TFS or use the logic to write a custom PowerShell post-build script. Hope this helps!
As you are using TFS you get to use Release Management for Visual Studio out of the box. This is a simple install but at this time is separate. I have an instance of RM running in a VM and attached to my VSO instance for running deployments.
I would expect this tool, which was bought by MS last year, would become more integrated in vNext.
I am trying to do a full CI-CD cycle using TFSonline.
when I go with 'AzureWebsite' along with Visual Studio Online, it provides me with a build definition using 'tfvccontinuousdeploymentTemplate.12.xaml'.
On check-in I get the output, the build triggers and deployment also happens to the azure website. The log contains build along with my deployment details, which is also reflected on the TFS portal
When I go the conventional iis route, I tried 2 steps
With Default build template and the good old ms build arguments /p:DeployOnBuild=true /p:VisualStudioVersion=12.0 /p:PublishProfile="dasd.pubxml" this does the build and deploy but I don't get the 'deployment summary', which is to be expected, because i did it via ms deploy...
I used the tfvccontinuousdeploymentTemplate and provided the build settings as the publish xml... well... build happens but the deployment does not
I'd like the build to contain the deployment summary for my deployment.
TFS Online has since been replaced by Visual Studio Online and since by Visual Studio Team Services. The XAML based build engine has been marked for deprecation and will be removed from Team Services in the near future.
The hosted build controller has since been upgraded with build templates for Visual Studio 14, upgrading to the latest tfvccontinuousdeploymentTemplate.14.xaml may also sole your issue until the XAML build engine is removed.
The new Build Engine ships with a "Deploy to IIS" task and there is a 3rd party MSDeployAllTheThings extension which makes it very easy to pick up packaged Web projects.
Your solution to switch to InRelease has since also been replaced by 2 different versions of Release Management and the latest release management feature uses the same tasks as the new build engine uses. So it's able to use the same Deploy to IIS and MSDeployAllTheThings task.
Due to the fact that this question is related to a SaaS solution, the old options are no longer available or will soon be removed.
We recently moved to Team Foundation Server 2008 from Source Safe. We are setting up some automated builds and have run into some issues with the publish of click once apps that seem to require additional installs on the build server.
I've seen posts that indicate that the Visual Studio IDE needs to be installed. I've also seen posts that say that installing the .Net Framework SDK would fix the issue. We don't want to install more than we need on the build server, but we also don't want to have to make multiple requests to our server team to install different pieces at different times. So, I'd like to know what most teams end up installing.
If it's important, we don't have a dedicated build server at this point. We are a small team (6 devs, all local). Builds are happening on our main TFS box, the SQL Server piece is the only part that is on a separate server.
If you are just compiling applications in with Team Foundation Build, then the .NET Framework will do - however as soon as you start wanting to do anything more advanced (such as running unit tests and having their results published into TFS) then you will need to bite the bullet and install a Visual Studio Team Edition on your build server. I usually just install a copy of Team Suite on the build server so that people who are licensed to use the various features can have those features run as part of any automated build.
Having to have it installed on your server is not ideal, but gives you the best experience at the present time.
Regarding using your TFS server as your build server, this is not recommended for larger teams because builds tend to be pretty CPU and IO intensive beasts - however for a small team such as yours and assuming that you don't have too many build definitions that could run at once you should be able to get away with it.
According to this, Visual Studio shouldn't be required--just the .NET Framework. One other note to consider from the link is that they recommend against builds happening on the TFS box.
Yes, I installed VS on the build server. I followed their manual for setting up TFS.