Add hook for importing .props file after .NET SDK props

[dsplaisted]

Add a hook for a .props import after the .NET SDK props, which is useful for modifying the default item globs.

[Sergio0694]

Seems like this would also cover part of ##1696? The "after SDK .targets" part I mean.

[dsplaisted]

Seems like this would also cover part of ##1696? The "after SDK .targets" part I mean.

Thanks for pointing that out, this does address part of that request.

FYI @jeffkl @baronfel

Also, any preference on the property naming? I went with AfterMicrosoftNetSdkProps here, while the issue linked suggests CustomAfterMicrosoftNETSdkProps.

[Sergio0694]

My two thoughts on naming, we should use "AfterMicrosoftNETSdkProps", for three reasons:

• It's consistent with "BeforeMicrosoftNETSdkTargets" and "AfterMicrosoftNETSdkTargets" which already exist
• Like those other two, these specifically refer to the .NET SDK .props/.targets, not the MSBuild ones, like eg. "CustomBeforeMicrosoftCommonProps" does. Not using "Custom" makes it easy to tell the two groups apart.
• There is also a functional difference between all "Custom" ones and these .NET SDK ones. The "Custom" ones are imported behind an Exists(...) check, meaning they do not support appending. Instead you must store the original value, overwrite it, then manually import the original value from your custom .props/.targets, if there was one. Whereas with these .NET SDK ones, you can just append your .props/.targets to the property, since all items are imported at once. Leaving the "Custom" prefix just for the MSBuild ones with this legacy behavior would also further make it easier to tell them apart.

[jeffkl]

I personally don't have a strong opinion one way or the other. My preference in general is to use the Custom prefix just out of habit. But honestly in this case, just having the functionality and it be documented is good enough for me, the naming is probably fine as-is.

[jeffkl]

Is there a good place to document this extensibility point?

[jeffkl]

Suggested change

	<!-- Hook for importing custom logic after .NET SDK props, for example for additional default item processing -->
	<!--
	Extensibility point for users to import build logic after all of the .NET SDKs .props are imported but before the project's contents are evaluated.
	This can be useful for overriding default globs or properties that the SDK sets.
	-->

[Sergio0694]

"Is there a good place to document this extensibility point?"

+1 to this. I could not find any existing docs clearly documenting all existing MSBuild/.NET SDK hooks 😅

[dsplaisted]

FYI @baronfel @marcpopMSFT, I added the consider-for-documentation tag

[dsplaisted]

/azp run dotnet-sdk-public-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Sergio0694]

@dsplaisted I tested this with the internal VS preview with the UWP SDK changes, works great! 🙂

[dsplaisted]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dsplaisted]

/azp run dotnet-sdk-public-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[marcpopMSFT]

@dsplaisted is this ready to go? Failures just look like known timeouts.