Attribute conflict in Azure Functions project

[Galarzaa90]

When trying to use this on a project using Azure Functions, the build fails on the second time it is called (i.e. when the VersionAssemblyInfo.cs file exists). I have to manually delete the file every time.

NETSDK1022
Duplicate 'Compile' items were included. The .NET SDK includes 'Compile' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultCompileItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'Properties\VersionAssemblyInfo.cs'

This is what is on my csproj file:

<PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <AzureFunctionsVersion>v2</AzureFunctionsVersion>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
  </PropertyGroup>

I can fix the build by adding <EnableDefaultCompileItems>false</EnableDefaultCompileItems>, but then no Functions are recognized when running.

[MicahZoltu]

@Galarzaa90 Hmm, it seems that this project may not be compatible with the latest version of .NET SDK based on that linked KB article. This package creates a file named Properties\VersionAssemblyInfo.cs in the root of the project and adds a .targets file (which .NET SDK picks up and uses as part of your build) with the following contents:

	<ItemGroup>
		<Compile Include="Properties\VersionAssemblyInfo.cs" />
	</ItemGroup>

The problem appears to be that the latest version of the .NET SDK implicitly adds <Compile ...> entries for all files matching the glob **/*.cs. This means that Properties\VersionAssemblyInfo.cs is already implicitly in the list of "files to compile". When we try to add that file to the list of files to compile, the tooling complains that we added the same file twice.

I'm not sure what the easy way to fix this is without having things break for older versions of MSBuild.

One option is you could manually add <Compile ...> entries to your .csproj file for your various source files and then run with <EnableDefaultCompileItems>false.

Another option is to fork this project and remove these lines, then publish as your own forked NuGet package:

Zoltu.Versioning/Zoltu.Versioning/Zoltu.Versioning.targets

Lines 24 to 26 in 8727a3e

	<ItemGroup>
	<Compile Include="Properties\VersionAssemblyInfo.cs" />
	</ItemGroup>

[Galarzaa90]

Thanks, I will try it out.

I have never published a NuGet package, I guess I would have to change the namespace to my own so it doesn't conflict? 🤔

[MicahZoltu]

Yeah, you'll need to publish it to your own namespace. This repository uses AppVeyor for CI, and I think they have free accounts. I believe if you create a NuGet publishing account and an AppVeyor account you should be able to just update the appveyor.yml file with your NuGet secret (encrypted by AppVeyor) and then point AppVeyor at the repository and it will publish to NuGet for you. Alternatively, you could publish manually by following publishing instructions on NuGet's website.

[cje2002]

I've made this work for us by adding a condition to the Compile Include element:

<Compile Include="Properties\VersionAssemblyInfo.cs" Condition="$(TargetFramework) != 'net5.0'" />

I'm not clear if this will work in all cases though - from my reading of the docs it's the Sdk attribute of the Project tag that dictates how the csproj file etc is interpreted, and I can't find any msbuild properties that would target it.

@MicahZoltu do you have any deeper knowledge of this?

[MicahZoltu]

Unfortunately I haven't worked in .NET much in the past several years outside of a few miscellaneous patches to things so I no longer remember much about the MSBuild system. 😢 IIUC, you are basically saying add that file manually outside of .NET 5 and let .NET 5 add it automatically?

[cje2002]

We're just starting some new projects in .Net 5 so I don't have that much experience of it yet, but the new csproj format doesn't need you to explicitly state which files are included in the project - it automatically includes everything in the project file system. So adding it via the element gievs you an error as it's included twice - the condition is able to work around that.

What I'm not clear about is whether that holds for all .Net 5 projects. I've not seen anything that clearly documents this.

I've managed to get a build working locally with that change, but once it hit our server it failed because the MSBuild in the project was too low (I have all sorts of ancient stuff on my dev PC). So I'm currently reworking some of the dependencies in the project to bring up to a more current version.

I suspect that all of these changes will make it difficult to merge into this code branch while maintaining support for legacy systems - a fork looks like the best option.

With all of that in place it works well though. Thank you :-)