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.
Related
I'm new to .net application (non-web application) 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.
Jenkins is not capable to pack any applications directly.
It will always use an external tool via a plugin or installed by you.
In MSI case, you need an windows agent with an app that will receive the command in command line and produce your deliverable.
Applications:
Installshield (very old - paid)
visual studio (paid)
TFS (on premises or cloud) (paid)
MSIX (? I don't know much about it)
WIX (free)
Jenkins plugin here
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 am having trouble understanding the fundamentals of octopus deployment. I am using octo.exe with the create-release and deploy-release commands. I am also using the octopack plugin.
I am getting an error but that's not really the point - I want to understand how these peices fit together. I have searched and searched on this topic but every article seems to assume the reader has a ton of background info on octopus and automated deployment already, which I do not.
My question is: what is the difference between using octopack by passing the octopack argument to msbuild and simply creating a release using octo.exe? Do I need to do both, or will one or the other suffice? If both are needed, what do each of them do exactly?
Release and deployment as defined in the Octopus Deploy Documentation:
...a project is like a recipe that describes the steps (instructions) and variables (ingredients) required to deploy your apps and services. A release captures all the project and package details so it be deployed over and over in a safe and repeatable way. A deployment is the execution of the steps to deploy a release to an environment.
OctoPack is
...the easiest way to package .NET applications from your continuous integration/automated build process is to use OctoPack.
It is easy to use, but as Alex already mentioned, you could also use nuget.exe to create the package.
Octo.exe
is a command line tool that builds on top of the Octopus Deploy REST API.
It allows you to do much of the things you'd normally do through the Octopus Deploy web interface.
So, OctoPack and octo.exe serve a different purpose. You can't create a release with OctoPack and octo.exe is not for creating packages.
Octopack is there to NuGet package the project. It has some additional properties to help with pushing a package onto the NuGet feed, etc.
octo.exe is used to automate the creation of releases on the Octopus server and optionally deploy.
Note: a release in Octopus is basically a set of instructions on how to make the deployment. It includes the snapshot of variables and steps, references to the versions of the NuGet packages, etc.
octopack is a good starter, however I stopped using it some time ago with a few reasons.
No support for .Net 2.0 projects (and I needed to move all legacy apps into Octopus)
didn't like it modifying the project files (personal preference)
Pure nuget.exe was not much more work for me.
I have a system with 8 options to deploy and manage all these .config files are causing problems for the team
So I found a Jenkins plugin for installshield. But i don't know how change the product version and product code using jenkins.
In VisualStudio, I change this options in "ProjectInstall > GeneralInformation > Product Version.
What I want to know is:
How change these information by code (jenkins configuration or Nant, or something else)
I'm using "VisualStudio 2013" and "InstallShield Limited Edition for VisualStudio 2013"
I've never used the IS plugin for Jenkins but it's probably just a wrapper for ISCmdBld.exe. If so, it probably exposes the -y and -z arguments (bottom of page) for overriding the ProductVersion and other named properties.
That said, I haven't called IsCmdBld.exe in years. InstallShield has nice MSBuild support which means you can do all of this in MSBuild and just build the .SLN like any other Visual Studio project.
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)