[Feature Request]: The warning in the WriteCodeFragment task should be changed to report the name of the attribute type whose definition it did not find.

[ajtruckle]

Issue Description

Not sure if this is a bug as such, but had to pick a template all the same. I set my compiler output to Normal and noticed this output:

1>Target GenerateTargetFrameworkMonikerAttribute:
1>  Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files.
1>Target CoreGenerateAssemblyInfo:
1>  Could not infer the type of parameter "#1" because the attribute type is unknown. The value will be treated as a string.
1>Target _GenerateSourceLinkFile:
1>  Updating Source Link file 'obj\Release\net8.0\MSATools.sourcelink.json'.

Why does it say:

Could not infer the type of parameter "#1" because the attribute type is unknown. The value will be treated as a string.

I have tried to find an explanation, but it is a little over my head. Eg:

#2281

This is a C# .NET8.0 Console App build with latest version of Visual Stduio 2022.

Steps to Reproduce

I can't get this to reproduce with an empty C# console project so I am not sure of the steps to reproduce.

Expected Behavior

I don't expect to see this warning.

Actual Behavior

I am getting this warning.

Analysis

Initially I thought it was because my version numbers for n.n.n and I changed them to n.n.n.n. It it was not the reason.

Versions & Configurations

MSBuild version 17.9.8+b34f75857 for .NET Framework
17.9.8.16306

Windows 11 x64

[KalleOlaviNiemitalo]

Get a more detailed MSBuild log and check what is being passed to the AssemblyAttributes parameter of the WriteCodeFragment task. I think WriteCodeFragment was unable to locate the definition of some attribute type that is listed there, and thus could not check the parameter types of the constructors. If the type is defined in some assembly that WriteCodeFragment does not search, I don't think there is a way to tell WriteCodeFragment from where to load it; but you can instead add item metadata to specify the type of the parameter so that WriteCodeFragment won't have to find it by reflection.

This still deserves fixes in .NET:

• If .NET SDK generated the item that was passed in AssemblyAttributes, then it should be changed to set the parameter type.
• The warning in the WriteCodeFragment task should be changed to report the name of the attribute type whose definition it did not find.

[ajtruckle]

@KalleOlaviNiemitalo

Get a more detailed MSBuild log and check what is being passed to the AssemblyAttributes parameter of the WriteCodeFragment task.

I have just set the build mode to Diagnostic and this is what I can find that is relevant:

1>  Using "WriteCodeFragment" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
1>  Task "WriteCodeFragment"
1>    Task Parameter:OutputFile=obj\Release\net8.0\MSATools.AssemblyInfo.cs
1>    Task Parameter:Language=C#
1>    Task Parameter:
1>        AssemblyAttributes=
1>            Microsoft.Extensions.Configuration.UserSecrets.UserSecretsIdAttribute
1>                    _Parameter1=~~~~~~~~~~~~~~~~~~
1>            System.Reflection.AssemblyCompanyAttribute
1>                    _Parameter1=MSATools
1>            System.Reflection.AssemblyConfigurationAttribute
1>                    _Parameter1=Release
1>            System.Reflection.AssemblyCopyrightAttribute
1>                    _Parameter1=Andrew Truckle © 2024
1>            System.Reflection.AssemblyDescriptionAttribute
1>                    _Parameter1=MSA Tools Console
1>            System.Reflection.AssemblyFileVersionAttribute
1>                    _Parameter1=2024.4.14.0
1>            System.Reflection.AssemblyInformationalVersionAttribute
1>                    _Parameter1=2024.4.14.0
1>            System.Reflection.AssemblyProductAttribute
1>                    _Parameter1=MSATools
1>            System.Reflection.AssemblyTitleAttribute
1>                    _Parameter1=MSATools
1>            System.Reflection.AssemblyVersionAttribute
1>                    _Parameter1=2024.4.14.0
1>    Could not infer the type of parameter "#1" because the attribute type is unknown. The value will be treated as a string.

From Package / General in Project Settings:

[KalleOlaviNiemitalo]

I'd blame Microsoft.Extensions.Configuration.UserSecrets.UserSecretsIdAttribute; that seems unlikely to be found by WriteCodeFragment.

https://github.com/dotnet/runtime/blob/9e6ba1f68c6a9c7206dacdf1e4cac67ea19931eb/src/libraries/Microsoft.Extensions.Configuration.UserSecrets/src/buildTransitive/Microsoft.Extensions.Configuration.UserSecrets.targets#L9-L11

This could be changed to set the parameter type metadata if the MSBuild version is high enough that its WriteCodeFragment task supports such metadata and won't treat it as another parameter.

[ajtruckle]

@KalleOlaviNiemitalo

This could be changed to set the parameter type metadata if the MSBuild version is high enough that its WriteCodeFragment task supports such metadata and won't treat it as another parameter.

This is the version that I have:

MSBuild version 17.9.8+b34f75857 for .NET Framework
17.9.8.16306

I'd blame Microsoft.Extensions.Configuration.UserSecrets.UserSecretsIdAttribute; that seems unlikely to be found by WriteCodeFragment.

Note that UserSecretsIdAttribute value there is not actually ~~~~~~~~~~~~~~~~~~. I changed it from a GUID value. Was not sure if I should share it publically.

[KalleOlaviNiemitalo]

I meant, if the targets file in the Microsoft.Extensions.Configuration.UserSecrets package is modified, then that should preferably be done in such a way that compatibility with older versions of MSBuild doesn't break.

The value of the UserSecretsIdAttribute does not matter for the "Could not infer" message; only the attribute type matters. But the user secrets ID isn't very secret anyway; anybody to whom you distribute the executable can read it from the assembly attributes, or capture it by monitoring the names of opened files (e.g. strace on Linux) when the process attempts to load the user secrets from the file system.

[ajtruckle]

@KalleOlaviNiemitalo
Ok. So, I just leave this until it is fixed?

[KalleOlaviNiemitalo]

Looking at the message again

1>Target CoreGenerateAssemblyInfo:
1>  Could not infer the type of parameter "#1" because the attribute type is unknown. The value will be treated as a string.

This doesn't even say "warning" so it's just a message. I don't think you need to do anything to it.

If you want to get rid of it anyway, then one way would be to set <GenerateUserSecretsAttribute>false</GenerateUserSecretsAttribute> in your project to prevent the attribute from being generated, and instead add it yourself, in one of these places:

• in AssemblyInfo.cs: then the WriteCodeFragment task is not involved, and the C# compiler knows where the attribute type is defined. But if you ever change the user secrets ID then you'd have to change it in two places: in the csproj for dotnet user-secrets, and in AssemblyInfo.cs for runtime.
• as an AssemblyAttribute item in the csproj: the same way as Microsoft.Extensions.Configuration.UserSecrets.targets adds it, but you'd add the parameter type too.

As a user of MSBuild, I'd like to keep this issue open for the feature request

The warning in the WriteCodeFragment task should be changed to report the name of the attribute type whose definition it did not find.

but if you prefer closing this one, then I can file a separate one for that.

[ajtruckle]

@KalleOlaviNiemitalo

As a user of MSBuild, I'd like to keep this issue open for the feature request

We can leave it open. 👍

[ajtruckle]

@KalleOlaviNiemitalo
I have changed the title of this issue but I can't add the Feature Request label.