NuGet Package Restore does not fetch Build Target Assemblies (Tools) - msbuild

I added Fody ProperyChanged to two projects in my solution. Package Restore is enabled on the solution. However, the TFS Build Service fails building with the following error:
WindowsUI.csproj (443): The imported project
"SolutionDir\Tools\Fody\Fody.targets" was not found. Confirm that the
path in the declaration is correct, and that the file exists
on disk.
The folder is indeed not there. I could check it into source control, obviously. However, should it not be populated by the NuGet Package Restore? Or am I misunderstanding what NuGet Package Restore does?

I ran into a similar problem trying to get a solution to build on Visual Studio Online.
Problem is that packages are restored before a project build, but before that the project
files and target inclusions from packages (still to be restored) have already been interpreted.
Use the before build hook as described here:
http://sedodream.com/2010/10/22/MSBuildExtendingTheSolutionBuild.aspx
In your before.solutionname.sln.targets file put something like this to force all packages to be restored before even the first project is built:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="BeforeBuild" BeforeTargets="Build">
<Message Text="Restoring all nuget packages before build" Importance="high">
</Message>
<Exec Command=".\.nuget\NuGet.exe restore YourSolution.sln" />
</Target>
</Project>
If you have external package sources configure them in your nuget.config file which should
also be in the .nuget folder. For example:
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageSources>
<add key="NuGet official package source" value="https://nuget.org/api/v2/" />
<add key="YourSource" value="http://yoursource.somewhere.net/nuget" />
</packageSources>
<packageRestore>
<!-- Allow NuGet to download missing packages -->
<add key="enabled" value="True" />
<!-- Automatically check for missing packages during build in Visual Studio -->
<add key="automatic" value="True" />
</packageRestore>
</configuration>

As of version 1.13.0.0 (released March 23, 2013) Fody is a 100% nuget deployed tool and as such it will work with package restore.
https://nuget.org/packages/Fody/
This will appear when you install the Fody Nuget
https://github.com/Fody/Fody/blob/master/NuGet/readme.txt

UPDATE: This answer now only applies to versions prior to 1.13.0.0.
The files in SolutionDir\Tools\Fody cannot be deployed through nuget and needs to be checked into source control

You are running into the same issue that I did when I tried to ship a build update in NuGet package. The issue is that NuGet package restore is invoked during the build process. Because of this if NuGet package restore restores a .targets file that is imported, it is restored too late. By the time the file is written to disk the <Import element has already been evaluated and skipped due to the file not being on disk.
The best thing that I have found is to build another project to invoke the package restore for you. In order to smooth this out for my own SlowCheetah NuGet package when the NuGet package is installed I create a packageRestore.proj file in the same director as the .csproj/.vbproj. Then users can build this project file and then the .sln/.csproj/.vbproj. By doing this the NuGet packages are restored and then the build process is kicked off.
If you are interested in using my packageRestore.proj I can re-factor that part of SlowCheetah NuGet package into its own and your NuGet package can depend on that one. Let me know if you are interested in that.

Related

How are we supposed to execute package build targets in the new world where nuget packages are consumed through msbuild PackageReference?

