Nuget not installing in Azure DevOps build - build

I'm trying to stop archiving into code source repository anything that comes from a Nuget package. For most, since they only have dlls, it works.
My problem is that I have one Nuget with a Content folder in the nupkg. When building using VS2017, everything gets installed correctly but when doing the same thing using the build server (Azure DevOps Pipeline), I get
Error MSB3030: Could not copy the file "....." because it was not found.
The pipeline agent version is v.2.122.1 according to Capabilities.
NuGet Task logs version 0.2.31 using NuGet 3.3.0.212 with MsBuild 14.0.
I see the nupkg files in the packages folder but the Content folder items don't get copied.
Is there anything special I need to add to my csproj or any additional steps I should add to my build definition?

Is there anything special I need to add to my csproj or any additional steps I should add to my build definition?
You need change your csproj file to link the files from content package instead of add the files into the project. Since you are trying to stop archiving into code source repository anything that comes from a Nuget package, then add a nuget restore task to your build definition.
As test, I create a content package and add a copy event to copy file from the content package:
After installing that package, following content will be add to the project file .csproj and packages.config:
.csproj:
<ItemGroup>
<Content Include="resources\Test.txt" />
<Content Include="resources\Test2.txt" />
</ItemGroup>
Packages.config:
<packages>
<package id="TestContentPackage" version="1.0.0" targetFramework="net461" />
</packages>
Then we change the .csproj file to link the files from content package:
<ItemGroup>
<Content Include="..\Packages\TestContentPackage.1.0.0\content\resources\Test.txt" />
<Content Include="..\Packages\TestContentPackage.1.0.0\content\resources\Test2.txt" />
</ItemGroup>
After change, the files from content package are not added to the project, just link to the project:
To verify the copy command, I add following copy command in the build event:
if not exist $(ProjectDir)TestFolder mkdir $(ProjectDir)TestFolder
xcopy /y "$(SolutionDir)Packages\TestContentPackage.1.0.0\content\resources\Test2.txt" "$(ProjectDir)TestFolder"
All the things work fine on my local.
Then I build this project with Azure devops, you need add the nuget restore task, otherwise, Visual Studio/MSBuild could not find the files from the packages. And it also work fine.
Note: If you want to copy the files from the content folder, you need copy it from the packages folder.
Hope this helps.

Related

Migrating to new VS2017 .csproj format with migrations

I am converting my project files to this new and shiny VS 2017 project format. I start out by replacing the content with this
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>library</OutputType>
<TargetFramework>net472</TargetFramework>
</PropertyGroup>
</Project>
Then I add Assemblies and Nuget packages slowly and it all compiles. But how do handle all my migrations? I have around 400. Do I need to add all these as an embedded resource?
You don't have to do anything.
The migrations are code files so they need to be compiled. According to the documentation here, all code files are included in the compilation by default.
And of course, If you try to add a migration to the project with the new format, you will see that nothing changes in the csproj file.
Well. There is actually something you need to do, to make commands like Update-Database or DbMigrator class work. At least that's what I needed to do for my EF6 project.
<PropertyGroup>
<EmbeddedResourceUseDependentUponConvention>true</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>
and then to make it work you need to upgrade your Entity Framework to version at least 6.3

Nuget "Manage Packages" dialog. Project names are mixed up

I've got a Visual Studio 2017 solution with several C# class library projects. On disk they take this structure:
MyProduct
MyCompany
MyCompany.ModuleA
MyCompany.ModuleB
MyCompany.ModuleC
But when I look at them in the "Manage NuGet Packages for Solution, the checkboxes show up in the dialog inconsistently. ModuleC appears strangely. Like this:
MyCompany.ModuleA
MyCompany.ModuleB
MyProduct\MyCompany\MyCompany.ModuleC
Also, whenever I build Module C, it keeps creating the following 3 files in its output /obj folder
- MyCompany.ModuleC.csproj.nuget.g.props
- MyCompany.ModuleC.csproj.nuget.g.targets
- project.assets.json
Neither of the other two modules does this.
I'm trying to understand the reason for the inconsistency and to fix it if I can. I have tried combing through the text of the .csproj files for these various projects but I can't spot any differences that might make this happen. And the raw text of the .SLN file project entry all look consistent for each of the 3 modules.
How does NuGet decide what name to put in the Manage Packages for Solution dialog?
Why is NuGet creating those temporary files in the output folder for Module C but not Module's A or B?
How does NuGet decide what name to put in the Manage Packages for Solution dialog?
It is depends on the NuGet manager type, packages.config or PackageReference.
If the project use packages.config, project name will be put in the Manage Packages for Solution dialog. If the project use PackageReference, project file name and relative path will be put in it. That because NuGet will update the project file .csproj when we install the nuget package with PackageReference. So, in the the Manage Packages for Solution dialog, it shows the relative path+project file name, like ClassLibrary1\ClassLibrary1.csproj.
Why is NuGet creating those temporary files in the output folder for
Module C but not Module's A or B?
That because NuGet with PackageReference controls the msbuild items that are generated for these files into the obj\projectname.csproj.nuget.g.props, obj\projectname.csproj.nuget.g.targets and project.assets.json file.
You can unload your project, check if the project file MyCompany.ModuleCuse the PackageReference, like:
<ItemGroup>
<PackageReference Include="Newtonsoft.Json">
<Version>11.0.2</Version>
</PackageReference>
</ItemGroup>
For some more details, please check this official blog: NuGet is now fully integrated into MSBuild.

Explicitly set the order of build targets defined in NuGet packages

