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.
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 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 it possible to create a nuget package containing a custom build step (analyzing the generated assembly and automatically generating some metadata)? The target environment should be .NET Core with the new .csproj format (Currently using Visual Studio 2017 RC). Best case would be if this only adds a msbuild step and no dependency to the projects resulting assembly.
If seen that it should be possible with full .NET, but the documentation for msbuild and the new .csproj for .NET Core is a bit sparse at the moment.
You can add MSBuild targets to a NuGet package in the "build" folder. The targets or props file name must match the package ID. When installed via "PackageReference" or packages.config, NuGet will automatically import the targets/props file into the csproj, so these files must be written as valid MSBuild code.
i.e. if your package was named "MyClassLibrary", you could have the following layout:
(package root)
lib/
netstandard1.3/
MyClassLibrary.dll
build/
netstandard1.3/
MyClassLibrary.props
MyClassLibrary.targets
For example, see Microsoft.Extensions.Configuration.UserSecrets on NuGet.org or and its source code on GitHub. This package uses an MSBuild target to automatically generate an assembly attribute before the compilation step
Nuget may execute "init.ps1" powershell script during installation if find it in your nuget package. But keep attention, that script support was modified in Nuget 3.x:
In Nuget 3.xx Powershell script support was modified to no longer execute install and uninstall scripts (install.ps1, uninstall.ps1), but init scripts are still executed.
Additionally, running NuGet outside of Visual Studio at the command-line or on other operating systems cannot execute these Powershell scripts as they relied on Visual Studio automation. Powershell is in NuGet to provide a shim to allow for missing features to run inside of Visual Studio
Powershell script support was modified to no longer execute install and uninstall scripts, but init scripts are still executed.
You can find more here in "Powershell Install and Uninstall Scripts".
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
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