mhutch
commented
8 months ago Currently that's not the case - definitions in a schema will always be preferred over inferred definitions, but inference is performed for all files and completion includes all inferred values that are not present in a schema.
Note that simply suppressing the inferred schema for files with an explicit schema is present would not be a very good solution. For example, a NuGet package could have a foo.targets, a foo.props, and several other msbuild files that are imported by the package targets/props. If the package author wanted to hide a symbol used by all of these files, they would have to add schemas for all these files, rather than just having one schema file containing all the symbols for their package.
One possible answer would be to add a setting that schema files could set that would suppress inference in all files in that directory and its subdirectories. However this would be non-ideal - the inferred symbols would no longer be exposed to consumers of your package, but you would no longer get completion for the inferred properties when you were editing the files in your package.
I have been considering adding a scoping mechanism that would allow a schema to mark symbols as global, sdk, directory or file scoped. There is currently a very primitive mechanism in place that treats symbols as file scoped when they start with an underscore.
A proper scoping model would help as it would allow you to explicitly mark properties as directory, sdk, or file scoped to prevent them being exposed to consumers. We could then consider treating symbols from inferred schemas as directory scoped when an schema file is present in that directory.
Trying the tool, and seeing too many properties, a lot of them inferred
(and not relevant, for example for the SDK here: https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/tree/master/src/MSBuild.Sdk.SqlProj/Sdk )
Will the precense of a .buildschema.json file for all targets improve this?