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".
Related
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.
So what I'm trying to do is build a .NET Core app with MSBuild, and have it create the web deploy folder but without automatically putting it in a zip file. I can do this for .NET Framework apps by using /p:WebPublishMethod=Package and /p:PackageAsSingleFile=false, it creates the same folder structure but without adding it to a zip file. However with a .NET Core app, it seems to ignore this flag and always zips up the final package.
The reason I do not want it zipped up is I need to add a number of "custom" files to the build before I can deploy it. I can't add the files during the build itself because we have a number of different clients, and they all share the same "base" software, and then the client specific files need to be added afterwords. So I want to build the "base" software, then be able to copy the output folder, add the client specific files, and then zip up that build to be deployed to IIS. This saves a tremendous amount of time because the alternative is doing a new build for each client, even though 95% of the software is the same.
So is there a different way to accomplish this with .NET Core apps?
I've been testing with MSBuild via command line. The solution has a mix of .NET Framework and .NET Core asp.net websites. This is what i'm running:
msbuild.exe "Solution.sln" /nologo /nr:false /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=false /p:SkipInvalidConfigurations=true /p:PreBuildEvent="" /p:PostBuildEvent="" /p:BasePackageLocation="C:\Temp\BuildOutput" /p:platform="any cpu" /p:configuration="release"
This works for the .NET Framework websites, but the .NET Core websites continue to be zipped up
And just a note that the BasePackageLocation is a custom property that sets the PackageLocation to "$(BasePackageLocation)\$(MSBuildProjectName)\" so that each website is put in its own sub-directory
So is there a different way to accomplish this with .NET Core apps?
Sorry but the answer could be negative. This is one issue about publishing .net core projects, it has been reported to Product Team, there might be a long way to go before the fix.
For web deploy package mode in .net core, you'll get WebApplication.deploy.cmd in the same folder where the .zip exists, many commands in the xx.cmd are associated with the xx.zip, so it's not recommended to manually do something to unzip it.
I suggest we can track the issue there(DC) and I will update the answer if there's any update or fix :)
I have an ASP.NET Web API project created on Windows using Visual Studio. How can I set this up for use with DNX/DNVM (on a Mac)?
Switching to Git solved the source control compatibility with TFS. But I wasn't able to find references to getting a project working across both these development environments.
I'm assuming as a first step the project will have to be migrated to ASP.NET 5/vNext but wondering other problems lurk around the corner with different project members using different environments.
I get an error when I run - git:(master):dnx . kestrel
As you mentioned yes you will have to migrate any namespace changes. I have a project that is developed across both. Also changing csproj files to xproj. Support is coming for some kind of interop between the different project types but its not here yet.
For build, publish, deploy from git without relying on VS publish capabilities or MSBuild you can follow my blog post here.
Basically you use DNU to publish and then kudu to deploy.
I have an asp mvc project. I'm wondering, what's the difference between building the solution and then copying bin and all other views/scripts/images/style sheets and publishing (besides the obvious work of copying files). I'm asking because i want to automate my deployment with rake and I can't use web deployment because it's not compatible with mono.
Depending on your version of Visual Studio and settings, Publishing typically does two main things in addition to the build
Packages the solution
-- usually into some standard format (WebDeploy, Web Project)
Automates deployment
-- typically hooks something like MSdeploy ("web deploy") to synchronize the site with a local or remote IIS setting
So in terms of what you are deploying, there is no difference. The build and output files are the same. Publishing is simply allowing a developer a simple path of packaging + deploy, which you are handling with rake.
BTW Have you looked Uppercut this tool could be very useful in your build process.
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.