visual studio build 15.9.5 not applying assembluinfo

[vsfeedback]

Hello,

We have had this issue since build 15.9.4; on our F# project assemblyinfo.fs is no longer being honoured/applyed to the dlls.

AssemblyInfo.fs:

namespace Transactive.Seymour.Server.Util.AssemblyInfo

open System.Reflection
open System.Runtime.CompilerServices // IS needed despite the compiler's opinion
open 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("Server.Util")>]
[<assembly: AssemblyDescription("")>]
[<assembly: AssemblyConfiguration("")>]
[<assembly: AssemblyCompany("")>]
[<assembly: AssemblyProduct("Server.Util")>]
[<assembly: AssemblyCopyright("Copyright ©  2017")>]
[<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("bf44ed42-2261-4e56-bae6-02e9c57aaa5d")>]

// 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("0.2.1.0")>]
// See https://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin
// for a good discussion.
[<assembly: AssemblyVersion("0.2.1.0")>]
[<assembly: AssemblyFileVersion("0.2.1.0")>]
[<assembly: AssemblyInformationalVersion("0.2.1.197+Sha.e866c41a")>]

do
    ()

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/422451/visual-studio-build-1595-not-applying-assembluinfo.html
VSTS ticketId: 762364
These are the original issue comments:
(no comments)
These are the original issue solutions:
(no solutions)

[cartermp]

Edited source code for better formatting

[kevinneufeld]

Ignored in Visual Studio 2017 v15.9.6

[cartermp]

@kevinneufeld I assume this is with the non-.NET SDK-style (aka old-style) project types?

[cartermp]

@KevinRansom any ideas?

[kevinneufeld]

@cartermp we have a mix of project type both older as well as newer. We are slowly migrating to the newer project styles and azure functions 2.0.

Do you have an alternative method to apply assembly info?

[cartermp]

Are you using this?

<PropertyGroup>
   <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

Alternatively, so long as your projects are using a .NET SDK corresponding with .NET Core 2.1 or higher, you can also auto generate them via properties such as those specified in a Directory.build.props file. This is the preferred mechanism for .NET Core, but you can also apply the above technique.

[kevinneufeld]

@cartermp yes we are using the following:

<PropertyGroup>
   <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

We use GitVersion to update our AssemblyInfo.fs files at the moment. I will need to investigate into Directory.build.props file more and see if I can make it work.

[cartermp]

Unfortunately, there may be issues with #3113 as well 😞

Basically, if you use the compiler within Visual Studio to do your build, autogeneration should work. But if you use dotnet build it does not.

[KevinRansom]

@kevinneufeld, @cartermp

Autogenerate works and generates the attributes and they are included in the assembly. We also need to generate and embed a native resource in the built .dll that contains this block so that they can be displayed on the details tab in explorer.

A fix is not yet scheduled, but I would expect it to be implemented sometime after Dev16.0 RTM's.

[kevinneufeld]

@cartermp,
I did a lot of cleanup of our solution and was able to find these issues:

• missing <GenerateAssemblyInfo>false</GenerateAssemblyInfo> in some of the projects in the solution.
• as well as some namespace collisions due to copy/paste errors
  After cleanup, the assembly info was applied as expected - from Visual Studio Build. (dotnet build - not tested)

I was also able to try out the auto-gen of the assembly info; this may work out better for us - using GitVersion and the when attribute Conditions:

<When Condition="'$(CI)'=='true' ">
   <PropertyGroup>
       <Company>SomeCompanyName</Company>
       <Authors>SomeCompanyNameTeam</Authors>
       <PackageId>ACoolPackage</PackageId>
       <Version>$(GitVersion_InformationalVersion)</Version>
       <AssemblyVersion>$(GitVersion_AssemblySemVer)</AssemblyVersion>
       <FileVersion>$(GitVersion_AssemblySemVer)</FileVersion>
   </PropertyGroup>
</When>

The above works with MSBuild command line and within visual studio;

If the <version> is a string like '1.0.0-local.001+Sha.bd36b357d63ac493930c718950f896af36539994'
dotnet build will error : 1.0.0-local.001+Sha.bd36b357d63ac493930c718950f896af36539994 is not a valid version string

[KevinRansom]

@kevinneufeld,

That is a NettSDK/Nuget versioning validation not the F# compiler, I get the same reasult in C# too.

NETSDK1018

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <Version>1.0.0-local.001+Sha.bd36b357d63ac493930c718950f896af36539994</Version>
  </PropertyGroup>

Built with this error:

Error occurred while restoring NuGet packages: The operation failed as details for project ConsoleApp35 could not be loaded.
1>------ Rebuild All started: Project: ConsoleApp35, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\2.1.503\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.GenerateAssemblyInfo.targets(161,5): error NETSDK1018: Invalid NuGet version string: '1.0.0-local.001+Sha.bd36b357d63ac493930c718950f896af36539994'.
1>Done building project "ConsoleApp35.fsproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

@Livaroc will be able to point you in the right direction.

[kevinneufeld]

@KevinRansom thanks for the insight, I had to alter our pattern to match SemVer 2.0
1.0.0-local001.Sha.bd36b357d63ac493930c718950f896af36539994