I am trying to build a .NET 4.6 project using MSBuild 15 on our build server (using CruiseControl).
The project has a NuGet package reference (to Oracle.ManagedDataAccess) and it gets restored correctly.
However, the build task fails with the error "The type or namespace name 'Oracle' could not be found".
I have tried building the project in VS 2017 on the build server using the same account, and it works.
I expected MSBuild to retrieve the package contents from the same location, but apparently it can't. What could be the reason?
The error seems to have been caused because MSBuild 14 was used in the build task instead of MSBuild 15. Not sure exactly why that made it fail, but it works now.
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
Our .net core 2.1 solution compiles fine on our local development machines with .net core sdk 2.1.301. Appveyor used to compile the solution in its CI pipeline when there was no database projects defined. Once such a project added, Appveyor started failing in building the solution with the error message below. Any clues how to address this issue?
C:\projects\comingsoon\ComsingSoonDatabase\ComsingSoonDatabase.sqlproj(57,3):
error MSB4019: The imported project "C:\Program
Files\dotnet\sdk\2.1.300\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
The database project can only be built using the full framework MSBuild tools included in visual studio.
Depending on how you set up appveyor, you need to change your definition to use msbuild.exe instead of dotnet commands.
My infrastructure now has TFS 2015, but we started a new project in .NET Standard. Our build server now has VS2017, and the project builds when loaded within VS2017 in that server.
When we set a new build definition to run the build through the build agent, then it fails. Seems even that System is not found:
Error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?)
Is there any simple thing to do to make it work, ir we will have to migrate to the new build steps to make it work? Some workaround?
I find a workaround for that. Simply I gave up of using the TFS 2015 build steps MSBUILD and Visual Studio Build, and now I am using the Command Line step. Calling the commands from there:
dotnet restore
dotnet build
That does the trick.
This is because we need to do our restore a different way using the .net core restore. You could fix this by adding the .NET Core (PREVIEW) task to the build definition or just use command line task. With command line task could running dotnet restore, dotnet build, dotnet publish, and dotnet test.
More details please take a look at this blog: Setting up .net core continuous integration build with VSTS/TFS
For command line solution please refer vsts-agent Build Definition for .NET Core (with Test Results) Also take a look at this similar question: Visual studio team services build .net core 1.1
I've got a couple of ASP.NET vNext applications and I want my CI server to also be able to build them. Both my local machine and the CI server are running VS2015 RC. Then we've got VS Online and a local build controller - which is the server mentioned.
However, I cannot get builds going since it seems to be looking for v12 tooling - which does not include anything DNX.
So - building the solution gives:
The Dnx Runtime package needs to be installed. See output window for
more details
It is installed - since it came with VS2015 RC, AFAIK. So I thought the build template isn't using v14 tooling. I downloaded the Default Git template v12. And indeed it says:
<this:Process.BuildProcessVersion>12.0</this:Process.BuildProcessVersion>
So I switched that to 14, uploaded template, ran build. Then:
Exception Message: The build controller used for this build does not
support the version of the template file used by the build definition.
The version of the template file is 14.0. The maximum supported
version for this build controller is 12.0.0.0.
So trying to solve this - got me to this forum question that states:
Then, instead of changing the BuildProcessVersion property, you need
to change the involved MSBuild version. Open the build process template, find the Run MSBuild for Project activity, change the ToolPath property to the 2013 version msbuild
So - I checked out the template - there is no ToolPath version. There is a ToolVersion property however - which I'll try setting to 14:
In short, my question is: how can I build ASP.NET vNext apps on my build server, that has VS2015RC installed - but is building using v12 tooling?
UPDATE
Seems that the problem is not as much in using the wrong tooling, but more in finding/using the correct DNX runtime while running under a service account ( which the TFS agent is doing ). I've added an issue for the DNX team: https://github.com/aspnet/dnx/issues/2239 .
use msbuild parameter /p:VisualStudioVersion=14.0 ,which can be added in build definition .
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.