Is there any way to make TFS2017 to use MSBuild 16? Some of my projects which getting updated to the latest NuGet packages can't compile in an older release of MSBuild due to the Fody package. I've installed the VS2019 build tools including MSBuild 16 on the server but the server is still not able to use this version. Even the build agent on the server directly still uses the older MSBuild version.
After a bit of searching, I read in a lot of threads about modifing the build process template but where can I find this?
Making TFS2017 to use MSBuild 16
Just like you said, to use MSBuild 16 with Azure DevOps Server 2017, update the Azure DevOps Server 2017 to 2019 is the cleanest way.
Besides, If you have any concerns about upgrading Azure Devops Server, you can try the following method before you start.
Using MSBuild task instead of Visual Studio build and configure MSBuild to point to my MSBuild 16.0 folder:
Add MSBuild to your build steps
Select the Specify Location option like the image below:
Then add the local path of MSBuild 16.0.
Hope this helps.
Related
We have a number of .NET Framework projects with a "nuget pack MyProject.csproj" command in the post-build step. We have been using VS2010 (:O I know) until now, and it has been happily spitting out nupkg files.
We recently updated our build tools to the 2019 version (running the new version of varsall.bat before calling msbuild), and the "nuget pack" command now fails:
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project has been built.
What I've tried:
Adding a "nuget spec" step before packing
Upgrading the nuget CLI executable to the latest version
Updating from packages.config to PackageReferences
This allows you to use MSBuild -t:pack. However, two issues:
When running this in the post-build step on my machine, it starts dozens of cmd & MSBuild processes and pegs my CPU.
Our developers are stuck on VS2017 for now, but the 2017 build tools are no longer available for our build server (so we use 2019). The 2017 & 2019 installs put MSBuild in different locations. We could set path variables for all the machines, but that seems brittle.
I'm playing with upgrading one of the projects to the new csproj format, but it is rather involved. Upgrading all of our projects will be an effort all its own, and I'm still exploring the ramifications.
Is there something simple I'm missing which will allow this to work without large modifications?
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project
has been built.
This message indicates that the nuget.exe can't find the output assembly. So you must make sure the assembly is created successfully.
And one point you need to take care, normally we use command like nuget pack foo.csproj -Properties Configuration=Release to pack the assembly built in release mode. If you use command like nuget pack xx.csproj in post-build-event, no matter which configuration you use msbuild to build the project, nuget will always try to find the assembly in ProjectDir/bin/debug.
So when you deploy the project to remote server without bin and obj folders, if you try to use command like msbuild xx.csproj /p:Configuration=Release, the build is in release mode while nuget.exe will search the bin\debug instead of expected bin\release. You should check if you're in same situation.
Why does NuGet pack break with VS2019 build tools?
This issue is not about the build tools package. Since the error message you got came from nuget. Msbuild just help call the nuget.exe, and the cause of the issue is nuget.exe can't find the needed assembly by one specific path. Please check if the path in the error message is right, and then check if the assembly is in that path.
I also ran into the same issue during our TFS upgrade to Azure Devops. The new Nuget task doesn't have the switch for -Build. The fields in the Nuget task screen for Pack also doesn't allow you to add this switch, that's why it's complaining about not finding the dll or the output of the build. I modified the nugetpack.js file on the agent's task folder to test the theory and now the pack options build successfully.
This is the line I added to the js file (towards the bottom of the page):
nugetTool.arg("-Build");
what would be nice is to have this option represented as check box to cover if there is use case to call Nuget pack without -Build switch
I am trying to setup a CI build using Visual Studio Online but I am getting the following error about the NuGet client:
The 'System.Net.Http 4.0.0' package requires NuGet client version '3.0' or above, but the current NuGet version is '2.8.60318.667'.
Solution builds and deploys fine directly from my Visual Studio 2015 itself but I am unable to get it to build in VSO. Does anyone if NuGet 3.x is installed on hosted build controllers or if I can supply my own copy along with my solution?
It's hard to guess by the question what build tasks are used. If you use VSBuild/MSBuild, it is only possible to turn "Restore NuGet packages" on, but there's no influence on the NuGet version.
However, if you turn this checkbox off, and instead add another build task called NuGet Installer before the main build step, you'll be able to provide a custom path to NuGet.exe. In the case of hosted build agent, the most obvious option is to commit required version of NuGet.exe to the repo, and then reference it from the build step:
Sounds like a hack, but it might work in your case.
I followed the instructions on the "SonarQube Setup Guide for .NET Users" (http://redirect.sonarsource.com/doc/sq-setup-guide-for-dotnet-users.html) to setup a SonarQube 5.1.2 server and integrated with TFS 2012. Even though the document describes how to integrate SonarQube with TFS 2013 XAML builds and TFS 2015 Build vNext, I was able to somewhat integrate it with TFS 2012 XAML build. Here are the sequence of steps in the TFS 2012 XAML.
call InvokeProcess build activity (with WorkingDirecotry set to the directory containing the VS Solution file to be compiled such as C:\Builds\...\ClassLibrary3 to call MSBuild.SonarQube.Runner.exe begin ... (MSBuild SonarQube Runner version 1.0.1)
Call Microsoft MSBuild activity to compile 1 or more VS Solutions such as C:\Builds\...\ClassLibrary3\ClassLibrary3.sln
call InvokeProcess build activity (with WorkingDirecotry set to the directory containing the VS Solution file previously compiled) to call MSBuild.SonarQube.Runner.exe end
The problem is that I can only analyze one compiled VS Solution even if multiple VS Solutions are compiled. This is because the working directory must be the same when calling MSBuild.SonarQube.Runner.exe and MSBuild. The MSBuild activity's working directory is set to where the VS Solution file is located but will differ for each VS Solution compiled but MSBuild.SonarQube.Runner.exe can only specify one working directory. Is there a way to analyze multiple VS Solutions? I don't think there's a way to change MSBuild activity's working directory is there? Thx.
The best way to proceed is be have one project in SonarQube for each of your solution, and use the Portfolio Management plugin (commercial) to perform the aggregation of all these projects on the server side to offer the big picture. See http://www.sonarsource.com/products/plugins/governance/portfolio-management/ & on Nemo how it integrates all Apache projects for example: http://nemo.sonarqube.org/dashboard/index?id=Apache
Another way would be to craft a *.proj file that will include all other projects to build.
Another way, which I wouldn't recommend, is to invoke MSBuild.SonarQube.Runner begin for every solution that you build, then movie the contents of every .sonarqube\out folders to a single one (aggregate it), and call MSBuild.SonarQube.Runner end from that location.
Another way would be to upgrade to TFS 2015, and check how its MSBuild task behaves.
I have a Build server which has TFS 2010 Build Service installed. I have 2 Build Agents and 1 Controllers configured. One of our projects have been converted to Visual Studio 2012.
I found out that .NET framework 4.5 comes with new version of MSBuild which is version 4.5.
I installed .NET framework 4.5 on the Build Server because prior to installing it every time the project was built I kept getting the following error:
"Solution is of version '12.00' which is not currently supported".
After installing .NET 4.5, I still run into the same issue.
How could I go about resolving this?
Do I have to configure the Build Agent to use the new MSBuild 4.5 in order to build this particular project or do I set something in the projects solution file itself? If so how?
I would really appreciate if somebody could assist me with this please?
Try install vs2012 on the build server, while i don't believe it's strictly needed it's the easiest way to get all the requirements installed.
We have installed VS2012 on the build agent. Interestingly when I RDC to the build agent and then run msbuild from the command line everything works fine. So the issue looks like it happens before we even get to MSBuild.
I am using TFS2010 and MSBuild to integrate a windows azure cloud solution to the CI.
To create the required 2 files for deployment I added in the "MSBuild Arguments" the /t:Publish
Here is the configuration I use in TFS to build the packages:
Problem is : if I remove all arguments the tests are built correctly but no azure package is built as seen on the build results:
Tho if I put the parameters the package is there but the test are not run :
Is there a way to have both ?
I have managed to resolve this issue in my tfs build (TFS 2013). I am setting my MSBuild Argument target as /t:Publish;Build
Basically, during Publish target the unit test project is not being built. The 'Build' target builds the unit test project and my tests are executed. I also noted that the sequence of 'Publish' and then 'Build' was important. Setting 'Build' target before 'Publish' raised a few errors for my build.
I had discussion about your problem with TFS Team and I was told that as of now with TFS2010 this functionality is not yet fully supported however such functionality is in they radar and could be part of future TFS releases.
Because you are using TFS 2010, here are a few pointers that could help:
Building and Deploying Windows Azure Projects using MSBuild and TFS 2010
How-To: Deploy to Windows Azure from TFS Build using DeployToAzure
This problem still exists in TFS 2013.
I work around it by creating a Makefile project in the solution, and add a new 'Makefile' file with content as
all:
msbuild $(SolutionDir)AzureProject\AzureProject.ccproj /p:TargetProfile=Cloud /t:Publish /p:Configuration=$(Configuration) /p:PublishDir=$(OutDir)
And set build command line in project property page
nmake /E SolutionDir=$(SolutionDir) /E Configuration=$(Configuration) /E OutDir=$(OutDir)