I have a Visual Studio 2017 project for building an Azure Function App. This project contains (amongst others) two NuGet packages - Microsoft.NET.Sdk.Functions and OctoPack. The packages are referenced in this order by the .csproj file for the Project in question.
The Microsoft.NET.Sdk.Functions package contains the target _GenerateFunctionsPostBuild -
<Target Name="_GenerateFunctionsPostBuild" AfterTargets="Build">...</Target>
The OctoPack package contains the target Octopack -
<Target Name="OctoPack" Condition="$(RunOctoPack)">...</Target>
When building, it's essential that the _GenerateFunctionsPostBuild target runs before the OctoPack target, otherwise required files are not available in the NuGet package generated by OctoPack.
As I can't edit the NuGet packages directly, I'm unable to explicitly state AfterTarget="_GenerateFunctionsPostBuild" for the OctoPack target. Is there any way I can force the targets to run in the order that I require?
In lieu of a answer, I've come up with a workaround. Instead of using OctoPack, I'm manually generating the NuGet package after the build has completed.
In the NuSpec file, I've added a couple of tokens for %Configuration% and %Version% so that I can choose the files to package based on the configuration, and obviously customise the version.
Here's what I'm doing - obviously I'm making $version before these lines.
$dir = (Get-Location).Path
& D:\nuget\4.4.1\nuget.exe pack $dir\AzureFunction\AzureFunction.nuspec -BasePath $dir\AzureFunction -Properties "Configuration=Release;Version=$version"

Nuget Package Installs Via Console But No Reference Added For C++ Project

I am trying to install the NuGet package detailed on this webpage: https://learn.microsoft.com/en-us/azure/storage/storage-c-plus-plus-how-to-use-blobs
For reference, the instructions are:
Windows: In Visual Studio, click Tools > NuGet Package Manager > Package Manager Console. Type the following command into the NuGet Package Manager console and press ENTER.
This works... kind of. The package is downloaded locally, but the reference isn't being added to my project. When I install the package manually or from the PM Console, no reference is added.
Instructions I've been able to find (such as here) just insist that the references will be automagically added. Which is great when it works, but it provides no debug reference point or how to add them manually.
Are there other options I'm missing?
Thanks.
the reference isn't being added to my project. When I install the package manually or from the PM Console, no reference is added
That is because NuGet cannot directly add references to native projects, the ‘native’ target framework is not recognized within the \lib folder.
For the detail information, you can refer to the Support for Native Projects.
Besides, after installed the wastorage package, you will notice that the blob.h and storage_account.h were added to External Dependencies:
Then you can add the following include statements to the top of the C++ file successfully where you want to use the Azure storage APIs to access blobs:
#include <was/storage_account.h>
#include <was/blob.h>
Update:
According to the JuniorIncanter comment, add the .targets, and .props file in the .vcxproj:
<ImportGroup Label="ExtensionTargets">
<Import Project="..\packages\cpprestsdk.v120.windesktop.msvcstl.dyn.rt-dyn.2.9.1\build\native\cpprestsdk.v120.windesktop.msvcstl.dyn.rt-dyn.targets" Condition="Exists('..\packages\cpprestsdk.v120.windesktop.msvcstl.dyn.rt-dyn.2.9.1\build\native\cpprestsdk.v120.windesktop.msvcstl.dyn.rt-dyn.targets')" />
<Import Project="..\packages\cpprestsdk.v140.windesktop.msvcstl.dyn.rt-dyn.2.9.1\build\native\cpprestsdk.v140.windesktop.msvcstl.dyn.rt-dyn.targets" Condition="Exists('..\packages\cpprestsdk.v140.windesktop.msvcstl.dyn.rt-dyn.2.9.1\build\native\cpprestsdk.v140.windesktop.msvcstl.dyn.rt-dyn.targets')" />
<Import Project="..\packages\wastorage.v120.3.0.0\build\native\wastorage.v120.targets" Condition="Exists('..\packages\wastorage.v120.3.0.0\build\native\wastorage.v120.targets')" />
<Import Project="..\packages\wastorage.v140.3.0.0\build\native\wastorage.v140.targets" Condition="Exists('..\packages\wastorage.v140.3.0.0\build\native\wastorage.v140.targets')" />
For those that stumble onto the question, there is no working solution. The issue arose because I was creating a UAP app, and the given Nuget package does not have UAP support. At that point, in order to continue I must download the source code for the Nuget package and recompile it with the -ZW flag.
See here: https://msdn.microsoft.com/en-us/library/mt186162.aspx
If you have source code for the DLL or static library, you can recompile with /ZW as a UWP project.

DeploymentProvider in manifest of ClickOnce depends on <Import Project=.. in project file

When I publish my project in VS2010 for ClickOnce a strange value for <deploymentProvider codebase="file://oldserver/.../....application" /> was present in my manifest file. The name oldserver name was wrong, it had to be replaced.
I didn't have a clue where the name oldserver came from?
In the project file I had
<InstallUrl>\\newserver\...\</InstallUrl>
but when opened, in the project properties in VS2010 oldserver was again displayed as publish folder location.
SOLUTION: In a hidden file called buildconfig.targets this was configured.
This file was referenced in the .proj file:
<Import Project="buildconfig.targets" />
In this file you need
<UpdateUrl>\\newserver\...\</UpdateUrl>
as well!
If you're publishing from Visual Studio, make sure you set the Install Url.
It's in the publish settings (in project settings for the project you are publishing) underneath the install url.
If you're publishing from MSBuild, then you need to set the UpdateUrl property (/p:UpdateUrl=youraddress for example).
When looking at your project in Visual Studio. select Build and then Configuration Manager. Check the information in your build configurations for Debug and Release and make sure they are correct. This is a total guess, but I could see something being set up in there.