Fairly new to Azure DevOps and PipeLines, but we are stumped by the fact executing an MSBuild command locally or through publish in VS2019 gives us a complete ready to publish folder, while the same command in Azure DevOps pipeline seems to be doing nothing but build.
Local command:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild" Webshop\Mvc.csproj /p:PublishUrl="c:\Publish\Mvc" /p:DeployOnBuild=true /p:Configuration=Release /p:WebPublishMethod=FileSystem /p:DeployTarget=WebPublish /p:AutoParameterizationWebConfigConnectionStrings=false /p:SolutionDir="." /p:PrecompileBeforePublish=true
MSBuild task:
steps:
- task: MSBuild#1
displayName: 'Build solution'
inputs:
solution: '$/MVC_Projects/<more here>/Webshop/Mvc.csproj'
msbuildVersion: 16.0
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
msbuildArguments: '/p:DeployOnBuild=true /p:DeployTarget=WebPublish /p:PublishUrl="$(build.artifactstagingdirectory)\publish" /p:WebPublishMethod=FileSystem /p:AutoParameterizationWebConfigConnectionStrings=false /p:PrecompileBeforePublish=true'
We tried playing with the parameters, but that does not seem to have much effect (or we don't know which parameters to tweek). The most we got was adding an /p:DeployTarget=Package and /p:OutDir="$(build.artifactstagingdirectory)\bin" would copy the bin folder. This was still without the .compiled files we were expecting though.
The project is an ASP.NET MVC Framework 4.8 application. The code does build properly and without errors. The logs do not hint with any warning or tasks not being able to be completed, so no clues there. We require the output folder for the full website and not just the DLL's to make our migration to DevOps easier. Having the folder allows other deployment processes to remain the same.
This might not be best practice, but it is practical for us at this moment in time.
Question 1. Why is MSBuild doing something else locally than in the DevOps Pipeline? Is it perhaps picking up configuration files we are unaware of ?
Question 2. What settings (or perhaps other task) would we need to set up to get the same local publish folder appear in the $(build.artifactstagingdirectory) folder in DevOps ?
Any insight, direction or solution is appreciated.
SOLUTION
After many checks and trials in the build parameters and pipeline setup, it was a DevOps server installation issue. The DevOps server had a full version of 2022 installed and only a partial version of 2019. Although the builds did not give any error or warning, the artifacts were not created without the 'ASP.NET and web components' for Visual Studio 2019 being installed. After that component was installed, the builds ran just fine and as expected.
Lesson learned is to double check local development installation with server installation with relation to installed (individual) components when results vary, even if there are no errors.
Related
I have installed TFS 2018 Community and was trying to publish a project to plesk domain using one of the publish profiles in the arguments of msdeploy task as shown in the picture below but it only build the project but did not publish it like I thought it would
Generally if you can run the msbuild command successfully with the arguments on local VS, then it should be also available in TFS.
So, please check below things to narrow down the issue:
Just make sure you have the same components installed and configured
on your build agent machine.
Make sure you have the correct configuration for your build
definition.
Based on your screenshot above, just try to set the correct buildPlatform and buildConfiguration (consistent with your project settings in VS).
Also verify that if you have checked in the PublishProfiles, and check the first Get sources step, make sure the system can get the sources and PublishProfiles during the build process.
This article for your reference : TFS 2015: deploy website to IIS without installing extra add-ons to TFS
UPDATE:
In order to use Publish Profiles on the build server, you have to have some of Visual Studio's prerequisites. Make sure you have installed the full version of Visual Studio on the build agent machine.
Besides, you can try with below arguments (Just change the PackageLocation value accordingly) :
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Referecne: Working with Web Deploy and Release Management for the deployment.
I have a build definition in Visual Studio Team Services (a.k.a. Visual Studio Online? I'm not really sure the right name for it honestly) that is not producing an artifact, and I'm really not sure why. The main project in the solution file is a Windows service that is built using TopShelf. I suspect that maybe the MSBuild arguments in the Visual Studio Build task might be wrong. I copied them from a build definition for an MVC project that is working, but it occurs to me that they might not work for a Windows service.
Here they are:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.artifactstagingdirectory)\\"
I have a Copy Files task and a Publish Build Artifacts task later on in the process, but apparently the $(build.artifactstagingdirectory)\\ is empty. I get this warning:
##[warning]Directory 'd:\a\1\a' is empty. Nothing will be added to build artifact
Oddly enough, in another task in the process where I publish the symbols, everything appears to go off without a hitch.
One more bit: I'm using a hosted build agent. Not sure if that matters or not.
That's all of the pertinent information I can think to provide. Am I way off base here? I've used Octopus Deploy in the past and I know I had to install Octopack on my services. Do I need to do something similar here?
You don't need any of those MSbuild arguments; most of them apply to ASP .NET projects and will do nothing for a console application.
Replace them all with /p:OutDir=$(Build.ArtifactStagingDirectory). That will tell MSBuild to put the build outputs in the artifact staging directory.
I thought this would be a pretty straightforward task and there is quite a bit of documentation out there but I've had zero luck with any of it and am assuming that it is pretty much all out of date.
I have .NET Core MVC 6 Web App that I've been developing for a while and need to set up a WebJob for it on Azure. I want to deploy this alongside the app using the continuous deployment system Azure provides that the app is already using. According to Kudu docs it's possible:
https://github.com/projectkudu/kudu/wiki/Web-Jobs#deploying-net-console-webjobs-alongside-an-aspnet-application
Which states:
This works both when deploying directly from Visual Studio
(WebDeploy), or via git.
It references this link (https://azure.microsoft.com/en-us/documentation/articles/websites-dotnet-deploy-webjobs/), which I've been attempting to follow with no success.
I have the latest version of Visual Studio 2015, .NET Core 1.0.0 & Tools and the Azure SDK.
First thing that becomes apparent is that I do not have the scaffolding options as shown in the screenshots on the Azure docs and after failing to find any missing dependencies I resorted to trying to set it up manually as described.
Even after putting the required files in the locations specified (webjobs-list.json and webjob-publish-settings.json) and configuring them for my project, and adding Microsoft.Web.WebJobs.Publish to the WebJob project, Kudu does not find the WebJob via the continuous deployment system.
I've tried several approaches and variations based on the documentation I've found out there but I just can't get it working and all other SO questions are year(s) old.
Does anyone know what I'm doing wrong? Is this even still possible with the latest version of .NET Core MVC?
WebJobs' files are stored under the 'App_Data/jobs/continuous' or 'App_Data/jobs/triggered' folders, so one way I could use to deploy both Web App and WebJob is manually copying all WebJobs' files needed to these folders during build time. I think this will fit while VS tooling is being updated.
My solution is a little different from yours since I'm using Visual Studio Team Services to build and release my app to Azure, but the concept is the same. You can use a post build event in Visual Studio to run a script that copies these files to the jobs' folder.
Below are the steps I've configured in VSTS build definition:
Command Line task:
Tool: dotnet
Arguments: restore
Visual Studio Build task:
Solution: **\MyApp.sln
Platform: $(BuildPlatform)
Configuration: $(BuildConfiguration)
Visual Studio Version: Visual Studio 2015
Command Line task:
Tool: dotnet
Arguments: publish -c $(BuildConfiguration)
Command Line task:
Tool: dotnet
Arguments: publish -c $(BuildConfiguration) $(Build.SourcesDirectory)\src\MyApp.Jobs\project.json
Copy Files task (this is the trick):
Source folder: src/MyApp.Jobs/bin/$(BuildConfiguration)/netcoreapp1.0/publish/
Contents: **
Target folder: src/MyApp.Web/bin/$(BuildConfiguration)/netcoreapp1.0/publish/App_Data/jobs/triggered/MyJobName/
Archive Files task:
Root folder (or file) to archive: src/MyApp.Web/bin/$(BuildConfiguration)/netcoreapp1.0/publish/
Prefix root folder name to archive path: unchecked
Archive type: zip
Archive file to create: website.zip
Replace existing archive: checked
Copy Files task:
Source folder:
Contents: **/*.zip
Target folder: $(Build.ArtifactStagingDirectory)
Publish Build Artifacts task:
Path do publish: $(Build.ArtifactStagingDirectory)
Artifact Name: drop
Artifact type: Server
We have just installed TFS 2015 (Update 1) on-premise and are trying to create a Continuous Integration/Build system using the new TFS Build system. The build works fine, and gives me a green light, but when I look at the default build it has only built the binaries from the bin directory, and there seems to be no easy way to deploy the app on-premise to a local server.
There are two deploy options for a filesystem copy, and a powershell script, and it would certainly be easy enough to use them to copy files to a new server, but since the build only built the binaries, I don't see a tool to gather up the Web artifacts (cshtml, images, scripts, css, etc..) for this.
After an exhaustive google search, I've only found one article which talks about this at:
http://www.deliveron.com/blog/building-websites-team-foundation-build-2015/
However, this uses WebDeploy and creates a rather messy deploy package.
How can I deploy the site (standard MVC web application, in fact my tests are using the default boilerplate site created by the create project wizard) complete with artifacts to a local server in the easiest possible way? I don't want to have to install WebDeploy on the servers, and would rather use PowerShell or something to deploy the final artifacts.
The build is just the standard Visual Studio build template, with 4 steps (Build, Test, Index & Publish, Publish Build Artifacts).
We use "Visual Studio Build" step and as Arguments for MSBuild we use following line:
/p:DeployOnBuild=True /p:PublishProfile=$(DeploymentConfiguration)
On Variables tab page DeploymentConfiguration has to be configured. It must be the Name of the publish Profile (filename of the pubxml file). If the file Name is Build.pubxml the publish profile is Build.
for example:
/p:DeployOnBuild=True /p:PublishProfile=Build
I wanted to add that Ben Day has an excellent write-up that helped us package quickly and then release to multiple environments through Release Manager.
His msbuild arguments look like this:
/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\for-deploy\website
The difference between this and the accepted answer is that this parameter set stages everything in an artifacts folder, and then saves it as part of the build. We can then deploy exactly the same code repeatedly.
We capture the web.env.config files alongside the for-deploy folder and then use xdt transforms in the release process to ensure everything gets updated for whichever environment we're deploying to. It works well for all our web projects.
We use WebDeploy/MSDeploy for 40+ applications and love it. We do install WebDeploy on all our servers so we can deploy more easily but you could also use the Web Deploy On Demand feature which doesn't require WebDeploy be pre-installed.
I have a TFS 2013 build definition that recently started to act strange. Its been doing its job for over a year now without any problems.
It builds 4 different projects. Two of them are asp.net mvc/webapi projects which also are deployed via msdeploy to two separate websites on the same QA staging web server. The build is configured to use Release|Any CPU
When the build runs the dll version is set using the ApplyVersionToAssemblys powershell script.
In the build folder all the assemblies have the correct version. But in one of the deployed web sites one of the dll files "WebUI.dll" has version number 1.0.0.0 ie not the same as the same dll in build directory has which is 4.0.buildnumber
The deployed "WebUI.dll" also seems to be built in Debug mode becuase some buttons and actions are only displayed when DEBUG is defined.
If I copy the built WebUI.dll from build directory or even the PublishedWebsites directory everything works as expected.
So my question is how can MSDeploy via MSBuild create its "own" version of the WebUI.dll? (And no - the Define DEBUG constant checkbox is not checked in Release mode). The version 1.0.0 WebUI.dll cant be found anywhere on the server so I guess it must be "created" when msdeploy runs?
(The only change I've made recently is to add a new build definition which builds the same solution and runs all tests but does not deploy anything.)
UPDATE: I tried to publish from VS using the same publish profile used by the build process and that works as expected. The WebUI.dll deployed is built in release mode. The version is not applied becuase that is part of the build process but the important thing is that its the Release mode dll that is deployed and not Debug which is the case when the buildprocess does the deploy. I also tried creating a web deploy package and installed that on the local server with the same result.
So the problem is still that the WebUI.dll built in the build process is correct (Release mode and correct versioning) - but gets "replaced" during the deploy on the build server by a Debug mode and without versoning
UPDATE 2; Msbuild cmd
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo /noconsolelogger "C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.sln" /nr:False /fl /flp:"logfile=C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:PublishProfile=Chicago /p:AllowUntrustedCertificate=true /p:Password=bw /m /p:OutDir="C:\Builds\2\Products\SomeApp4.Main\bin\SomeApp4.Web\\" /p:Configuration="Release" /p:Platform="Any CPU" /p:VCBuildOverride="C:\Builds\2\Products\SomeApp4.Main\src\SomeApp4\Main\Source\SomeApp4.Web.sln.Any CPU.Release.vsprops" /dl:WorkflowCentralLogger,"C:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/740;IgnoreDuplicateProjects=False;InformationNodeId=14;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;LogProjectNodes=True;LogWarnings=True;TFSUrl=http://boston.SomeCompany.local:8080/tfs/SomeCompany;"*WorkflowForwardingLogger,"C:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;" /p:BuildId="abd7db3d-4ff8-43b4-ab36-f35c6f6e5697,vstfs:///Build/Build/740" /p:BuildLabel="SomeApp4.Main_4.0.6.740_20160121_103558" /p:BuildTimestamp="Thu, 21 Jan 2016 09:35:59 GMT" /p:BuildSourceVersion="LSomeApp4.Main_4.0.6.740_20160121_103558#$/Products" /p:BuildDefinition="SomeApp4.Main"
When you change the assembly version, the version under source control won't be changed. You can only change the version which has been copied on your build agent machine. If the source of the msdeploy command point to the project in TFS, you won't get the versioned assembly.
I found the problem.
The build definition builds 4 solutions where one is the WebUI(aspnet mvc) solution and one is an Api solution (asp.net WebApi)
In the Api solution a project was referencing the WebUI project but the WebUI project wasnt in the Api solution.
MSbuild resolved the WebUI project anyways so there were no errors and build + deploy of the api solution worked. But the WebUI project was built in debug mode since it has no solution configuration in Api solution I guess
The problem when msbuild ran the api solution with deploy flag it also managed to deploy the WebUI project built in debug.
So the WebUI project was deployed twice. First the correct one from the WebUI solution and then the wrong debug WebUI compiled with the Api solution.
Doh! Is all I have to say about that.
Thanks for your help guys.