Skip to content
This repository has been archived by the owner on Nov 20, 2018. It is now read-only.

Stop using MSBuildProjectExtensionsPath in dotnet-watch and user-secrets #347

Merged
merged 2 commits into from Sep 26, 2017
Merged

Stop using MSBuildProjectExtensionsPath in dotnet-watch and user-secrets #347

merged 2 commits into from Sep 26, 2017

Conversation

natemcmaster
Copy link
Contributor

Resolves #244

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

"/t:" + TargetName,
"/p:DotNetWatchBuild=true", // extensibility point for users
"/p:DesignTimeBuild=true", // don't do expensive things
"/p:CustomAfterMicrosoftCommonTargets=" + watchTargetsFile,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't specify multiple targets to include in this property, can you? This prevents projects from using this extensibility point.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. I just wanted to make sure you considered the tradeoffs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@bricelam bricelam Sep 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Directory.Build.targets :trollface:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

haha. Going with CustomAfterMicrosoftCommonTargets for now.

Nate McMaster added 2 commits September 26, 2017 11:59
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
@natemcmaster natemcmaster merged commit f3bb408 into aspnet:dev Sep 26, 2017
@natemcmaster natemcmaster deleted the proj-eval branch September 26, 2017 19:03
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants