I have a library that I can successfully build locally and on another computer. However, when I try to do the build at VSTS online, I get
classes.csproj(152,5): Error : This project references NuGet
package(s) that are missing on this computer. Use NuGet Package
Restore to download them. For more information, see
http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is
....\classes\packages\NuProj.0.11.30\build\NuProj.props
I have tried multiple times to check the git repository but comparison shows that the VSTS version is the same.
What am I missing? Do I need to delete this VSTS project and simply reload? Hoping not.
From the command line, you need to do a manual nuget restore before building your project. Visual studio can take care of this automatically. But from the command line, msbuild is not running visual studio.
Thus do something like
nuget restore c:\my\path\to\my\project.sln
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 have a Xamarin Android project that I'm building on a TFS build server. The Nuget packages are not restored, and so the build fails with a bunch of "[filename] could not be found" errors.
I believe the problem is that for the Android build, you specify the .csproj file, rather than the .sln. The field is called "Project" on a Xamarin.Android build step. The automatic Nuget package restore only works if you load the solution file. If you directly build the csproj with MSBuild.exe, the Nuget package restore does not happen.
I expect I can create a PowerShell script step that manually calls Nuget, but it seems this should be supported first-class. Any ideas for me?
The recommended way is to add a NuGet Installer build step before the actually build step. More about this package here
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.
One of my projects is using Clarius Transformation nuget package to transform a .tt file during build without having to install VS Modeling SDK on each machine. However, in one of the solutions, it seems that it is not transforming the files and generates many errors.
How can I guarantee that this transformation is done?
UPDATE
I think the problem may be the fact that the nuget packages are not committed to source control. Then visual studio needs to download the package and only after this run the transformation. But this is just a shot in the dark.
I am not sure about your specific case, but it sounds like you have a post/pre-build action related to one of the projects which creates the files in a wrong order. Check if one of the custom build options has such actions and make sure it is in the correct position in the build order.
My guess is that you are using the older MSBuild based package restore which restores the NuGet package too late in the process for the custom MSBuild target in the NuGet package to be run.
The MSBuild based package restore, which is enabled when you right click the solution and select Enable NuGet Package Restore, adds a .nuget/NuGet.targets file to your project. If you use the MSBuild based package restore then the NuGet package is restored by MSBuild during the build. However the Clarius.TransformOnBuild NuGet package will be restored too late for MSBuild to be able to use the custom MSBuild Clarius.TransformOnBuild.targets and run the transforms.
If you do not use the MSBuild based package restore, and rely on the newer automatic package restore which is done by Visual Studio itself, then your text template should work. With the newer automatic package restore Visual Studio restores the packages when you start the build but before MSBuild is started. This means that any custom MSBuild targets are properly loaded by MSBuild and will be available for use. The newer automatic package restore was introduced to solve this problem.
From the NuGet site:
Packages are restored before MSBuild is invoked by Visual Studio. This allows packages that extend MSBuild though targets/props file imports to be restored before MSBuild starts, ensuring a successful build.
Testing this with Visual Studio 2013, with a text template and the Clarius.TransformOnBuild NuGet package installed, the automatic package restore allows the text template to run during the first build. With the MSBuild based package restore the text template is not run the first time but only on the second build after the NuGet packages have been restored.
So your options are:
Stop using the MSBuild based package restore.
Check your NuGet packages into source control.
Thought I would try and get the most out of my visualstudio.com trial membership. I created a solution with a few projects, pushed it to the Microsoft git source control provider, configured a build definition and tried to build it on the project server. However it keeps failing telling me:
The type or namespace name 'Moq' could not be found (are you
missing a using directive or an assembly reference?)
I know this means that the build server can't find the Moq.dll library. I had installed it using NuGet, but configured my .gitignore to keep the packages folder out of source control. I also enabled NuGet package restore for the solution and pushed nuget.exe, nuget.targets, and nuget.config (all 3 of the files in the .nuget folder) along with all of the other project files.
Now I am sure I could get the build to work if I pushed the packages folder too, but I want to keep the nuget packages folder out of source control. So I am wondering, is this possible? The visualstudio.com docs say that the build servers have visual studio 2013 installed, and because of this I assume that nuget package restore would work to download the missing dll's so that they can be resolved by MSBuild. Is this right? Or to use automated CI builds at visualstudio.com, do you need to have your packages under source control?
According to the log file, nuget package restore downloaded the package. What gives?
Project "C:\a\src\MySln.sln" (1) is building
"C:\a\src\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj"
(3) on node 1 (default targets). RestorePackages:
"C:\a\src.nuget\NuGet.exe" install
"C:\a\src\Tests\MySln.ProjA.UnitTests\packages.config" -source ""
-NonInteractive -RequireConsent -solutionDir "C:\a\src\ " Restoring NuGet packages... To prevent NuGet from downloading packages during
build, open the Visual Studio Options dialog, click on the Package
Manager node and uncheck 'Allow NuGet to download missing packages'.
All packages listed in packages.config are already installed.
PrepareForBuild: Creating directory "obj\Debug\".
ResolveAssemblyReferences: Primary reference "Moq". C:\Program Files
(x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1635,5):
warning MSB3245: Could not resolve this reference. Could not locate
the assembly "Moq". Check to make sure the assembly exists on disk. If
this reference is required by your code, you may get compilation
errors.
[C:\a\src\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj]
This line is also in the build log file, below the above:
Considered "..\packages\Moq.4.1.1311.0615\lib\net40\Moq.dll", but it didn't exist.
I had this same error but it was occurring on our build server. I had added Moq via NuGet, checked in the project and everything was fine. I then moved the project into a new folder in TFS and the build server just couldn't seem to find Moq. It was building great locally. I ended up fixing the problem by making sure all of my changes were checked into source control and then deleting my local source code directory. I got latest and my test project realized it needed a new copy of Moq. I blame TFS/ source safe or what ever the Visual Studio integration module is for not adding it to source control at some point in time.
Figured this one out on my own. Turns out I had added the nuget packages before moving the test project into a Tests subfolder. The solution still built on my LM, probably because the dependencies were already copied to bin/Debug. After reinstalling the nuget packages, the solution built on vs.com.