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.
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 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.
I'm setting up a new build server using TFS 2015 and after I configured the agent, when I tried to queue a build I got this error:
No agent could be found with the following capabilities: msbuild, visualstudio, vstest
How can this be resolved?
Install Visual Studio on your build agent, then restart the build agent. Restarting the build agent will capture the added Capabilities.
Note: First of all, you can do all this with the community edition and TFS Express 2015 on your own server (for free up to five users) - so don't worry about needing to use the Visual Studio online version or paying for Visual Studio Professional.
It is very easy to misinterpret the error message provided and go off on a wild-goose chase trying to debug it.
Unfortunately the message itself is just badly worded and that's the real problem.
Here is what that error message really means:
"No agent could be found with the following capabilities: msbuild,
visualstudio, vstest.
In fact I didn't actually find ANY build agents configured for the selected build queue."
So you're thinking that doesn't apply to you because you just created a build agent?
Well, maybe you did, but here's what probably happened:
You created a new pool (for no reason other than you just thought you ought to).
You then created a queue under that pool.
You ran the PowerShell script to create an agent and you assumed it put it in the pool you just created....
But it didn't - it put it in the 'default' pool which you aren't even using...
Aha!
So here's what happens when you build:
You select a queue from the dropdown.
TFS tries to build by looking for the pool that corresponds to that queue and it doesn't find any agents AT ALL there, so you get a stupid useless red-herring error message.
When I finally realized what happened I just deleted my cutely named pool + queue and just reverted to using the default pool.
Next time I will try to pay more attention to this message during the PowerShell configuration:
Configure this agent against which agent pool? (default pool name is
'default')
You will have to create a queue under the pool, but then your agent should start working.
If you have a genuine with a certain capability being absent from your agent you can check what your agent supports via the 'capabilities' tab shown here. Of course msbuild, visualstudio and vstest are all here :-)
In my case, after installing MSBuild (https://www.visualstudio.com/downloads/, search for "Build Tools for Visual Studio 2017"), I just had to add the path to MSBuild to the PATH environment variable. The agent wasn't detecting MSBuild until I did that.
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin
I did NOT have to install the full Visual Studio IDE. The selected answer for this question is just plain wrong...
By default, when using the new build system on VSO, it doesn't pick the hosted build option, which is how I ended up on this post in Stack Overflow. If you are used to using a VSO build server here's what you need to do:
Create a hosted build by going to the General tab and changing your Default Queue to hosted. More on the restrictions of that and how it works here: https://www.visualstudio.com/get-started/build/hosted-agent-pool
Add them as User-defined capabilities, e.g.:
visualstudio C:\Program Files\Microsoft Visual Studio\2022\Community
vstest C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow
I had initially installed the agent on a machine that did not have Visual Studio installed. However, after installing Visual Studio (and then Visual Studio Build Tools), restarting/recreating my agent, restarting my machine, etc., I could not get the agent to detect the new capabilities automatically, so I added them myself in Azure DevOps as User-defined capabilities.
I had this issue and it turned out being my release process had selected the "wrong" agent. Just edit the release and set the correct agent queue
I was using a Xcode build slave for building an Xcode project.
And the error message I ended up with in TFS 2015 was
"No agent could be found with the following capabilities: xcode"
I registered an OS X on-premise build slave.
In the "Register Agent" step, I named by build agent:
>> Register Agent:
Enter agent pool (press enter for default) > My-Xcode-Agent-Pool
So, I had to select the "My-Xcode-Agent-Pool" as Default queue in the build settings. Source: Microsoft-hosted agents
Although none of previous answers worked for me, the post by Simon_Weaver pointed me in the right direction.
He mentioned that vstest was in his list, but it wasn't in mine. I fixed it by adding a user-defined capability named "vstest" with the full path to vstest.console.exe under Visual Studio 2017.
What ended up working for me was to go to where I downloaded the agent and running:
./config.cmd remove then ./config.cmd to reinstall the agent from the command line inside the directory of my agent.
Download agent
per microsoft https://msdn.microsoft.com/en-us/ie/bb399135(v=vs.94)
You must install on the build agent the version of Visual Studio that your team uses on its dev machines. See Installing Visual Studio. You must also install any other software and components that are installed on your dev machines and that are required to build your app.
In my case, after installing MSBuild, restart all Azure services (in windows service) and it worked. No need to install full Visual Studio
You have to install the correspondent Visual Studio version on the build machine (where you have installed your agent). This will add the required tools and capabilities to the server.
Visual Studio is required, because it installs all the build targets required to build your projects.
After being installed, you have to restart the agent Windows service so that it refreshes the list of capabilities.
Since you are using the Visual Studio installation on the build machine to build, that installation doesn't count as an additional license.
General solution for TFS:
The common way of resolving most of the issues on the build server is to install Visual Studio & all dependent packages on your build server.
Alternative solution in case of using VSTS
When you choose where to build, use "Hosted"
and then the build will work.
The guide how to make it work may be found here: Deploy an agent on Windows for TFS 2015
Check the agent section which will contain information about capabilities.
Updated:
Once you have the list of capabilities in vsts(azuredevops)
you might need to install the desired software on your build agent machine.
PS Be aware, you might have to license your sw, if required.
I've been reading and experimenting for days. I bought the latest "Inside the Microsoft Build Engine - Using MSBUild and Team Foundation Build". I've been trying to figure things out by looking at the build targets.
I was quickly able to get a package to be built on the build server, but I want to be able to specify the installation folder, so it doesn't go into wwwroot. I read that I would have to switch the project over from using cassini to the local IIS server. Went through all of that.
The args I'm passing to msbuild through the definition:
/p:DeployOnBuild=true /p:DeployTarget=Package /p:MSDeployPublishMethod=InProc /p:CreatePackageOnPublish=True /p:MsDeployServiceUrl=localhost
I've got SO MANY questions, but I'll start simply. If anyone can provide guidance I'd be super thankful.
If the named application doesn't exist on the build server (which it shouldn't!) the package creation fails. If I add a shell app named accordingly the package is built.
Even if I hack my way past #1 when I try to deploy using Web.deploy.cmd, it fails:
Error: Using a 64-bit source and a 32-bit destination with provider appHostConfig is not supported.
Note that the build server is 64-bit and THIS target server (development) is 32-bit. I have the build configuration building against "any cpu". Oh, and I'm invoking the deployment FROM the 32-bit machine, so there's only the 32-bit msdeploy.exe available.
In the appropriate BuildDefinition under "Process", expand the "Advanced" section and set the value of "MSBuild Arguments" to "/p:DeployOnBuild=True".
That will make your WebDeploy Package built according to your settings in the project properties.
I write 2 articles about how to create Web Package and auto deploy it to a Web Server, I think it maybe useful for you.
Auto Deploy your Website for QA with Team Build click here
How to run remote deploy with MS Deploy? click here