VisualStudioOnline NuGet Restore now built in? - msbuild

Is the Host Controller on Visual Studio Online now automatically restoring NuGet package before calling MSBuild?
Previously I had to manually execute the following:
nuget.exe restore MySolution.sln
Now, when creating a new build in a new project, I noticed that I didn't need to do this. When looking at the build logs, I see this:

This was a change in TFS 2013 Update 2 and is reflected in VS, TFS, and VSO...

Related

Can I remove NuGet.exe from the Solution folder

I am using Visual Studio 2019 after upgrading from 2015. The problem I am having is when calling MSBuild from the command line, older projects which have a NuGet.exe within the .nuget folder inside the project/solution directory will fail to build because they've got an old version of the exe.
Can I delete the NuGet.exe from .nuget folders, remove references to it in the csproj files, and use one central NuGet.exe from this point on?
Is this the correct thing to do?
Yes, that .nuget\NuGet.targets and .nuget\NuGet.exe thing is from Visual Studio 2013 and earlier. Not only is it causing you problems now, but every build and restore from in Visual Studio 2015 and later has been slower because these projects are using this old "integration". (NuGet is probably restoring in VS, and then when the build happens, the restore via nuget.exe in NuGet.targets is running, doing a second restore check)
The NuGet team have some docs, with instructions in the "Migrate to automatic package restore (Visual Studio)" section: https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore#migrate-to-automatic-package-restore-visual-studio

nuproj.props file is missing

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

Is there an easy way to automatically create a NuGet package from a Visual Studio 2015 project?

Before Visual Studio 2015, it was trivial to setup your project to automatically generate NuGet packages. Specifically, you did:
Add a .nuspec file to your project
Enable NuGet Package Restore in the Solution right-click context menu
Edit the project .csproj file and set the build property <BuildPackage> to true
And that was it!
However, starting from VS 2015, MSBuild-integrated package restore has been removed and replaced by the new Automatic Package Restore. While these are all good news, it seems that setting the build property <BuildPackage> to true no longer triggers an automatic package build.
This is a major break of functionality! Is there a way to setup automatic builds of NuGet without using post-build events? Specifically, I'm looking for an MSBuild solution, as it forms the backbone of my build workflow.
Try OctoPack: https://www.nuget.org/packages/OctoPack/
Just add nuget package to your project.
If you want to build it every time you build release, add
to section <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|Whatever' ">
next line:
<RunOctoPack>true</RunOctoPack>
More information about finetuning can be found here: https://github.com/OctopusDeploy/OctoPack
There is a move to Class Library Packages in VS2015 which makes it incredibly easy to create NuGet packages. I've blogged about this before, but essentially it's just a few steps. Note that this is just a RC1 at the moment and not a stable release yet.
Install the ASP.NET and Web Tools 2015 (RC1 Update 1) update to VS2015.
Open VS2015 and create a new Class Library Package project.
Add your code to the library and configure the project.json file with any changes you may need. A default project.json file is used as an example.
Right-click on the project and select the Properties menu item. In the Build tab select “Produce outputs on build”. Build the project.
You’re done. Go to the artifacts folder in your project, in my case “artifacts\bin\AwesomeSoft.TextConverter\Debug”.
You should see the NuGet package already created, and the folders targeting each framework specified earlier.
There is another alternative called NuPack :
How-to-create-a-nuget-package-on-each-Visual-Studio-with-NuPack
It is a nuget package that automatically generate nuget package on build time.
VS4MAc already supports this and you can get it as a extension for VS on Windows
https://github.com/NuGet/NuGet.Build.Packaging

Visual Studio Online build error about NuGet client version (v3.0 or above required)

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.

Solution must be compiled twice to succeed

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.