I added Property to include Package release note, but I don't see it in Nuget and visual studio Nuget Package manager. Anyone noticed this ?
<PropertyGroup>
<IncludeSymbols>true</IncludeSymbols>
<SymbolPackageFormat>snupkg</SymbolPackageFormat>
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<PackageReleaseNotes>Testing</PackageReleaseNotes>
</PropertyGroup>
If you want to modify the author, description,copyright, you have to use these properties:
<PropertyGroup>
<IncludeSymbols>true</IncludeSymbols>
<SymbolPackageFormat>snupkg</SymbolPackageFormat>
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<PackageReleaseNotes>Testing</PackageReleaseNotes>
<PackageId>testme</PackageId>
<Version>2.0.0</Version>
<Authors>me</Authors>
<Description>mytest</Description>
<Copyright>company</Copyright>
</PropertyGroup>
See this document.
When I upload the nuget package on nuget.org,
And when I finish publishing it, I got it:
Related
I'm trying out the new Central Package Management feature in NuGet.
As stated in the documentation, if you use multiple NuGet sources (which I use), it is now required to configure the Package Source Mapping in a nuget.config file, otherwise you should get a NU1507 warning.
My simplified file tree is this:
MySolution.sln
Proj1.csproj
MyLibrary\ (this is an external repository with all my shared projects)
Directory.Packages.props
nuget.config
Proj2\ (an example library project)
Proj2.csproj
Here is the Proj1.csproj content:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net7.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
<PropertyGroup>
<DefaultItemExcludes>$(DefaultItemExcludes);MyLibrary\**\*</DefaultItemExcludes>
</PropertyGroup>
</Project>
Here is Directory.Packages.props:
<Project>
<PropertyGroup>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
</PropertyGroup>
<ItemGroup>
<PackageVersion Include="JetBrains.Annotations" Version="2022.1.0" />
</ItemGroup>
</Project>
Here is nuget.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear/>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json"/>
<add key="Custom NuGet" value="https://nuget.mydomain.net/"/>
</packageSources>
<packageSourceMapping>
<packageSource key="nuget.org">
<package pattern="*"/>
</packageSource>
<packageSource key="Custom NuGet">
<package pattern="MyNamespace.*"/>
</packageSource>
</packageSourceMapping>
</configuration>
and Proj2.csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net7.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
</Project>
In the official documentation the MyLibrary\nuget.config should be used when restoring the packages because it is in the parent directory of Proj2.csproj, and actually it works when I build the solution via dotnet build, but when I build it in Visual Studio I still get the NU1507 warning.
I know that I could work around the issue by copying the nuget.config file in the same directory as the solution file (the warning goes away), but I have hundreds of projects that include the MyLibrary directory and I'd like to keep all the configuration centralized.
Moreover it works as expected when it's built from the command line, so what am I doing wrong?
Everything seems like correct from your configure file.But MS doc has mentioned this note:Central package management is in active development. You can provide any feedback you may have at Nuget/Home
Here’re suggestions you can have a try to check :
1 check your visual studio version and this feature is available for Visual Studio 2022.17.2 and later.Because older tooling will ignore central package management configurations and features.See more information please refer to doc:CPM
2 If you are unable to onboard to Package Source Mapping but want to use central package management, can suppress the warning. Please refer to doc:
<PropertyGroup>
<NoWarn>$(NoWarn);NU1507</NoWarn>
</PropertyGroup>
3 use dotnet nuget list source to get package source list and check whether they are enabled.
Am unable to resolve nuget error in a new webapi project on one of my laptop, but works good on another. Both have same VS Code, nuget, dotnet core versions and have the same project files
error NU1100: Unable to resolve 'Swashbuckle.AspNetCore (>= 6.2.3)' for 'net6.0'.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Swashbuckle.AspNetCore" Version="6.2.3" />
</ItemGroup>
</Project>
Any thoughts appreciated.
Check if NuGet sources are available via dotnet nuget list source.
Add it, if missing, via:
dotnet nuget add source https://api.nuget.org/v3/index.json -n nuget.org
See https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-add-source
Problem: Top level project references MyLibrary nuget which references several vendor.dll files. Vendor.dll files should be able to be referenced by top level project when MyLibrary nuget package is added to top level project but they are not.
When I run the top level project I receive this error:
FileNotFoundException: Could not load file or assembly 'Vendor.A, Culture=neutral, PublicKeyToken=b88d1754d700e49a'. The system cannot find the file specified.
Vendor .dll files are not copied to bin folder.
I hope to find a resolution to this problem that does not require me to create a .nuspec file.
Structure of generated MyLibrary nuget package (observed with Nuget package explorer):
lib
net5.0-windows
Vendor.a.dll
Vendor.b.dll
net5.0-windows7.0
MyLibrary.dll
I do not understand where net5.0-windows7.0 comes from. It does not exist in TFM list referenced below. Also, if net5.0-windows7.0 is for some reason necessary, why does MyLibrary.dll exist there but not the .dlls it depends on?
Looking at the package from within Visual Studio 2019 it appears as follows (vendor dlls do not appear):
Packages
MyLibrary
Compile Time Assemblies
MyLibrary.dll
MyLibrary.csproj:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
<PropertyGroup>
<AssemblyVersion>1.0.0.1</AssemblyVersion>
<FileVersion>1.0.0.1</FileVersion>
<Version>1.0.0.3</Version>
</PropertyGroup>
<ItemGroup>
<Content Include="$(OutputPath)\Vendor.*.dll">
<Pack>true</Pack>
<PackagePath>lib\$(TargetFramework)</PackagePath>
</Content>
</ItemGroup>
<ItemGroup>
<Reference Include="Vendor.a">
<HintPath>VendorLib\Vendor.a.dll</HintPath>
</Reference>
<Reference Include="Vendor.b">
<HintPath>VendorLib\Vendor.b.dll</HintPath>
</Reference>
</ItemGroup>
TopLevel.csproj
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="MyLibrary" Version="1.0.0.3" />
</ItemGroup>
Target Framework Monikers
Similar question
Similar question requiring nuspec
Similar question requiring nuspec
Possibly related issue
I also found an issue about this strange behavior and still did not know where the net5.0-windows7.0 from. Since the issue is still open and the Team does not know it is normal or a strange issue, as my opinion, net5.0-windows7.0 is the special version for wpf project's frameowork of nuget, so you should pack your dlls into such folder of nupkg.
Although this is not the best function, but is a workaround now. You can keep tracking the issue to get the explanation from the Product Team.
Or try my suggestions:
function one
1) change the targetframwork of your nuget project to
<TargetFramework>net5.0-windows7.0</TargetFramework>
As the Team said, net5.0-windows is the same as net5.0-windows7.0. However, they treat them differently in terms of packaging into nuget.
function two
2) still use <TargetFramework>net5.0-windows</TargetFramework>.
change this to:
<ItemGroup>
<Content Include="$(OutputPath)\Vendor.*.dll">
<Pack>true</Pack>
<PackagePath>lib\$(TargetFramework)7.0</PackagePath>
</Content>
</ItemGroup>
Besides, when you finish packing nuget project, please delete nuget caches first or delete all files under C:\Users\xxx\.nuget\packages, then install the new release version of the nuget package into the main project.
vendor is my custom nuget project name.
In my VS 2017 project I reference docfx.console package and I want it to be used only when certain condition is met. But the package gets used for all builds.
Here is a part of my project. I want docfx.console to be used when configuration is Installer/AnyCPU and VS is building net40 flavor.
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net40;netstandard1.3;netstandard2.0</TargetFrameworks>
<!-- ... -->
<Configurations>Debug;Release;Installer</Configurations>
</PropertyGroup>
<ItemGroup Condition=" '$(TargetFramework)'=='net40' ">
<!-- ... -->
<PackageReference Include="docfx.console" Version="2.30.0" Condition="'$(Configuration)|$(Platform)'=='Installer|AnyCPU'" />
</ItemGroup>
<!-- ... -->
</Project>
Is there a way to use docfx.console in Installer build for net40 only?
To summarize, even with the condition "false", the package will be imported.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp3.0;netcoreapp2.2;net472</TargetFrameworks>
<Platforms>x64;x86</Platforms>
</PropertyGroup>
<ItemGroup Condition="false">
<PackageReference Include="MyPackage" Version="1.0.0" />
</ItemGroup>
</Project>
We found that we can work around this issue by putting the packagereference in a different file, and making the import of the file conditional.
Separate file: packagerefs.targets
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="MyPackage" Version="1.0.0" />
</ItemGroup>
</Project>
Project file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp3.0;netcoreapp2.2;net472</TargetFrameworks>
<Platforms>x64;x86</Platforms>
</PropertyGroup>
<Import Project="packagerefs.targets" Condition="false" />
</Project>
Even i was looking for referencing nuget packages on condition based (load only when expected constant is set in DefineConstants). Though #Luke Schoen Solution worked for me, I could make it work without the external targets file.
Solution is to include your PackageReference using Choose > When
Make sure to have this block after your PropertyGroup which has DefineConstants.
<Choose>
<When Condition="$(DefineConstants.Contains('My_CONST'))">
<ItemGroup>
<PackageReference Include="MyPackage">
<Version>1.0.6</Version>
</PackageReference>
</ItemGroup>
</When> </Choose>
PackageReference condition is ignored
This is an known issue about the new style csproj PackageReference to work with content/Tools files in a nuget package.
In the package docfx.console, it looks like docfx.console has "content", "build" and "tools" without .NET code in it, just random files:
In this case, when we install this nuget package, nuget does not do anything. So it seems gets used for all builds. That because:
NuGet packages that work with Packages.config, don't always work in
transitive NuGet environments (projects using Project.json or
PackageReferences). Packages that work in transitive NuGet
environments must use "contentFiles" instead of "content" -- you can
have both, if a package would like to work in both environments. Also,
install.ps1/uninstall.ps1 doesn't execute in transitive NuGet
environments -- however, init.ps1 will work in both Packages.config
and transitive environments.
At this moment, there is not a perfect solution, so the issue 4837 is still open.
To resolve this issue, the NuGet docfx.console package needs to be changed to use contentFiles and define targets and would typically reference a tool by using $(MSBuildThisFileDirectory)..\tools\MyTool.exe. If you put this PackageName.targets file into the a build directory, it will be automatically included into the project referencing the NuGet package.
Hope this helps.
In my case I had also same kind of problem - but root cause was that some of msbuild properties were not defined when nuget package building was performed - in particular $(SolutionName) was not defined. Condition still gets evaluated, only it's returning true for some reason. (You can test this by putting Condition="false" - it will be omitted).
Solution for me was to check if property is defined, for example like this:
<ItemGroup Condition="'$(SolutionName)' != '' and $(SolutionName.Contains('SolutionCustomTag'))">
<Reference Include="...">
Te first statement '$(SolutionName)' != '' and - tests that property is defined.
In some of my csproj files I have this but some dont:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable 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('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
What exactly is this and why do I need it? My other projects are restoring their packages just fine without it.
I am using VS2013 and NuGet 2.8.
It ensures that the imported .props and .targets files are indeed imported. NuGet has supported NuGet MSBuild support since 2.5. EnsureNuGetPackageBuildImports code was added in September, but I think it is a 2.8 change. Unfortunately, it looks like a non-backward compatible change. We have some developers on 2.7 who will now need to upgrade to 2.8. I found EnsureNuGetPackageBuildImports in Common/MsBuildProjectUtility.cs on line 11.