I come from a background of Java, PHP and NodeJS development. I have successfully built continuous integration/continuous deployment environments using these languages based on a Linux Platform but now I am working in an environment with a mix of .NET web development and Java based web development.
I would like to build a CI/CD environment that shares tools and concepts as much as possible. The workflow that has worked in the past and seems to be pretty standard is:
Check code into Git
Jenkins checks out the code, runs tests
Jenkins builds the code if tests pass
Jenkins builds a package. WAR file, RPM etc. and pushes it to an artifact repo, Maven, Yum repo, Artifactory, Nexus etc.
Jenkins deploys the package to a given environment by simply pulling the correct version of an artifact and pushing it to a given box. I like to use Ansible or Puppet or some nice configuration management tool for this step and let that handle the versioning and environment specific changes.
I know Microsoft has built tools that can do similar things but I would like to keep things consistent across the organization and I feel like Jenkins is the gold-standard and has been battle tested for a hundred years while Microsoft’s CI tools are relatively new.
I am able to set up a Windows based Jenkins slave compile the code using the MSBuild plugin (This is an excellent tutorial if you are interested http://blog.couchbase.com/2016/january/continuous-deployment-with-jenkins-and-.net). I am stuck on how to package the code. I had thought NuGet would be a good choice for this but I can’t seem to find any guidance on building/deploying NuGet packages for ASP.NET applications and deploying them. I prefer NuGet to something like the web application zip file as the packages are versioned.
Is NuGet the answer or is there something else out there that could support my needs or should I be altering my thinking for CI/CD in a Microsoft environment?
Related
I have a .Net Core 3.1 application that I'd like to deploy as a Self Contained (SCD) Deployment using an MSI Installer in Visual Studio 2019...
I have published the project as an SCD Deployment and I can run this on the target machine just fine
However, I've been asked by IT support to provide an MSI installer for the application as .MSI files work well with some of the admin/control applications they have.
So I created a setup project in my solution and selected 'Publish Items' as the Project Output of the setup project and rebuilt it...
The installer seems to run just fine on the target machine but when we try to run the installed application it says that .Net Core is required ...It's as if the installer has ignored the Self Contained aspect and just installed as a regular Framework Dependent Deployment
Is there a way to create an installer that installs an SCD deployment? Have I made a mistake in my thinking?
Many Thanks in advance,
Andy
The VS Setup Project template is quite old. Most likely it was not updated to be "aware" of the SCD support so it resorts to extracting the classic output binaries from your project.
There are other free tools that you can use to create an MSI from VS, which give you more options to customize and correctly configure the package.
If you have time and want to learn a new skill, try WiX Toolset. It is very powerful but you will need some time to get started.
If you wanted to get it done quickly and avoid the hassle, use the free VS Extension from Advanced Installer. Its GUI allows you to easily create your setup package and it has native support for .NET Core packaging too. If you follow the steps from the linked tutorial it should create a working package for your application.
Disclaimer: I work on the team building Advanced Installer.
We have for a while been building various web projects with AzureDevops and self hosted build agents.
Today I had to add a new build, consisting of a windows service written in .net core 3.1. This service has to be installed by our customers, so we have to provide it in a friendly installable way. As some of our developers were already used to handle MSI/*.vdproj projects, they added a vdproj into the *.sln to manage that. On a developper machine, this is not a problem even with VS2019: you just have to use the relevant VS studio extension...
But when it comes to building that in a CI/CD context, this becomes a real challenge. I quickly understood that we can't use MSBuild at all for that and found some alternative using directly Visual Studio (devenv)... Inspired by this thread (still opened), I came up with the following command line:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv" [...]\MySolution.sln /build "Release" /Project MyInstallationProject
This worked fine both on my developer machine and even on the build agent machine. But when I add it into a build pipeline as a command line task, it seems to hang, and after a while I get the following result for the job:
##[error]The job running on agent <MyAgent> ran longer than the maximum time of 60 minutes. For more information, see https://go.microsoft.com/fwlink/?linkid=2077134
What can I do to make it work?
What are the best practices for generating a self installable in a CI/CD context? (Is MSI still relevant? )
As a workaround, you can try to install the extension Build VS Installer and use the task DutchWorkz - Build VS Installer(s) to build Visual Studio Installer Project in Azure Pipelines.
Here are some tickets(ticket1, ticket2) with similar issue you can refer to.
Our company is currently developing the Continuous Integration process in Visual Studio Team Foundation Services and we've gotten to the part where we need to replace locally saved NuGet
packages with the packages which have already been uploaded to the MyGet server (https://www.myget.org/).
We are currently investigating two things:
Is there any option in Visual Studio where the IDE detects and builds packages automatically (and that's only counting the projects in which I've done changes, not triggering the build for all of them)?
Is there a way to save the packages locally to one root folder and not in the bin folder of each project? Please bear with me if the questions are silly, I'm still new to all of this.
What is the process of swapping the locally saved packages with the MyGet packages? Is there a task which can be added in VSTS? Should a PowerShell script be written for that process?
Any guidance will be extremely appreciated.
First, the Visual Studio can’t detect and build package automatically if you’ve done changes.
Secondly, there are many ways to sync the packages, but the changes need to be pushed to server.
Publish NuGet packages to your MyGet server through NuGet push task (add it to your CI build)
Do it in MyGet build directly when code is pushed to a Git repository in VSTS: MyGet with Visual Studio Team Services
While learning continuous integration, i come across both of these terms. And i got confused. May be it is a very silly question. But i want to know in continuous integration process what are the role of MsBuild.exe and MsDeploy.exe. Can i use one over other. Or do they have there own purpose.
I have also tried to use both options but while using them i got following error on server request timeout for "www.serverurl/MsDeployAgentService"
Should i use www.serverurl.com/msbuild.axd or www.serverurl.com/MsDeployAgentService.
As far as i understand, they both build and publish application with config transform.
Please help me out.
You can't build using msdeploy, but you can build and deploy using msbuild or you can build with msbuild and deploy with msdeploy
MSBuild is a hierarchical target-based build system. It's intent it to run general purpose tasks related to building an application, and is primarily focused around compilation. Visual Studio uses this when you build your project.
MSDeploy (or Microsoft Web Deploy) is a CLI and library for deploying files (and other configuration) between servers. It handles concepts like authentication, skipping files and environment-specific parameters. Visual Studio uses this when you select "Publish".
I want to set my server to automatically build my application upon commit on SVN repo, then deploy on a test/homologation server.
What I planning to do:
install a build tool (Nant? use MSBuild?);
create a simple script and set a hook to SVN that starts the process of building and deploy.
To do that, what I need to install on my server desides the .NET 3.5 framework? Is Nant capable of build our application based only on our solution file (.sln)?
I researched a little bit, and the Nant last release, v0.86 beta 1, does not include the solution target.
Is there other alternative to do that?
Note that currently I only use the VS2008 build system, and do not call the MSBuild directly. Is that feasible and simple to setup on server environment?
Just use CruiseControl.NET or TeamCity.
They're both fully-fledged continuous integration servers with lots of features and easy to configure.
We use Hudson to do that. Like mentioned before. It supports MsBuild (and Nant). We use msbuild with as paramters the solution file and the build configuration like debug/release (we created a deploy and watin configuration with different web.config's). No extra tasks or different scripts than the solution file we us in visual studio. (which I think is the setup you're after)
Additionally before deployment we setup a webserver (cassini) with the results of the build execute nunit (watin) tests. All through Hudson, which shows a nice diagram of the nunit test results.
TeamCity and CruiseControl.Net should be capable of doing the same thing,but I found hudson to be a snap to setup, and configure. (It has everything included in a package just start it)
What's also nice is that it supports SourceCop and FxCop results which you can view in a diagram and look at the location a certain warning applies to in the sourcefile, all using the web interface.
You could use Hudson or Cruise Control for it.
They are Continuous Integration Servers, and can also run your unit tests before deploying it.
I think you are looking at installing Cruise Control.Net. It will handle automatically checking your SCM repository, and kicking off anything build related you want.
http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET
As for NAnt or MSBuild - it's a personal choice. I went with MSBuild as NAnt hasn't been updated in a while. That being said - they are both capable of doing whatever it is you are looking to do.
One note - if you compile in Visual Studio - you are using MSBuild. You can target the SLN or PROJ files with MSBuild through Cruise Control.net.
I use Teamcity and it was very easy to set up. Before that I used plain Nant. The Teamcity server realy changed things, because now everybody in the team understands what is going on on the buildserver.
It is free for up to 20 project configurations.
For Asp.Net you will also need Web Deployment Project on any type of buildserver you choose.
Are you realy shure you need to build sln? For a typical ASP.NET project this is not the best way. You usually build a WebDeploymentProject. Anyway Teamcity (and other buildservers I guess too) understands sln-files.