Stop using MSBuildProjectExtensionsPath in dotnet-watch and user-secrets #347
Conversation
| "/t:" + TargetName, | ||
| "/p:DotNetWatchBuild=true", // extensibility point for users | ||
| "/p:DesignTimeBuild=true", // don't do expensive things | ||
| "/p:CustomAfterMicrosoftCommonTargets=" + watchTargetsFile, |
There was a problem hiding this comment.
You can't specify multiple targets to include in this property, can you? This prevents projects from using this extensibility point.
There was a problem hiding this comment.
Yes, this would override the project's setting. From what I've seen, this property is rarely used, much less than BaseIntermediateOutputPath. Even when used, it seems unlikely to change the list of files in Compile/EmbeddedResource/ProjectReference.
Another option is to write the targets file to MSBuildUserExtensionsPath, though, I have reservations about adding files to machine state, and this wouldn't work across major version changes in MSBuild.
There was a problem hiding this comment.
Sounds good. I just wanted to make sure you considered the tradeoffs.
There was a problem hiding this comment.
Btw, before I merge this, are you aware of any other extensibility points I should consider? These are the ones I've looked at:
- MSBuildProjectExtensionsPath
- MSBuildUserExtensionsPath
- CustomAfterMicrosoftCommonTargets
- CustomBeforeMicrosoftCommonTargets
- $(MSBuildProjectFullPath).user
There was a problem hiding this comment.
haha. Going with CustomAfterMicrosoftCommonTargets for now.
Use CustomAfterMicrosoftCommonTargets instead of MSBuildProjectExtensionsPath. - No more need to write to obj/$(Project).g.dotnetwatch.targets - Works on project that have changed default file locations via BaseIntermediateOutputPath Simplify DotNetWatch targets - Condense to one targets file - Simplify dependency chain of targets - Build project references in a parallel
Resolves #244
Use CustomAfterMicrosoftCommonTargets instead of MSBuildProjectExtensionsPath.
Simplify DotNetWatch targets