Tags: ebraminio/runtime
Tags
[release/6.0-rc1] [debugger] Avoid calling debugger_agent_single_step… …_from_context when thread is not attached yet (dotnet#58480) * Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1383962 * Fix { Co-authored-by: Thays <[email protected]>
[wasm] Fix Publish for Blazorwasm projects on VS17 (dotnet#56433) 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 d574b03 Author: Ankit Jain <[email protected]> Date: Mon Jul 19 01:02:01 2021 -0400 [wasm] Add support for using custom native libraries (dotnet#55797) ``` Co-authored-by: Ankit Jain <[email protected]>
Backport dotnet#55040 to preview6 (dotnet#55091) If we don't, then the aot packs will be imported on Windows when running an iOS offline build Fixes dotnet#54944
[release/6.0-preview5] [build] Define NO_UNALIGNED_ACCESS for 32-bit … …arm platforms (dotnet#52942) Co-authored-by: Aleksey Kliger <[email protected]>
PreviousNext