I am developing a suite of UI tests using Selenium. One of the run-time dependencies of this suite is the chromedriver.exe, which we are expected to consume through the Selenium.WebDriver.ChromeDriver NuGet package.
The old world
When this NuGet package is imported the following lines are injected into the csproj file:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>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 {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\Selenium.WebDriver.ChromeDriver.2.44.0\build\Selenium.WebDriver.ChromeDriver.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Selenium.WebDriver.ChromeDriver.2.44.0\build\Selenium.WebDriver.ChromeDriver.targets'))" />
</Target>
<Import Project="..\packages\Selenium.WebDriver.ChromeDriver.2.44.0\build\Selenium.WebDriver.ChromeDriver.targets" Condition="Exists('..\packages\Selenium.WebDriver.ChromeDriver.2.44.0\build\Selenium.WebDriver.ChromeDriver.targets')" />
And it is automatic by the Visual Studio. This covers our bases, making sure the build targets provided by the Selenium.WebDriver.ChromeDriver package are there at the time of the build and running them as needed. The logic inside the build targets file copies/publishes the chromedriver.exe to the right location.
All is green.
The new world.
I consume the same NuGet package as PackageReference in the csproj file. Cool. However, the build targets of that package are no longer executed. See https://github.com/NuGet/Home/issues/4013. Apparently, this is by design.
I could import the targets manually, but the problem is that I will have to hard code the location where the package is restored. It is no longer restored in the packages directory in the solution, but under my windows profile. But there is no property pointing to this location and hard coding it sucks.
So, here is the version that works for me and I hate it:
<PropertyGroup>
<MyPackagesPath>$(UserProfile)\.nuget\packages\</MyPackagesPath>
<SeleniumWebDriverChromeDriverTargets>$(MyPackagesPath)selenium.webdriver.chromedriver\2.44.0\build\Selenium.WebDriver.ChromeDriver.targets</SeleniumWebDriverChromeDriverTargets>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Selenium.WebDriver.ChromeDriver" Version="2.44.0" />
</ItemGroup>
<Target Name="EnsureChromeDriver" AfterTargets="PrepareForRun">
<Error Text="chrome driver is missing!" Condition="!Exists('$(OutDir)chromedriver.exe')" />
</Target>
<Import Project="$(SeleniumWebDriverChromeDriverTargets)" Condition="Exists('$(SeleniumWebDriverChromeDriverTargets)') And '$(ExcludeRestorePackageImports)' == 'true'" />
Overall, the Sdk style projects are absolutely great, but this whole business of running targets from the packages is totally broken, even if it is by design.
What am I missing?
EDIT 1
So, here is the content of the generated obj\UITests.csproj.nuget.g.targets:
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
</PropertyGroup>
<ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Import Project="$(NuGetPackageRoot)selenium.webdriver.chromedriver\2.44.0\build\Selenium.WebDriver.ChromeDriver.targets" Condition="Exists('$(NuGetPackageRoot)selenium.webdriver.chromedriver\2.44.0\build\Selenium.WebDriver.ChromeDriver.targets')" />
</ImportGroup>
</Project>
Notice the ImportGroup condition is '$(ExcludeRestorePackageImports)' != 'true'. Now, this condition is always false, because ExcludeRestorePackageImports seems to be hard coded to be true in
c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets
Inspecting binary log confirms this. Plus https://github.com/NuGet/Home/issues/4013 was closed as WontFix.
Or am I still missing something?
If you are running Restore and other targets during the build, you may get unexpected results due to NuGet modifying xml files on disk or because MSBuild files imported by NuGet packages aren't imported correctly.

MSBuild not restoring NuGet packages

I have a solution consisting of multiple projects, several of which reference NuGet packages. There's a web site but also a service which has to be built for x86 or x64; the service is what I'm currently trying to build.
We're on TFS 2013; for this particular solution, I'm using Visual Studio 2015.
"Allow NuGet to download missing packages" and "Automatically check for missing packages during Visual Studio build" are both checked.
I was running NuGet 3.4.4, I've updated to 4.6.2.
I can build fine from Visual Studio. But automated builds on the server fail; but more importantly, it also fails if I try to run MSBuild locally. Similar to this question and this one.
As far as I can tell, the release template is the correct version (12), but I don't think it's a server issue, since I can't build locally either.
The packages are not in source control.
I have a nuget.config in the solution root folder; it previously was in a .nuget folder under the solution root. I do not (and never did) have nuget.exe or nuget.targets in the nuget folder. Here's the config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="NuGetCache" value="\\BuildServer\NuGetPackages" />
<add key="NuGetV2" value="https://www.nuget.org/api/v2/" />
</packageSources>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<solution>
<add key="disableSourceControlIntegration" value="true"/>
</solution>
</configuration>
If I (manually) clear the packages and run
MSBuild /p:Configuration=Release;Platform=x64
(from a VS2015 command prompt), it fails, because it can't find the referenced packages.
As suggested in this answer, I've removed the EnsureNuGetPackageBuildImports targets from my projects; they did not have a RestorePackages tag or an import for nuget.targets.
I tried adding a pre-build event to do the package restore (yes, I realize this is the "old" way of doing things)
"C:\Program Files (x86)\NuGet\nuget.exe" restore -ConfigFile "$(SolutionDir)nuget.config" -PackagesDirectory "$(SolutionDir)packages"
... but it consistently fails ("The command exited with code 1"). If I copy the NuGet command line from the MSBuild output and execute it on its own, it succeeds.
I have noticed one odd thing: in the pre-build event, NuGet says "The folder d:\path\to\solution\project1\bin\Release-x64 does not contain an msbuild solution or packages.config file to restore". I'm not sure why it's looking for those in the output folder.
I do have a workaround for this. We have a network share set up to use as sort of a package cache. If I hand-edit the project files and change each reference so that the HintPath points to \\BuildServer\NuGetPackages\ rather than ..\packages\, the build will succeed. But this is ugly, and more importantly it significantly degrades the performance of Visual Studio.

Treat ProjectReference as PackageReference or allow PackageReference to local csproj

I have a netstandard2.0 csproj (let's call it MyPackage) that is packed at build time (as specified by GeneratePackageOnBuild) into a nuget package. This nuget package has custom props and targets in the build directory (so referencing projects get these imported).
I have another project (let's call it MyConsumer) in the same solution for testing MyPackage. I want MyConsumer to have the build asset props and targets imported from MyPackage at build time, just as if it were consuming it as a PackageReference from some remote nuget source.
How can I get this working (most simply)?
I have been able to do it via a very convoluted method where I have MyConsumer add a PackageReference to MyPackage and override the RestoreSources in MyConsumer to point to the bin directory of MyPackage. This gets very weird when running dotnet build or Visual Studio build of the sln, because project metadata is generated upfront for all projects during Restore and thus MyPackage doesn't exist at that point. The resolution was to add nested calls to MSBuild within the MyConsumer project, but then this becomes even worse, since Visual Studio restores operate quite differently than that automatic restores performed by dotnet build.
Is there any simple way of doing this?
This is what I have now
<Project>
<Target Name="Build">
<Message Text="Running inner build" Importance="high" />
<!--
Need to call MSBuild twice, once to restore, then again to restore and build to get the restore of the Sdk to work
because of this bug in MSBuild: https://github.com/Microsoft/msbuild/issues/2455
Note the trailing Prop=1 is required to get MSBuild to invalid it's cache of the project target imports
-->
<MSBuild Projects="$(MSBuildProjectFullPath)" Targets="Restore" Properties="Configuration=$(Configuration);Version=$(Version);IsInnerBuild=true;Prop=1" />
<!-- Have to use dotnet build instead of another call to MSBuild because of another bug that prevents proper imports within the same physical process -->
<Exec Command="dotnet build /p:Configuration=$(Configuration) /p:Version=$(Version) /p:IsInnerBuild=true" />
<Message Text="Finished inner build" Importance="high" />
</Target>
<Target Name="Restore" />
<Target Name="RemoveBin">
<RemoveDir Directories="bin" />
</Target>
<!-- Don't do real cleans old rebuild since it breaks MSBuild due to the same above bug -->
<Target Name="Rebuild" DependsOnTargets="RemoveBin;Build">
</Target>
</Project>
Treat ProjectReference as PackageReference or allow PackageReference to local csproj
If I understand you correct, you want to generate the package with project MyPackage, then install it to the test project MyConsumer and have the build asset props and targets imported from MyPackage at build time.
To accomplish this goal, you need to complete the following few things:
Make sure the project MyPackage build before the project MyConsumer.
Set the package into the packager source
Add the package MyPackage.nupkg to the test project MyConsumer during the build time.
Details for above:
Make sure the project MyPackage build before the project MyConsumer.
Since you wan to test the package which generated by the project MyConsumer, you should make sure this package grnerate before test project using it, so we need set the project MyConsumer reference the the project MyPackage.
Set the package into the packager source
You can use a post-build event for the project MyPackage to copy the package MyPackage.nupkg to the local feed, or you can just add the bin directory of MyPackage.nupkg to the package source.
Add the package MyPackage.nupkg to the test project MyConsumer during the build time.
Using VS 2017 and the PackageReference style of the test project MyConsumer, you can set a Directory.Build.props file into the root of your solution containing the test project MyConsumer you need:
<Project>
<ItemGroup>
<PackageReference Include="MyPackage" Version="1.0.* />
</ItemGroup>
</Project>
This will add these NuGet packages to the test project MyConsumer in the solution, it will be used as a PackageReference from some remote nuget source.
Check the Martin`s answer for some more details.
Hope this helps.

Can new projects in VS2017 store nuget packages in project packages director?

Through automatic nuget restore is convenient it is not safe. I previously checked in all packages into the repository. This was easy as VS created a packages directory under the project root.
Now I find I have a
~/.nuget
directory outside the project hierarchy. Is there a way to revert the behavior? Perhaps a flag in the *.csproj file?
You can change the location for the global package folder to a solution-local location by specifying a path in a NuGet.Config file next to the solution (note that you have to re-open the solution for this to have an effect):
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="globalPackagesFolder" value=".\packages" />
</config>
</configuration>
There are two properties that can be set this way to affect the location of where the packages will be restored to. repositoryPath for packages.config projects and globalPackagesFolder for project.json and projects usingPackageReference.

Config transformation in WIX setup

I'm creating a MSI setup with WIX for my Web Application. This works correct. The only thing that I don't get to work is to enabling the config transformation of the standard web application publish method.
I understand that you can add the using tag for existing target files. I try'ed to add the TransformXml to the AfterBuild Target in the project file of the WIX installer but that doesn't work.
<TransformXml Source="Web.Config" Transform="Web.$(Configuration).config" Destination="Web.Config" />
Can someone help me?
I created a test project for this called WebApplicationWix
I didn't see any mention of TransformXml in your example project.
You need code similar to this:
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterCompile">
<CallTarget Targets="TransformWebConfiguration" Condition="Exists('web.$(Configuration).config')"/>
</Target>
<Target Name="TransformWebConfiguration">
<!-- Generate transformed web configuration -->
<TransformXml Source="web.config" Destination="web.transformed.config" Transform="web.$(Configuration).config" />
</Target>
A few things to note:
Check the path to Microsoft.Web.Publishing.Tasks.dll in the UsingTask element (change for your version of Visual Studio)
In your example, the source and destination were the same; you should make sure the destination is a different file so that you don't have file lock issues or overwrite the web.config you're trying to transform with the transformed one.
In Visual Studio 2010, there were file locking issues with TransformXml, so be careful of that if you're using 2010.