[wasm] Fix Publish for Blazorwasm projects on VS17

[radical]

TL;dr publish fails on any blazorwasm project with VS17

A recent commit[1] moved initializing $(_WasmIntermediateOutputPath) from
a target, to project level PropertyGroup. It is set as:

<_WasmIntermediateOutputPath>$([MSBuild]::NormalizeDirectory($(IntermediateOutputPath), 'wasm'))</_WasmIntermediateOutputPath>

The NormalizeDirectory call converts this to a full path, presumably
using the current directory.

Because we are setting $(_WasmIntermediateOutputPath) at the project
level, it gets evaluated during the evaluation phase. And the current
directory doesn't seem to be set to the project directory at that point
in VS. So, $(_WasmIntermediateOutputPath) gets a wrong path like:

C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\obj\Release\net6.0\wasm.

And then when actually publishing, it fails to create this directory
with:

Unable to create directory "C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\obj\Release\net6.0\wasm\". Access to the path 'C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\obj\Release\net6.0\wasm\' is denied.

Fix:
Set the property in _InitializeCommonProperties target, at which
point the current directory is correctly set.

Note:

• This doesn't seem to be reproducible outside VS
• It happens only on publish, because that's when the wasm targets
  come into play.

--
1.

commit d574b032793ae752387d32b97ff9840de17420a2
Author: Ankit Jain <radical@gmail.com>
Date:   Mon Jul 19 01:02:01 2021 -0400

    [wasm] Add support for using custom native libraries (#55797)

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

TL;dr publish fails on any blazorwasm project with VS17

A recent commit[1] moved initializing $(_WasmIntermediateOutputPath) from
a target, to project level PropertyGroup. It is set as:

<_WasmIntermediateOutputPath>$([MSBuild]::NormalizeDirectory($(IntermediateOutputPath), 'wasm'))</_WasmIntermediateOutputPath>

The NormalizeDirectory call converts this to a full path, presumably
using the current directory.

Because we are setting $(_WasmIntermediateOutputPath) at the project
level, it gets evaluated during the evaluation phase. And the current
directory doesn't seem to be set to the project directory at that point
in VS. So, $(_WasmIntermediateOutputPath) gets a wrong path like:

C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\obj\Release\net6.0\wasm.

And then when actually publishing, it fails to create this directory
with:

Unable to create directory "C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\obj\Release\net6.0\wasm\". Access to the path 'C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\obj\Release\net6.0\wasm\' is denied.

Fix:
Set the property in _InitializeCommonProperties target, at which
point the current directory is correctly set.

Note:

• This doesn't seem to be reproducible outside VS
• It happens only on publish, because that's when the wasm targets
  come into play.

--
1.

commit d574b032793ae752387d32b97ff9840de17420a2
Author: Ankit Jain <radical@gmail.com>
Date:   Mon Jul 19 01:02:01 2021 -0400

    [wasm] Add support for using custom native libraries (#55797)

Author:	radical
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[radical]

This applies for preview7 too.

cc @pranavkm @danroth27

[radical]

/backport to release/6.0-preview7

[github-actions]

Started backporting to release/6.0-preview7: https://github.com/dotnet/runtime/actions/runs/1072672302

[radical]

This was already approved, and merged in preview7. Merging this.