[release/3.1] Unescape PresentationBuildTasks.dll paths containing special characters #2487
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
requested a review
from 
rladuca
approved these changes
Jan 30, 2020
|
/cc @richaverma1 |
rainersigwald
approved these changes
Jan 31, 2020
|
Wait for branch to open before merging. |
vatsan-madhavan
added
the
* NO MERGE *
When the SDK is installed in a path containing special characters, for e.g., under `C:\Program Files (x86)\dotnet` (the special characters here being `{'(', ')'}`), calling an MSBuild property function like `$([System.IO.Path]::GetFullPath())` on `$(MSBuildThisFileDirectory)` will result in MSBuild escaping any special characters that are returned.
Now, this is what the [documentation ](https://docs.microsoft.com/en-us/visualstudio/msbuild/property-functions?view=vs-2019)says about using property functions:
>String values returned from property functions have[ special characters](https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-special-characters?view=vs-2019) escaped. If you want the value to be treated as though it was put directly in the project file, use `$([MSBuild]::Unescape())` to unescape the special characters.
>...
>In static property functions, you can use any static method or property of these system classes:
> ```
> System.Byte
>...
> System.IO.Path
>...
> Microsoft.Build.Utilities.ToolLocationHelper
> ```
When such an escaping happens, characters like `(` get translated to`%26` etc. When `UsingTask` encounters a value of `$(PresentationBuildTasksAssembly)` containing encoded characters, it fails.
We must unescape these characters by calling `$([MSBuild]::Unescape())` to ensure that `UsingTask` will not fail.
vatsan-madhavan
force-pushed
the
windowsdesktop-tasks-complexpath-fixup
branch
from
fe2f46e to
9b2d40d
Compare
vatsan-madhavan
added
auto_merge
|
Hello @vatsan-madhavan! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
The branch is open for 3.1.3 and branding updates are merged (#2572). Removing NO MERGE and scheduling for auto-merge. |
|
Uninstall the x86-SDK of NETCore 3.1 on Windows x64. |
ghost
locked as resolved and limited conversation to collaborators
This pull request was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2415
Description
.NET Core 3.1 SDK installed in paths containing special characters like
'(fails to build WPF projects. This affects the default WOW64 installation - i.e., x86 MSI installation on x64 system, that typically installs under%SystemDrive%\Program Files (x86)\dotnetThe builds fail with the following error:
When the SDK is installed in a path containing special characters, for e.g., under
C:\Program Files (x86)\dotnet(the special characters here being{'(', ')'}), calling an MSBuild property function like$([System.IO.Path]::GetFullPath())on$(MSBuildThisFileDirectory)will result in MSBuild escaping any special characters that are returned.Now, this is what the documentation says about using property functions:
When such an escaping happens, characters like
(get translated to%28etc. WhenUsingTaskencounters a value of$(_PresentationBuildTasksAssembly)containing encoded characters, it fails.We must unescape these characters by calling
$([MSBuild]::Unescape())to ensure thatUsingTaskwill not fail.Customer Impact
Developers who install x86 SDK on x64 OS are not able to build WPF apps using 3.1.x SDK.
Regression
This was a regression introduced by #2075, [release/3.1] Use correct PresentationBuildTasks.dll for VS and MSBuild builds.
We did not catch this during development and testing early on since testing was done using SDK's installed under
%appdata%,%temp%etc., which typically didn't have special characters that are escaped by MSBuild.We are still trying to understand how we failed to catch this in end-to-end testing. The current theory is that the x86 SDK was likely tested directly on an x86 OS installation where this problem would not have manifested itself (since the default install location would have been
%SystemDrive%\Program Files, and would not have involved WOW64).We are taking steps to ensure that this scenario is covered in testing.
Risk
Low.