UserSecretsId Missing From PropertyGroup

[vindicatorr]

I'm making the assumption that this extension is used to expose things like the PropertyGroup UserSecretsId (https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-2.2&tabs=linux#set-a-secret), but the closest I get is "GenerateUserSecretsAttribute".

I know the limitation mentioned for PropertyGroups, but wasn't sure if this applied. Maybe it's something best left for the msbuild folks to figure out.

This is something I brought up in a comment at dotnet/aspnetcore#2867 (comment)

[tintoy]

Hi - let me have a look at get back to you :)

[tintoy]

I can add it here:

https://github.com/tintoy/msbuild-project-tools-server/blob/master/help/properties.json

[vindicatorr]

Ah, I didn't realize it was some hard-coded (so to speak) stuff, rather than some magic going through the libraries and recognizing what goes in appsettings and what goes in the csproj.

Hopefully that "magic" can happen, or I can see the maintenance of the list being hellish.

[tintoy]

The extension also shows any properties defined in any of the projects your project includes, but since there is no default value for UserSecretsId, it doesn’t show up. Visual Studio does the same thing using XSDs :)

[vindicatorr]

I've been away for awhile, but do remember XSD a little.

Yeah, that magic your extension does, getting the project includes, is what I thought would also be used for all of the other packages in the system.
Odd that it would require default values for things to show up, but then I didn't look into the magic your extension does.

There was some other tool I used to use long ago that would pull all of the IL information from files (I don't think it was ilspy that I see is also an extension), and that's what I thought would be used to populate the intellisense stuff.
Like, an extension could perhaps scan through the dotnet root for all libraries and extract the information that could then be placed into an XSD. And upon every start of the extension (loading VS), it would look for any file changes and alter the XSD accordingly.

It's just the not-knowing part of what "CAN" go into a csproj or appsettings.json, or how it should be structured, that perturbs me.
If UserSecretsId was missed, it makes me wonder what other things I may be missing out on.
I'd think that if TargetFramework and UserSecretsId both inherit from Attribute, then MAYBE all other classes that inherit Attribute could also be placed in the csproj.

[tintoy]

Yep, I've had the same thoughts on more than one occasion :)

The problem is that there is no "fixed" list of properties because it's all dynamic. It's a bit like JavaScript, in that the only way to know what symbols are in scope is to actually "run" it.

Lots of properties (such as TargetFramework) are given default values by declaring them in a PropertyGroup somewhere (it's those declarations that cause the properties to show up where we're able to look for them). But some properties (such as UserSecretsId) don't have a default value because they are not declared anywhere (but are tested for in expressions used in MSBuild conditions).

In theory we could go as far as parsing expressions, but that would probably kill performance.

For sure, language services are easier to build for statically-defined strongly-typed languages such as C# (or Cake). It's trickier for dynamic ones (e.g. PowerShell or MSBuild).

On the other hand, that flexibility is also what gives the dynamic languages their strength :)

PS. We do scan task assemblies for metadata to determine the schema for task elements (but they're the just about the only aspect of MSBuild that drills down to actual code).