-
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
Permit individually settable search paths #7008
Permit individually settable search paths #7008
Conversation
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.
LGTM. Friendly reminder that we need these properties inserted in our public facing docs (if i recall correctly, that was the location we agreed on?)
To both "known MSBuild properties" and our repo-level docs, but we also decided I should put that off until rainersigwald has had a chance to review it, and it's been merged. |
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.
Can you follow this up with an equivalent change in the .NET SDK, which overrides our defaults? https://github.com/dotnet/sdk/blob/5899560935260ff35a9ca601c91c75afbaed1f1d/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.props#L91
It looks cleaner as-is than if I were to change it to use the new properties in this PR to me. If I did, I'd have to set several properties instead of just one. Also, it currently sets DesignTimeAssemblySearchPaths (if it's nonempty) to |
What I'm asking for is to respect these new properties in the .NET SDK as well. Otherwise we'll be in a position where we say "you can set
Divergence of DesignTimeAssemblySearchPaths from AssemblySearchPaths worries me. |
Oh, makes sense.
Do you think setting DesignTimeAssemblySearchPaths where I pointed to is too much of a breaking change? It feels pretty small to me, but I really don't know. The only way I can think of to fully avoid any change in behavior is if the SDK checks for all the new properties and sets AssemblySearchPaths then DesignTimeAssemblySearchPaths appropriately, but that's a bit messy. |
<AssemblySearchPaths Condition="$(AssemblySearchPathUseCandidateAssemblyFiles) != 'false'">{CandidateAssemblyFiles}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseReferencePath) != 'false'">$(AssemblySearchPaths);$(ReferencePath)</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseHintPathFromItem) != 'false'">$(AssemblySearchPaths);{HintPathFromItem}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseTargetFrameworkDirectory) != 'false'">$(AssemblySearchPaths);{TargetFrameworkDirectory}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseAssemblyFoldersConfigFileSearchPath) != 'false'">$(AssemblySearchPaths);$(AssemblyFoldersConfigFileSearchPath)</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseRegistry) != 'false'">$(AssemblySearchPaths);{Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseAssemblyFolders) != 'false'">$(AssemblySearchPaths);{AssemblyFolders}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseGAC) != 'false'">$(AssemblySearchPaths);{GAC}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseRawFileName) != 'false'">$(AssemblySearchPaths);{RawFileName}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseOutDir) != 'false'">$(AssemblySearchPaths);$(OutDir)</AssemblySearchPaths> |
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.
Can you please also add these to the XSD?
Related: #772 |
<AssemblySearchPaths Condition="$(AssemblySearchPathUseAssemblyFolders) != 'false'">$(AssemblySearchPaths);{AssemblyFolders}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseGAC) != 'false'">$(AssemblySearchPaths);{GAC}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseRawFileName) != 'false'">$(AssemblySearchPaths);{RawFileName}</AssemblySearchPaths> | ||
<AssemblySearchPaths Condition="$(AssemblySearchPathUseOutDir) != 'false'">$(AssemblySearchPaths);$(OutDir)</AssemblySearchPaths> |
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.
Sorry for the late review but...
<AssemblySearchPaths Condition="$(AssemblySearchPathUseOutDir) != 'false'">$(AssemblySearchPaths);$(OutDir)</AssemblySearchPaths> | |
<AssemblySearchPaths Condition="'$(AssemblySearchPath_UseOutDir)' != 'false'">$(AssemblySearchPaths);$(OutDir)</AssemblySearchPaths> |
CHANGES
- Use quotes to avoid erroring out with a malformed value (with space and illegal symbols) entering the condition.
- Wouldn't it better to use
BaseProperty_SubOption
with an_
acting as a separator to make these properties clearer?
See that we already use this pattern of naming here...
msbuild/src/Tasks/Microsoft.Common.props
Line 181 in 14313d1
<DisableLogTaskParameter_ConvertToAbsolutePath_Path>true</DisableLogTaskParameter_ConvertToAbsolutePath_Path> |
It does but I linked the issue here via the comment above. |
Follow-ups from Permit individually settable search paths #7008 (review) Respect opt-outs from #7008 sdk#22719 (comment) Context For multi-level properties, follow the naming pattern similar to BaseProperty_SubOption with an _ underscore character acting as a separator to make these properties clearer. We already follow this pattern in Common props where we have DisableLogTaskParameter_ConvertToAbsolutePath_Pathand friends. msbuild/src/Tasks/Microsoft.Common.props Lines 181 to 183 in 14313d1 <DisableLogTaskParameter_ConvertToAbsolutePath_Path>true</DisableLogTaskParameter_ConvertToAbsolutePath_Path> <DisableLogTaskParameter_FindUnderPath_OutOfPath>true</DisableLogTaskParameter_FindUnderPath_OutOfPath> <DisableLogTaskParameter_RemoveDuplicates_Inputs>true</DisableLogTaskParameter_RemoveDuplicates_Inputs> Changes Made So, Use AssemblySearchPath_Use{Variant} property format to control individual inclusion of different variants of assembly search paths. By default, these properties will be opt-out to maintain back-compat. Notes This change hasn't been shipped yet. So, it's technically not breaking and it's also not too late to change it.
Respect opt-outs from dotnet/msbuild#7008
Fixes #3784
Context
AssemblySearchPaths are currently set using a property (not an item because order often matters) in which either the user sets all of them or the user accepts the default. This allows the user to accept some or most of the default without accepting all of it.
It may also be reasonable to add:
though that would only allow users to add custom paths at the predefined spot, so it may not be too helpful. I'm also unsure if it would be most likely to be used if it's first, last, or just before OutDir.