Add scoping and information hiding for msbuild variables (properties and items)

[richardszalay]

I'd like to start a conversation around the potential for PropertyGroups / ItemGroups that are scoped to a local target.

MSBuild scripts, written by Microsoft or not, end up using overly descriptive names for properties and items to avoid clashing with those created by other targets and introducing "undefined behavior".

The proposed feature would introduce the ability to define a property/item group as "Scope=Target". Values defined in these blocks would be added to a scope that is local to the target. Variable resolution would always prefer the target scope, if it is available.

<PropertyGroup Scope="Target">
</PropertyGroup>

This scope would be truly local - target dependency chains wouldn't be able to see each others' target-scoped variables.

Disclaimer: While I'm reasonably familiar with consuming MSBuild as a developer, as well as the web publishing tasks developed by Microsoft, I'm not at all familiar with the MSBuild source code. There might be some very good architectural reasons why this proposal isn't possible or feasible.

Outstanding questions:

• What about file/project level? Unsupported, or additional support for Scope=Project?
• What if a target defines a globally scoped variable after already defining a target scoped variable? It might be best to destroy the locally scoped variable, as it might cause developer confusion if it continues to resolve the locally scoped value in preference to the globally scoped variable.

[erwinbonsma]

I am in favour of such a feature. In our custom MSBuild scripts we use poor man's scoping for item groups. In particular:

• Naming conventions to communicate intended scope (double underscore prefix => target local, single underscore prefix => file local)
• Explicitly empty local item groups at the end of each target, e.g. <__Lines Remove="@(__Lines)" />

This, however, is far from ideal. The explicit remove statements:

• add clutter,
• are error prone (typo in name, copy/paste mistakes, can become out-of-synch),
• can mysteriously fail (when items include semi-columns in their identity; this happened to me today, as they were lines read from file), and
• incur an unnecessary performance penalty (especially for large item groups)

Scoping would nicely address this. A second-best solution would be a convenient syntax for emptying an item group, but the latter is obviously inferior.

[cdmihai]

I see three potential privacy scopes:

• target level. Can be defined in targets. Can only be referenced inside the target that declared it. Gets cleaned when the target exists.
• project level. Can be defined in project and in targets. A project level variable can be referenced only in entities from that project file (other project level variables or targets)
• global level. Can be defined anywhere (this is the only option in msbuild currently). Can be referenced everywhere.

If we ever do this, it would good to actually formalize it in terms of established scoping theory (lexical vs dynamic, etc).

[rainersigwald]

A problem with "project level" is the common pattern of having related .props and .targets files. It might be reasonable to want to have an access level that would cover both.

[LostTime76]

I don't find this whole msbuild properties are basically all global thing to be very sane especially since it came and smacked me in the face just now. I am trying to author multiple build task libraries in different repos with .targets and .props files. Multiple .props files would have the same property names, otherwise I would have to somehow make them unique across the world. I had thought that the properties would get evaluated then and there and be useable in the UsingTask declarations; however, UsingTask declarations are evaluated in a subsequent pass after all properties are evaluated. That means whatever .props file set the property last, is the one that wins. That obviously screws up other .props files trying to declare UsingTask statements.

What exactly do you expect me to do here? Hardcode 'magic constants' into each UsingTask statement so that properties are not used? That means if those constants change, I have to update a billion UsingTasks. I had considered this as a necessary evil; however, I actually have several things that must be properties, because they are built based on the path of the .props file and then used in the UsingTask decalarations. I can't hardcode constants there.

It would not be the end of the world if UsingTasks got evaluated as they were declared after the properties as the properties would just get used and then subsequent .props files could just redefine the properties.

Is it honestly expected for me to declare all my property values as ThisVeryLongNamespace_AssemblyTasksPath to try and make them unique?

[rainersigwald]

Is it honestly expected for me to declare all my property values as ThisVeryLongNamespace_AssemblyTasksPath to try and make them unique?

Yes, that's the best option available today. It doesn't usually have to be that long, most prefixes are pretty short. For example, NuGet uses $(RestoreTaskAssemblyFile) for the purpose you're describing.