Log an error if MSBuildProjectExtensionsPath is modified after it is used #3059

jeffkl · 2018-03-07T17:00:21Z

If MSBuildProjectExtensionsPath is set in a project like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <MSBuildProjectExtensionsPath>$(MSBuildThisFileDirectory)</MSBuildProjectExtensionsPath>
  </PropertyGroup>
</Project>

The value used by the top implicit import is different then the value used by the bottom implicit import. Since the MSBuildProjectExtensionsPath contains imports generated by NuGet, this behavior can cause some obscure build errors.

This change stores the value used by Microsoft.Common.props and logs an error if it changed later on.

The error message is not localized, should I make this a task? Or log it as an error in the evaluator?

…used

AndyGerlicher · 2018-03-07T17:28:38Z

src/Tasks/Microsoft.Common.CurrentVersion.targets

+    -->
+    <Error Condition=" '$(_InitialMSBuildProjectExtensionsPath)' != '' And '$(MSBuildProjectExtensionsPath)' != '$(_InitialMSBuildProjectExtensionsPath)' "
+           Code="MSB3540"
+           Text="The value of the property &quot;MSBuildProjectExtensionsPath&quot; was modified after it was used by MSBuild which can lead to unexpected build results.  To set this property, you must do so before Microsoft.Common.props is imported, for example by using Directory.Build.props."


Change looks good, but the error message might be hard to be actionable. Do we have a docs page with Directory.Build.props explained where we could send people?

I agree, we thought about making a whole page for this but we could also do an aka.ms link to https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-example

Thoughts?

I'd say make a page for the new MSB3540.

@Mikejo5000 do you have thoughts? We're introducing a new error to catch a subtle user error, and we'd like to direct anyone who encounters it to an explanation of the right way to do things. The options proposed so far are: just be terse and rely on search to find the fix, fwlink to a semi-general "how to extend your build" page, and fwlink to a new docs page that describes the error and its fix and cross-links to the general page.

