Using The AutoGenerated .NET Core/Standard AssemblyInfo.cs
When you create a new .NET Core/.NET Standard project you will get a auto generated set of attributes, which is based on these settings for the project
Which you can in effect in the obj folder, where a auto generated xxxxAssemblyInfo.cs class is created for you.
/------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.42000
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
using System;
using System.Reflection;
[assembly: System.Reflection.AssemblyCompanyAttribute("SomeDemoCode.Std")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.0")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0")]
[assembly: System.Reflection.AssemblyProductAttribute("SomeDemoCode.Std")]
[assembly: System.Reflection.AssemblyTitleAttribute("SomeDemoCode.Std")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0.0")]
// Generated by the MSBuild WriteCodeFragment class.
So when we build the project we would end up with this version being applied to the resulting output for the project
Ok that explains how the AssemblyInfo stuff works in .NET Core/Standard, but what is the .NET Cote/Standard way of doing auto incrementing versions?
Well believe it or not there is not a native feature for this, there are various efforts/attempts at this which you can read more about
· https://stackoverflow.com/questions/43019832/auto-versioning-in-visual-studio-2017-net-core
· https://andrewlock.net/version-vs-versionsuffix-vs-packageversion-what-do-they-all-mean/
After reading all of those the best approach seemed to be based upon sticking with using the Auto generated Assembly.info stuff, but to come up with some scheme that would aid in the generation of the assembly version at build time.
What that means is you want to ensure your .csproj file looks something like this, where it can be seen that some of the .NET Core/Standard auto generated AssemblyInfo stuff is made available directly in the project file
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard2.0</TargetFramework> <Platforms>x64</Platforms> </PropertyGroup> <PropertyGroup> <DefineConstants>STD</DefineConstants> <PlatformTarget>x64</PlatformTarget> <AssemblyName>SomeDemoCode.Std</AssemblyName> <RootNamespace>SomeDemoCode.Std</RootNamespace> <VersionSuffix>1.0.0.$([System.DateTime]::UtcNow.ToString(mmff))</VersionSuffix> <AssemblyVersion Condition=" '$(VersionSuffix)' == '' ">0.0.0.1</AssemblyVersion> <AssemblyVersion Condition=" '$(VersionSuffix)' != '' ">$(VersionSuffix)</AssemblyVersion> <Version Condition=" '$(VersionSuffix)' == '' ">0.0.1.0</Version> <Version Condition=" '$(VersionSuffix)' != '' ">$(VersionSuffix)</Version> <Company>SAS</Company> <Authors>SAS</Authors> <Copyright>Copyright © SAS 2020</Copyright> <Product>Demo 1.0</Product> </PropertyGroup> </Project>
With this in place you will get a auto versioned Assembly version using just .NET Core/Standard approach
But what about InternalsVisibleTo?
Quite often we want to still expose our .NET Standard projects to test projects. And if the .NET Core/Standard projects auto generate the AssemblyInfo based on either defaults or attributes in the actual .csproj file, how do we add a InternalsVisibleTo, this doesn’t seem to be covered by the auto generated AssemblyInfo that gets created for .NET Core/Standard project, nor does it seem to be available as a csproj level MSBUILD property item. So how do we do this ?
luckily this is quite simple we just need to do the following in a custom file which you can call anything you want, you can even call it “AssemblyInfo.cs” if you want
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("SomeDemoCode.IntegrationTests")]
Opting Out Of the Auto Assembly Info Generation Process And Using Our Own Auto Increment Scheme
If you want to use the .NET Framework approach to auto versioning this is normally done with a wildcard in the
[assembly: AssemblyVersion("1.0.*")]
So you might think, hmm so I can just override this by adding my own AssemblyInfo.cs, But this will not work you will get this when you build
> Error CS0579: Duplicate 'System.Reflection.AssemblyFileVersionAttribute' attribute > Error CS0579: Duplicate 'System.Reflection.AssemblyInformationalVersionAttribute' attribute > Error CS0579: Duplicate 'System.Reflection.AssemblyVersionAttribute' attribute
Luckily we can opt out of this auto generation process, where we have to add the following to our .NET Core/.NET standard csproj file
<PropertyGroup> <GenerateAssemblyInfo>false</GenerateAssemblyInfo> <Deterministic>false</Deterministic> </PropertyGroup>
You need the deterministic property otherwise you will get this error
Wildcards are only allowed if the build is not deterministic, which is the default for .Net Core projects. Adding False to csproj fixes the issue.
With this in place we can now include a custom AssemblyInfo.cs which could for example use a auto incrementing version number, where we use a wild card when specifying the AssemblyVersion
using System.Reflection;
using System.Runtime.InteropServices;
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("SomeDemoCode.Std")]
[assembly: AssemblyDescription("SomeDemoCode .NET Standard")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("SAS")]
[assembly: AssemblyProduct("SAS 1.0")]
[assembly: AssemblyCopyright("Copyright © SAS 2020")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]
// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("CA7543D7-0F0F-4B48-9398-2712098E9324")]
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.*")]
Now when we build you will get some nice auto incrementing assembly versions inside your .NET Core/Standard projects
Sacha's Blog 
Nice article, and good solution. Two big drawback is that the build on a server will always have a different version from the local ones; and the version numbers will not be consecutive over time…
True but for my situation we don’t care