I have a large visual studio solution using multiple NUGET packages and multiple projects to build an asp.net web project. When I build locally using VS 2017, the build works correctly. I have an on-premise TFS 2014 server (soon to be retired) and use it to build the solution successfully using my TFS build server. I moved the source code to a VSTS project and defined a locally hosted build pipeline using the same build server that I use for TFS 2014. I have used this same build server with other VSTS project pipelines successfully.
My web project builds all the projects correctly (I can see it in the log and looking on my build server, I can see all the dlls in the c:\Agent_work\n\a directory including packages (from the built projects) or the built projects. The final project to build is the web project. It fails to find the other projects needed to build this final project.
I find this curious since some of the other projects in the solution have dependencies to other projects in the solution and build correctly. I have examined the web project .csproj file and the .sln file, and I see no issues in the references to these dependent projects.
I solved this issue by switching the pipeline step from visual studio build to msbuild.
Related
In my asp.net web application, i have solution with 5 projects and nuget.org. In TFS Build Definition,
1) While building the whole solution in Visual Studio Build Task
Nuget packages getting restored.
2) While trying to generate executable files for individual projects in MS Build Task
If I select Restore Nuget packages, It's not finding nuget packages and step getting failed with message - "Process 'NuGet.exe' exited with code '1'."
I have tried many references online and none worked. Any suggestions on how to solve this?
Do i need to make any changes in the nuget.config file to support restoring
packages to individual projects.
Do not directly select Restore Nuget pacakges in MS build task configuration. This option is deprecated. To restore NuGet packages, add a NuGet Installer step before the build.
(Important) This option is deprecated. Make sure to clear this
checkbox and instead use the NuGet Installer build step.
Source Link: MSBuild
Besides, you could also build single project not the entire solution in Visual Studio Build task. Just select the project (.*proj) files instead of .sln file.
Unless you are building a customized MSBuild project file, then we recommend you use the MSBuild step instead of the Visual Studio Build step.
You could also try to build single project using Visual Studio Build task, see if the issue is still exists.
Same problem, downgraded to 4.4.1. it helped
Packaging a build use Nuget Packager in VSTS and i get the error:
[error]'Newtonsoft.Json' already has a dependency defined for 'NETStandard.Library'.
Most of the hints that solves this involves updating nuget, but since I am building on Team Services I can't really do this.
It seems that the nuget used by nuget packager is not the latest. After testing locally with latest nuget.exe everything worked so I added a new powershell release step. This solution is appropriate for VSTS, for TFS where you have access to the server I recommend upgrading nuget.exe on the server itself:
This script downloads nuget.exe into the artifacts directory (and outputs the path to the nuget.exe so you can see where it is put.).
I then altered the Nuget Packager build step to use the freshly downloaded nuget.exe.
Had the same issue today.
Using your own build agent
If you are using your own build agents (rather than the hosted agent) you can manually update the version of NuGet to the latest version. In my case, this has resolved my problems.
e.g. C:\agent\externals\nuget\nuget.exe
Using the hosted agent
It's a bit messy but you could just upload the latest nuget.exe into the repo and set the NuGet Packager to use this.
To anyone getting this in 2018, Microsoft have created a new version of the NuGet task that fixes this issue. No need for powershell install steps.
Change the NuGet task version in your build step version to 2.*
This caused some breaking changes for me, that I resolved with the following advanced settings
Nuget Restore
Nuget Pack
Nuget push
I have created a asp.net mvc core app targeting the .net framework (not the multi platform core) as I want to include standard .net framework libraries and running cross platform is irrelevant to me as I will be hosting in Azure.
The solution looks like this:
I am trying to get a VSTS build working with this project (which is part of a larger solution) but when building I get the following error:
Which seems to be a common error. What should my build definition look like to build these .csproj based projects? There seems to be a lot of information but no definitive answer. Hopefully that answer can be here and people can stop looking elsewhere for information on how to get a Continuous Integration build going.
On a side note at the solution level I find no packages folder containing my nuget packages, why is this? The project definitely contains nuget packages.
Your project is using the newest MSBuild based project files for .NET Core.
The extension is still .csproj, but the XML schema is different than the ordinary .csproj used in .NET46 (and previous versions).
You need appropriate tooling to build such .csproj file, for example:
Visual Studio 2017: install it on your private build agent; VSTS hosted build agent does not have VS2017 installed yet;
.NET Core SDK 1.0.0-preview4-004233 (or more recent): this SDK contains the command line tool 'dotnet' for MSBuild .NET Core based projects.
Note in your build log that the msbuild used is the one shipped with VS2015 (version 14.0) instead, that does not support such .csproj format file.
On the other hand, if you do not need multiplatform nor any other benefit of .NET Core, why are you using it? Just created an ordinary ASP.NET 4 web project targetting .NET 4.6.
We have SQL CLR dll that we developed quite a long time ago that we have been using. Unfortunately it wasn't ever in our normal daily builds.We are going to be upgrade our sql server from 2008 R2 to 2014. So i opened the project and upgrade it to a visual studio 2013 project (we hadn't opened it for quite some time). I also upgrade the target framework from 3.5 to 4.5.1. Lastly i changed the target sql server version to 2014. I was able to build it locally. I then tried to add it to our TFS build and got the following error:
E:\Builds\8\TRSApps\Dev\Sources\Shared
Objects\Components\FrsSqlCLR\VB Code\FrsSqlCLR.vbproj (76): The
imported project "C:\Program Files
(x86)\MSBuild\12.0\bin\amd64\SqlServer.targets" was not found. Confirm
that the path in the declaration is correct, and that the
file exists on disk.
I was able to resolve the problem. I searched for "SqlServer.targets" locally and found it under the .net 3.5 framework folder (not under 4.x):
C:\Windows\Microsoft.NET\Framework\v3.5
I just copied it to the location it was looking for it above and it fixed the problems which leads me to my questions:
Is TFS looking for SqlServer.targets in the correct location? If so then why isn't SqlServer.targets there?
Is there something i need to install on the build machine?
Why is the file in the 3.5 framework folder and not in the 4.x framework folder
Though i was able to resolve it by copying it from the 3.5 framework folder it seem a kind of hacky solution. I want the details so in the future when we upgrade our tfs server i have all the details.
You need to install Visual Studio 2013 on the build server. Also Sql Server Data Tools for 2013.
Once you have them on the build server it should build as is.
I currently work on a MVC 4.0 project that was upgraded to MVC 5.0 using the official guide.
I use Visual Studio 2012 locally and a publish profile was created for the project.
Locally I call msbuild via the Visual Studio developer command prompt using: msbuild /m /p:Configuration=Dev;DeployOnBuild=true;PublishProfile=Dev my-solution.sln
All projects in the solutions do have a Dev configuration and there is a web.dev.config.
The command line on the server is the same.
So far the difference is that on the server only the visual studio shell is installed (not the full) and we cannot install the full instance of VS2012 on the server.
Also, seeing on the install of TFS on the server, I discovered that only v9.0 target files were installed (Visual Studio 2008). Copying Visual Studio 2012 target files do not fix this problem.
I see 2 solutions so far but searching for a third.
Install full Visual Studio 2012 instance
Update csproj to include a target transformConfigFiles (basically copy and paste the content of the "Microsoft.Web.Publishing.targets" section) or import the file via a declaration inside of the .csproj
Would there be a third solution available?
It is pretty common to install full Visual Studio on your build server. As of VS 2012 you couldn't even run Unit Tests in your build without VS installed.
I'd suggest installing VS and seeing if that fixes the issue.