We may add a warning in NuGet (see PR NuGet/NuGet.Client#2056) that should probably link to the same thing. So it wouldn't necessarily be just for MSB3540.

Current proposed text of the NuGet warning:

The BaseIntermediateOutputPath ('{0}') did not match the MSBuildProjectExtensionsPath ('{1}'), which is where the Restore output will go. If you want the Restore output to go to the BaseIntermediateOutputPath, you must set this property before the common .props are imported (for example, in a Directory.Build.props file).

`

@rainersigwald I think making an error page is probably the best choice. Historically, these pages don't get rated very high, but that's often because multiple scenarios can cause the error and multiple possible fixes are involved. The scenario/fix sounds pretty well-known here, so you likely won't have that issue.

rainersigwald · 2018-03-07T18:56:37Z

src/Tasks/Microsoft.Common.props

+    <!--
+      Save the value of MSBuildProjectExtensionsPath to verify during a build that it was not changed in the body of a project.  In an SDK style project
+      if you set a value in the body, the value is not used by the top implicit import but is used by the bottom.  This can lead to non-deterministic behavior
+      and builds can fail for obscure reasons.


I vote put the comment in only one place since it's wordy and almost duplicated.

dsplaisted · 2018-03-08T08:42:39Z

Here's what we decided: MSBuild will add a warning to cover the case where BaseIntermediateOutputPath doesn't match the MSBuildProjectExtensionsPath. It will try to only warn if it looks like this was unintentional (ie the MSBuildProjectExtensionsPath has its default value and BaseIntermediateOutputPath had its default value in the common props but not when the target is run. It will also only generate the warning if the ValidateBaseIntermediateOutputPathMatchesProjectExtensionsPath property (actual name TBD) is set to true. NuGet will set this property to true if it's not already set and the RestoreProjectStyle is PackageReference.

Here's my stab at a warning message:

The BaseIntermediateOutputPath ('{0}') did not match the MSBuildProjectExtensionsPath ('{1}'). Tools such as NuGet will write output to the MSBuildProjectExtensionsPath. If you want the output to go to the BaseIntermediateOutputPath, you must set this property before Microsoft.Common.props is imported (for example, in a Directory.Build.props file). See [link] for more info.

Add fwlink

jeffkl · 2018-03-13T18:26:36Z

@AndyGerlicher @rainersigwald @cdmihai @dsplaisted this is ready for review

rainersigwald · 2018-03-13T19:04:03Z

src/Tasks/Resources/Strings.resx

@@ -2681,7 +2681,7 @@
            MSB3501 - MSB3510   Task: ReadLinesFromFile
            MSB3511 - MSB3520   Task: Message
            MSB3521 - MSB3530   Task: Warning
-            MSB3531 - MSB3540   Task: Error
+            MSB3531 - MSB3540   Task: Error    // MSB3539, MSB3540 is used in Microsoft.Common.CurrentVersion.targets, do no reuse


typo: do not reuse

rainersigwald · 2018-03-13T19:04:32Z

src/Tasks/Microsoft.Common.CurrentVersion.targets

+    <!--
+      Log an error if the user set MSBuildProjectExtensionsPath in the body of a project. In an SDK style project
+      if you set a value in the body, the value is not used by the top implicit import but is used by the bottom.
+      This can lead to non-deterministic behavior and builds can fail for obscure reasons.


pedantry: it's not nondeterministic, just confusing.

rainersigwald · 2018-03-13T19:05:09Z

src/Tasks/Microsoft.Common.CurrentVersion.targets

+        2. $(BaseIntermediateOutputPath) was set in the body of a project after its default value was set in Microsoft.Common.props
+        3. $(BaseIntermediateOutputPath) is not the same as $(MSBuildProjectExtensionsPath)
+
+      Similar to the error above, there are cases when users set $(BaseIntermediateOutputPath) in the body of their project and things build but only by coincedence.


typo: coincidence

jeffkl · 2018-03-13T21:42:31Z

@dotnet-bot test OSX10.13 Build for CoreCLR please

dsplaisted

Can we add any test coverage for this?

dsplaisted · 2018-03-13T22:53:01Z

src/Tasks/Microsoft.Common.CurrentVersion.targets

+    -->
+    <Error Condition=" '$(_InitialMSBuildProjectExtensionsPath)' != '' And '$(MSBuildProjectExtensionsPath)' != '$(_InitialMSBuildProjectExtensionsPath)' "
+           Code="MSB3540"
+           Text="The value of the property &quot;MSBuildProjectExtensionsPath&quot; was modified after it was used by MSBuild which can lead to unexpected build results.  To set this property, you must do so before Microsoft.Common.props is imported, for example by using Directory.Build.props.  For more information, please visit https://go.microsoft.com/fwlink/?linkid=869650"


Consider using an aka.ms link instead of a fwlink. That way you can choose a URL that's more type-able and remember-able.

dsplaisted · 2018-03-13T22:55:30Z

src/Tasks/Microsoft.Common.CurrentVersion.targets

+      Log a warning if:
+        1. $(EnableBaseIntermediateOutputPathMismatchWarning) is 'true'
+        2. $(BaseIntermediateOutputPath) was set in the body of a project after its default value was set in Microsoft.Common.props
+        3. $(BaseIntermediateOutputPath) is not the same as $(MSBuildProjectExtensionsPath)


Consider disabling the warning if MSBuildProjectExtensionPath was set when the common .props were evaluated. That might be a case where we can assume that the different values were intentional.

I think you'd get the error that MSBuildProjectExtensionPath was modified anyway right?

The scenario I'm thinking of is that you set MSBuildExtensionsPath in Directory.Build.props, but you set BaseIntermediateOutputPath to a different value in the body of your project. Perhaps that's too convoluted to care about, but I think we can infer in that situation that you intended for the paths to be different.

dsplaisted · 2018-03-13T23:00:46Z

src/Tasks/Microsoft.Common.CurrentVersion.targets

+    -->
+    <Warning Condition=" '$(EnableBaseIntermediateOutputPathMismatchWarning)' == 'true' And '$(_InitialBaseIntermediateOutputPath)' != '$(BaseIntermediateOutputPath)' And '$(BaseIntermediateOutputPath)' != '$(MSBuildProjectExtensionsPath)' "
+             Code="MSB3539"
+             Text="The value of the property &quot;BaseIntermediateOutputPath&quot; was modified after it was used by MSBuild which can lead to unexpected build results. Tools such as NuGet will write outputs to the path specified by the &quot;MSBuildProjectExtensionsPath&quot; instead. To set this property, you must do so before Microsoft.Common.props is imported, for example by using Directory.Build.props.  For more information, please visit https://go.microsoft.com/fwlink/?linkid=869650"


I'd try rewording this message. The only unexpected build results that I think we're aware of (once we get these changes in) is that output might be written to a path you don't expect. So I'd avoid being unnecessarily vague.

I'd suggest something like this:

The BaseIntermediateOutputPath ('{0}') did not match the MSBuildProjectExtensionsPath ('{1}'). Tools such as NuGet will write output to the MSBuildProjectExtensionsPath. If you want the output to go to the BaseIntermediateOutputPath, you must set this property before Microsoft.Common.props is imported (for example, in a Directory.Build.props file). See [link] for more info.

I'd also suggest using an aka.ms link here (the same one as above).

jeffkl · 2018-03-19T16:40:38Z

Can we add any test coverage for this?

Done

jeffkl · 2018-03-19T17:48:29Z

@dotnet-bot
test OSX10.13 Build for CoreCLR please
test Ubuntu16.04 Build for CoreCLR please

Log an error if MSBuildProjectExtensionsPath is modified after it is …

2c1e4ea

…used

jeffkl requested a review from dsplaisted March 7, 2018 17:00

AndyGerlicher reviewed Mar 7, 2018

View reviewed changes

jeffkl mentioned this pull request Mar 7, 2018

Use MSBuildProjectExtensionsPath for RestoreOutputPath NuGet/NuGet.Client#2056

Closed

rainersigwald reviewed Mar 7, 2018

View reviewed changes

jeffkl mentioned this pull request Mar 13, 2018

NuGet package build logic ignored under some obj customizations #2245

Open

Add warning for BaseIntermediateOutputPath changing

7397e1b

Add fwlink

AndyGerlicher approved these changes Mar 13, 2018

View reviewed changes

rainersigwald approved these changes Mar 13, 2018

View reviewed changes

Address comments

5b8e22f

dsplaisted approved these changes Mar 13, 2018

View reviewed changes

dsplaisted mentioned this pull request Mar 14, 2018

Issue error or warning if BaseIntermediateOutputPath is modified after it's used to calculate MSBuildProjectExtensionsPath dotnet/sdk#803

Closed

jeffkl added 3 commits March 19, 2018 08:57

Add ErrorIfChangedInBodyOfProject test

835980b

Unit test for BaseIntermediateOutputPath

ef58539

Migrate other test cases to Shouldly

4b5f6c3

AndyGerlicher approved these changes Mar 19, 2018

View reviewed changes

jeffkl mentioned this pull request Mar 19, 2018

Use a task in _CheckForInvalidConfigurationAndPlatform #3105

Closed

jeffkl merged commit f72bd2e into dotnet:master Mar 19, 2018

jeffkl deleted the msbuildprojectextensionspath branch March 19, 2018 21:41

dsplaisted mentioned this pull request Mar 24, 2018

Use MSBuildProjectExtensionsPath for RestoreOutputPath NuGet/NuGet.Client#2121

Closed

rohit21agrawal mentioned this pull request Mar 30, 2018

Use MSBuildProjectExtensionsPath for RestoreOutputPath NuGet/NuGet.Client#2131

Merged

wli3 mentioned this pull request Apr 23, 2018

do not set BaseIntermediateOutputPath in temp project of dotnet install to 2.1.4xx dotnet/cli#9122

Merged

dsplaisted mentioned this pull request Jun 18, 2018

Setting BaseIntermediateOutputPath correctly in a SDK-based project is hard #1603

Closed

jeffkl mentioned this pull request Aug 2, 2018

Compat: BaseIntermediateOutputPath might not be respected in some cases #1525

Closed

wli3 mentioned this pull request Jan 31, 2020

do not set BaseIntermediateOutputPath in temp project of dotnet install dotnet/sdk#9309

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Log an error if MSBuildProjectExtensionsPath is modified after it is used #3059

Log an error if MSBuildProjectExtensionsPath is modified after it is used #3059

jeffkl commented Mar 7, 2018

AndyGerlicher Mar 7, 2018

jeffkl Mar 7, 2018

rainersigwald Mar 7, 2018

dsplaisted Mar 7, 2018

Mikejo5000 Mar 7, 2018

rainersigwald Mar 7, 2018

dsplaisted commented Mar 8, 2018

jeffkl commented Mar 13, 2018

rainersigwald Mar 13, 2018

rainersigwald Mar 13, 2018

rainersigwald Mar 13, 2018

jeffkl commented Mar 13, 2018

dsplaisted left a comment

dsplaisted Mar 13, 2018

dsplaisted Mar 13, 2018

jeffkl Mar 15, 2018

dsplaisted Mar 15, 2018

dsplaisted Mar 13, 2018

jeffkl commented Mar 19, 2018

jeffkl commented Mar 19, 2018

Log an error if MSBuildProjectExtensionsPath is modified after it is used #3059

Log an error if MSBuildProjectExtensionsPath is modified after it is used #3059

Conversation

jeffkl commented Mar 7, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dsplaisted commented Mar 8, 2018

jeffkl commented Mar 13, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jeffkl commented Mar 13, 2018

dsplaisted left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jeffkl commented Mar 19, 2018

jeffkl commented Mar 19, 2018