Generated AssemblyInfo.cs file should be regenerated after package restore

[AArnott]

Incremental build is buggy. If a user installs Nerdbank.GitVersioning into a .netstandard project in VS2017 after the assemblyinfo.cs was generated in the obj directory, the user will get build errors until they delete the file.

I've hit this so many times, and @asherber just reported it as well: dotnet/Nerdbank.GitVersioning#121

Please regenerate the file on each build, or delete it as part of package restore.

You can keep CoreCompile skipping behavior while still generating this intermediate source file on each build the same way you do for project.lock.json: generate the file elsewhere and then only copy it over the original file if the contents are not equivalent
.

[dasMulli]

Does the target added through that nuget package add itself to MSBuildAllProjects (see example)?

I've filed a smilier issue (#967), PR is still in discussion (#1007).

[AArnott]

Thanks for the tip about MSBuildAllProjects. I usually include that, but evidently forgot to do so in this package. I'll see how that works.

[AArnott]

That doesn't resolve the issue. Probably because the .targets file in my package cache is older than the generated assemblyinfo.cs file, so MSBuild considers that it doesn't invalidate the generated file.

[nguerrera]

If restore changed the targets that are imported, then the file restore generates with imports from packages should have changed. Does that not put itself in MSBuildAllProjects?

[AArnott]

Yes, my package does (now) add the .targets to MSBuildAllProjects. But MSBuild does not track changes to the set of projects in that property, so that doesn't matter to MSBuild. What does matter for MSBuild's own Target Inputs/Outputs attributes is whether any file specified in Inputs is newer than any file specified in Outputs. And as I said in my last comment, unless package restore actually unpacked NB.GV for the first time, then the .targets file will be older than your last generated source file, so it still won't regenerate.

[nguerrera]

@AArnott I understand that, but I am referring to the contents of obj\SomeProject.nuget.g.targets that restore generates to pull in SomePackage.targets, not to SomePackage.targets itself.

AFAICT, any change to what's imported via packages will cause changes to *.nuget.g.(props|targets) to change during restore. If you start using a package with targets, then the import will be written for the first time. If you stop using it, the import will be deleted. Even if you just change versions, it will still change because the path includes the version.

I just checked and *.nuget.g.(props|targets) do include themselves in MSBuildAllProjects. I'm missing why that doesn't solve the issue...

[AArnott]

Oh I see. Then yes, I guess I'd be puzzled by that as well -- unless the very build that is /t:restore itself writes out the generated source file in question, and later writes out the nuget imports .targets file.

[Bakanych]

Reproducing for vsts build solution task with csproj vnext.
/obj/*AssemblyInfo.cs is cached with old version.

[dasMulli]

@Bakanych can you share a binary log (/bl msbuild argument > msbuild.binlog) that reproduces this?

the 2.0.0+ SDKs should now detect changes to the attribute values for incremental builds.

[Bakanych]

@dasMulli
I tried to use /bl argument, but looks like it's overridden by /dl param provided by vsts tasks. Here is msbuild call according to vsts build logs:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe /nologo /bl:.\log.binlog /dl:CentralLogger,C:\agent2\_work\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.120.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll;RootDetailId=c65cf082-f576-41f7-97eb-2bb72d1295f4|SolutionDir=C:\agent2\_work\14\s*ForwardingLogger,C:\agent2\_work\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.120.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll /nr:false /p:Version=2018.01.22.3 /p:PackageOutputPath=C:\agent2\_work\14\a /p:platform=any cpu /p:configuration=release /p:VisualStudioVersion=15.0 /p:_MSDeployUserAgent=TFS_55a81053-f8c8-46d8-b9a9-12fef6d85b06_build_22_1275 C:\agent2\_work\14\s\Core.SS.Common.sln

[Bakanych]

I'm using incremental builds having clean checkbox off both in get sources and build tasks.

[livarcocc]

Any chance you can repro this locally and provide some logs to us, or maybe a repro? I will be nearly impossible to tell what might be going on otherwise.

Also, can you share what version of the .NET Core SDK you have installed in your box?

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.

[github-actions]

This issue will now be closed since it has been labeled 'stale' without activity for 30 days.