Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upStop 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, |
bricelam
Sep 25, 2017
You can't specify multiple targets to include in this property, can you? This prevents projects from using this extensibility point.
You can't specify multiple targets to include in this property, can you? This prevents projects from using this extensibility point.
natemcmaster
Sep 26, 2017
Author
Contributor
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.
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.
bricelam
Sep 26, 2017
Sounds good. I just wanted to make sure you considered the tradeoffs.
Sounds good. I just wanted to make sure you considered the tradeoffs.
natemcmaster
Sep 26, 2017
Author
Contributor
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
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
bricelam
Sep 26, 2017
•
Directory.Build.targets 
Directory.Build.targets
natemcmaster
Sep 26, 2017
Author
Contributor
haha. Going with CustomAfterMicrosoftCommonTargets for now.
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