We Keep Coding

Get Nuget package properties from assembly attributes (in Visual Studio 2022)

I have a C# project in Visual Studio 2022.
In the AssemblyInfo.cs file I have an AssemblyVersion attribute:
using System.Reflection;
[assembly: AssemblyVersion("1.2.3")
I want to generate a NuGet package automatically on build, and I was wondering if it would be possible to specify, in the package properties dialog, to use the AssemblyVersion as package version, to avoid having to remember to change the version in two places each time.
Something like this (which doesn't work):
Is there a way to do this?

The $(AssemblyVersion) value is trying to reference an MSBuild property. It cannot see an [AssemblyVersion] attribute in your code at build time. I recommend you move the specification of the version to your project file (search for "version" in that UI, or edit your .csproj and set the <Version> property manually. In that way you only have to set the value once; the version will be set on the assembly, and used during pack operations.

You can remove the AssemblyInfo and specify the version in your csproj file (see below). dotnet pack then should produce both package and dll with correct version.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
...
<Version>MAJOR.MINOR.PATCH</Version>
<IsPackable>true</IsPackable>
</PropertyGroup>
...
</Project>

Custom Nuget package shows missing dependency error

I have two class libraries in a single solution (.NET Core). One of them (cl1) is a main library and it depends on another library (cl2). I have added a .nuspec file with the required metadata only (no dependencies, no files) for the cl1 project in the project folder (same location of .csproj file) and I have set GeneratePackageOnBuild propery to true.
Whenever I am building the class library (cl1), the .nupkg is created automatically in the debug/release folder.
When I check the generated .nupkg file, I am see two strange things:
The generated .nuspec file is different than what I have added in the project folder
cl2 is mentioned as a dependency in the newely generated .nuspec file, but the DLL for cl2 is not included in the lib folder of the .nupkg. So, whenever I consume this package in another solution, I am getting the error No packages exist with this id in source(s) for the cl2.
I have surfed in internet, but was not able to find a proper solution for the above error.

And I have added a .nuspec file [...] in the project folder(same location of .csproj file)
You have to specify the path to your own NuSpec file in the .csproj using the NuspecFile tag, otherwise it will be ignored and the package will be created with the metadata from the .csproj file instead, see reference. You need to use either a relative or an absolute path to the file, for example:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<NuspecFile>cl1.nuspec</NuspecFile>
</PropertyGroup>
</Project>
The generated .nuspec file is different than what I have added in the project folder
As already stated, your NuSpec file is probably not included. However, even if it is, there can be differences, because some information, e.g. source file locations are unnecessary and the target locations are in most cases given by the internal package file structure itself, so it is not there because it is redundant.
cl2 is mentioned as a dependency in the newely generated .nuspec file, but the dll for the cl2 is not included in the lib folder of the .nupkg. So, whenever I consume this nupkg in other solution, I am getting error " No packages exist with this id in source(s)" for the cl2.
Dependencies are meant for packages. So when NuGet restores the package it searches for other packages that this package depends on, here cl2, but there is none, hence the error. When packing a project, referenced projects are not included in the package. That is an open issue and there are workarounds that you can try.
The most reliable, but inconvenient solutions are to avoid the issue at all.
Only use a single project, everything will be included in the package
Pack each project on its own and use the generated package instead of the referenced project

How to specify the assembly version for a .NET Core project?

I noticed in new .NET Core projects there is no AssemblyInfo.cs file created. I have seen that you can still set assembly attributes such as AssemblyVersion and so forth.
Are there still any valid reasons to use an AssemblyInfo.cs file?

You can absolutely create an AssemblyInfo.cs file and configure your assembly like you did in the past. Of course, since the properties are set using assembly attributes, you do not need to use AssemblyInfo but can choose any other file name or even an existing one.
That being said, the reason that the AssemblyInfo.cs is no longer included in the default templates is that the new SDK-style project type supports setting this information within the csproj project file.
So the usual approach to setting the version of your assembly would be to set the Version property within your project file (or have that automatically set as part of your build process). For example:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.0</TargetFramework>
<Version>1.2.3</Version>
</PropertyGroup>
…
</Project>
Since this is a MSBuild property, you can also set this during the build process e.g. with dotnet build /p:Version=1.2.3.
There are also the properties VersionPrefix and VersionSuffix which can be used to automatically construct version numbers from the environment (e.g. Git commit ids, or build numbers).
In addition to the version related properties, there are also some more NuGet properties you can set in the project file, which makes the AssemblyInfo.cs mostly redundant.

According to migration guide, these days, we have few flexible ways to set up assembly attributes.
Use old-style AssemblyInfo.cs file (create manually).
using System;
using System.Reflection;
[assembly: System.Reflection.AssemblyCompanyAttribute("...")]
[assembly: System.Reflection.AssemblyCopyrightAttribute("...")]
[assembly: System.Reflection.AssemblyDescriptionAttribute("...")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("...")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("...")]
[assembly: System.Reflection.AssemblyProductAttribute("...")]
[assembly: System.Reflection.AssemblyTitleAttribute("...")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0-dev01234567")]
Use MSBuild's properties to generate assembly attributes on build time (may be static in your.csproj or passed via command line arguments like /property:Version=1.0.0-dev01234567).
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<Company>...</Company>
<Copyright>...</Copyright>
<Description>...</Description>
<Product>...</Product>
<AssemblyTitle>...</AssemblyTitle>
<Version>1.0.0-dev01234567</Version>
</PropertyGroup>
...
</Project>
Note: you may merge both solutions but avoid duplicates of assembly attributes.

I'm using Visual Studio 2022 and .NET Core 6.
Right click on the project in Solution Explorer
Edit Project File
Here is an example project file containing Version, AssemblyVersion and FileVersion:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<Version>1.0.0</Version>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
</PropertyGroup>
...
</Project>

Reasons for still using an AssemblyInfo.cs file might include
you want to share some of the AssemblyInfo across projects,
which you can do with a file
you might have a code-generation process that spits out the assemblyinfo
the project file format doesn't yet support all the attributes you might want to use. The project Sdk knows how to auto-generate a limited set of [AssembyAttributes] from Xml Elements with matching names in the csproj file, but it doesn't support autogeneration of arbitrary [AssembyAttributes] or other metadata for your assembly.
AssemblyInfo.cs is “just” a source code file, you might have other metadata – whether AssemblyAttributes or classes or other – you want to keep all in one easily found place.

From Your Project -> Select Properties
On left panel select Package/General
At field Assembly version and File version enter your version (ex: 1.0.0.0)

Copy all of the required dlls to folder

I have a MonoAndroid10 project and it has a lot of dependencies(NuGet packages too). I would like to be able to copy all of the DLL dependencies to the output folder.
Normally in a .Net Standard 2.0 project the following
<PropertyGroup>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>
would make that possible. But in the MonoAndroid project, nothing happens.
If what I posted above doesn't work for a MonoAndroid project, how could I copy everything that I need in some folder, preferably in a post-build action?
I'm trying to do this because after copying all of the required DLLs in one folder I can merge them together with ILRepack.

I've come across this today, solved by adding
<CopyNuGetImplementations>true</CopyNuGetImplementations>
to android project .csproj file (under the desired PropertyGroup section).
Note: there is no need to set CopyLocalLockFileAssemblies to ture neither in android project nor in any of the dependencies.

Is there a way to override attributes from AssemblyInfo.cs (e.g. AssemblyVersionAttribute)?

I'm using dotnet core. This is for a CI process, not local builds. I'd like to allow devs to create AssemblyInfo.cs files for things like title etc but I'd like my build process to have control over the assembly's version.
Currently I'm using the "dotnet build ... /p:Version=1.2.3.4" command, but as soon as an AssemblyInfo.cs file is present this version number is superseded, even if the AssemblyInfo.cs doesn't specify any version properties.
The only way I can control the version from the CLI is to remove the AssemblyInfo.cs file. Is there any way of doing this without resorting to manually altering the AssemblyInfo.cs file before build?

The tooling generates a custom .cs file containing assembly attributes. The compiler only allows each attribute to be defined just one. Usually you'd turn off the automatic assembly info generation completely, but the SDK enables you to control the generation of each attribute individually.
So if you edit the csproj file to contain these property group (inside the <Project> element):
<PropertyGroup>
<!-- true is the default here -->
<GenerateAssemblyInfo>true</GenerateAssemblyInfo>
<GenerateAssemblyCopyrightAttribute>false</GenerateAssemblyCopyrightAttribute>
<GenerateAssemblyDescriptionAttribute>false</GenerateAssemblyDescriptionAttribute>
<GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
<GenerateAssemblyTitleAttribute>false</GenerateAssemblyTitleAttribute>
</PropertyGroup>
These properties won't be auto-generated during compilation and you can define them in a custom property. The complete list is available in the dotnet/sdk repo.