Code Cleanup: Bundle.props can be moved into Bundle.targets

[dannyvv]

At the moment the bundle.props is assumed to be imported after all the users settings. Typically .props are imported at the top of the project and set the defaults.

This issue tracks:

• Determining which values can be defaults and move
• Move the property groups that still require to be processed at the end of the msbuild evaluation to the bundle.tarets file.

[JunielKatarn]

Does Bundle.props contain targets, or properties and item definitions?

[asklar]

so we originally had everything in one file but I had asked that we split things up into properties that we want to be able to be overridable by the project, and the targets which we dont expect people to want to override, so that's how we ended up with the current layout.

[dannyvv]

There are various ways in msbuild to go about this. MsBuild properties are just a simple recursive descent macro expansion. So there are two ways to deal with defaults: a) You unconditionally set them at the top of the file (import the props before the user properties) <Foo>MyDefault</Foo> b) You conditinoally set them when not set to the default after the user had a chance to set them: <Foo Conditoin="'$(Foo) == ''" />

For msbuild all files are the same and extensions don't matter. It is just a convention of .props for property groups and .targets for targets. ItemGroups, ItemDefinitionGroups etc all fall in between as they don't have a real file...

If you want to use public vs private fields. The convention has become as pioneerd by the cpp team to previs the name of the properties, items, targets with an undescore.

So my inference when looking at the code was If we use style 'b' for the defaults, then they might as well be in the targets. Else we should probably switch to style 'a' and place the .props import at the top of the file.