-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log an error if MSBuildProjectExtensionsPath is modified after it is used #3059
Changes from 1 commit
2c1e4ea
7397e1b
5b8e22f
835980b
ef58539
4b5f6c3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -766,6 +766,16 @@ Copyright (C) Microsoft Corporation. All rights reserved. | |
<PropertyGroup Condition="'$(Prefer32Bit)' == 'true' and ('$(PlatformTarget)' == 'AnyCPU' or '$(PlatformTarget)' == '') and '$(PlatformTargetAsMSBuildArchitectureExplicitlySet)' != 'true'"> | ||
<PlatformTargetAsMSBuildArchitecture>x86</PlatformTargetAsMSBuildArchitecture> | ||
</PropertyGroup> | ||
|
||
<!-- | ||
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. | ||
--> | ||
<Error Condition=" '$(_InitialMSBuildProjectExtensionsPath)' != '' And '$(MSBuildProjectExtensionsPath)' != '$(_InitialMSBuildProjectExtensionsPath)' " | ||
Code="MSB3540" | ||
Text="The value of the property "MSBuildProjectExtensionsPath" 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." | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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:
` There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @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. |
||
/> | ||
</Target> | ||
|
||
<!-- | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -58,6 +58,13 @@ Copyright (C) Microsoft Corporation. All rights reserved. | |
<MSBuildProjectExtensionsPath Condition="'$([System.IO.Path]::IsPathRooted($(MSBuildProjectExtensionsPath)))' == 'false'">$([System.IO.Path]::Combine('$(MSBuildProjectDirectory)', '$(MSBuildProjectExtensionsPath)'))</MSBuildProjectExtensionsPath> | ||
<MSBuildProjectExtensionsPath Condition="!HasTrailingSlash('$(MSBuildProjectExtensionsPath)')">$(MSBuildProjectExtensionsPath)\</MSBuildProjectExtensionsPath> | ||
<ImportProjectExtensionProps Condition="'$(ImportProjectExtensionProps)' == ''">true</ImportProjectExtensionProps> | ||
|
||
<!-- | ||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I vote put the comment in only one place since it's wordy and almost duplicated. |
||
--> | ||
<_InitialMSBuildProjectExtensionsPath Condition=" '$(ImportProjectExtensionProps)' == 'true' ">$(MSBuildProjectExtensionsPath)</_InitialMSBuildProjectExtensionsPath> | ||
</PropertyGroup> | ||
|
||
<Import Project="$(MSBuildProjectExtensionsPath)$(MSBuildProjectFile).*.props" Condition="'$(ImportProjectExtensionProps)' == 'true' and exists('$(MSBuildProjectExtensionsPath)')" /> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pedantry: it's not nondeterministic, just confusing.