Skip to content
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

[release/6.0][wasm] Partially fix issue caused during VS upgrade #79572

Merged
merged 3 commits into from
Jan 13, 2023

Conversation

radical
Copy link
Member

@radical radical commented Dec 12, 2022

Issue:

TL;dr After some VS upgrades, or possibly messed up workload installs users get the above exception when trying to build their projects. But this error is a side effect of the real issue of msbuild failing to load a workload pack. This fix allows the real error to get surfaced to the user.

Upgrading from VS 17.3.6 to 17.4.2 caused wasm project builds to break with:

Unhandled exception: Microsoft.Build.Exceptions.InvalidProjectFileException: The result “” of evaluating the value “$(JsonToItemsTaskFactoryTasksAssemblyPath)” of the “AssemblyFile” attribute in element is not valid. C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.WebAssembly.Sdk\6.0.11\Sdk\WasmApp.Native.targets

at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args) at Microsoft.Build.Shared.ProjectErrorUtilities.VerifyThrowInvalidProject[T1,T2,T3,T4](Boolean condition, String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, T1 arg0, T2 arg1, T3 arg2, T4 arg3) at Microsoft.Build.Shared.ProjectErrorUtilities.VerifyThrowInvalidProject[T1,T2,T3,T4](Boolean condition, IElementLocation elementLocation, String resourceName, T1 arg0, T2 arg1, T3 arg2, T4 arg3) at Microsoft.Build.Execution.TaskRegistry.RegisterTasksFromUsingTaskElement[P,I](ILoggingService loggingService, BuildEventContext buildEventContext, String directoryOfImportingFile, ProjectUsingTaskElement projectUsingTaskXml, TaskRegistry taskRegistry, Expander`2 expander, ExpanderOptions expanderOptions, IFileSystem fileSystem) at Microsoft.Build.Evaluation.Evaluator`4.EvaluateUsingTaskElement(String directoryOfImportingFile, ProjectUsingTaskElement projectUsingTaskElement) at Microsoft.Build.Evaluation.Evaluator`4.Evaluate() at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, Project project, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive) at Microsoft.Build.Execution.ProjectInstance.Initialize(ProjectRootElement xml, IDictionary`2 globalProperties, String explicitToolsVersion, String explicitSubToolsetVersion, Int32 visualStudioVersionFromSolution, BuildParameters buildParameters, ILoggingService loggingService, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, Nullable`1 projectLoadSettings, EvaluationContext evaluationContext) at Microsoft.Build.Execution.ProjectInstance..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, Nullable`1 projectLoadSettings, EvaluationContext evaluationContext) at Microsoft.Build.Execution.ProjectInstance..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion) at Microsoft.DotNet.Workloads.Workload.Restore.WorkloadRestoreCommand.RunTargetToGetWorkloadIds(IEnumerable`1 allProjects) at Microsoft.DotNet.Workloads.Workload.Restore.WorkloadRestoreCommand.Execute() at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.d.MoveNext() — End of stack trace from previous location — at Microsoft.DotNet.Cli.Parser.<>c__DisplayClass17_0.d.MoveNext() — End of stack trace from previous location — at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass11_0.d.MoveNext() — End of stack trace from previous location — at System.CommandLine.CommandLineBuilderExtensions.<>c.d.MoveNext() — End of stack trace from previous location — at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass15_0.d.MoveNext() — End of stack trace from previous location — at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass7_0.d.MoveNext()

There are two issues here:

  1. The error seen by the user (seen above)
  2. And the real error underneath which is that some workload packs fail to load (possibly because they are missing), but the error gets swallowed by msbuild.

This is explained in dotnet/sdk#21032 (comment) .

For the workload failure, what is going on is that the workload missing
error comes from running a Target, while the failure about the empty
value for AssemblyFile comes from evaluation. So you get the
AssemblyFile failure before it gets a chance to tell you about the
missing workload.

Details:

  • the MonoTargets pack is missing, or doesn't have the correct version, and the SDK cannot be loaded (see (2))

  • And this in turn causes (1) because: - the UsingTask for ReadEmccProps in WebAssembly.Sdk's WasmApp.Native.targets uses AssemblyFile=$(JsonToItemsTaskFactoryTasksAssemblyPath) - and $(JsonToItemsTaskFactoryTasksAssemblyPath) is set in the MonoTargets.Sdk pack - because of the missing pack the above property is unset, causing the UsingTask evaluation to fail.

As a workaround, we move the UsingTask to MonoTargets.Sdk too, which should cause the real error to surface.

Original issue: #78237

Customer Impact

This fix would allow the real error about the missing workload pack to be surfaced to the user, instead of the unhelpful exception message.

Risk

Low. This has been manually tested to check that the change does not break anything. But note that we can't actually reproduce the original user issue.

Upgrading from VS 17.3.6 to 17.4.2 caused wasm project builds to break
with:

```
Unhandled exception: Microsoft.Build.Exceptions.InvalidProjectFileException: The result “” of evaluating the value “$(JsonToItemsTaskFactoryTasksAssemblyPath)” of the “AssemblyFile” attribute in element  is not valid. C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.WebAssembly.Sdk\6.0.11\Sdk\WasmApp.Native.targets
    at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
    at Microsoft.Build.Shared.ProjectErrorUtilities.VerifyThrowInvalidProject[T1,T2,T3,T4](Boolean condition, String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, T1 arg0, T2 arg1, T3 arg2, T4 arg3)
    at Microsoft.Build.Shared.ProjectErrorUtilities.VerifyThrowInvalidProject[T1,T2,T3,T4](Boolean condition, IElementLocation elementLocation, String resourceName, T1 arg0, T2 arg1, T3 arg2, T4 arg3)
    at Microsoft.Build.Execution.TaskRegistry.RegisterTasksFromUsingTaskElement[P,I](ILoggingService loggingService, BuildEventContext buildEventContext, String directoryOfImportingFile, ProjectUsingTaskElement projectUsingTaskXml, TaskRegistry taskRegistry, Expander`2 expander, ExpanderOptions expanderOptions, IFileSystem fileSystem) at Microsoft.Build.Evaluation.Evaluator`4.EvaluateUsingTaskElement(String directoryOfImportingFile, ProjectUsingTaskElement projectUsingTaskElement)
    at Microsoft.Build.Evaluation.Evaluator`4.Evaluate() at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, Project project, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive) at Microsoft.Build.Execution.ProjectInstance.Initialize(ProjectRootElement xml, IDictionary`2 globalProperties, String explicitToolsVersion, String explicitSubToolsetVersion, Int32 visualStudioVersionFromSolution, BuildParameters buildParameters, ILoggingService loggingService, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, Nullable`1 projectLoadSettings, EvaluationContext evaluationContext) at Microsoft.Build.Execution.ProjectInstance..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, Nullable`1 projectLoadSettings, EvaluationContext evaluationContext) at Microsoft.Build.Execution.ProjectInstance..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion)
    at Microsoft.DotNet.Workloads.Workload.Restore.WorkloadRestoreCommand.RunTargetToGetWorkloadIds(IEnumerable`1 allProjects)
    at Microsoft.DotNet.Workloads.Workload.Restore.WorkloadRestoreCommand.Execute()
    at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<b__0>d.MoveNext()
    — End of stack trace from previous location —
    at Microsoft.DotNet.Cli.Parser.<>c__DisplayClass17_0.<b__0>d.MoveNext()
    — End of stack trace from previous location —
    at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass11_0.<b__0>d.MoveNext()
    — End of stack trace from previous location —
    at System.CommandLine.CommandLineBuilderExtensions.<>c.<b__17_0>d.MoveNext()
    — End of stack trace from previous location —
    at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass15_0.<b__0>d.MoveNext()
    — End of stack trace from previous location —
    at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass7_0.<b__0>d.MoveNext()
```

There are two issues here:

1. The error seen by the user (seen above)
2. And the real error underneath which is that some workload packs fail
   to load (possibly because they are missing), but the error gets
   swallowed by msbuild.

This is explained in
dotnet/sdk#21032 (comment) .

```
For the workload failure, what is going on is that the workload missing
error comes from running a Target, while the failure about the empty
value for AssemblyFile comes from evaluation. So you get the
AssemblyFile failure before it gets a chance to tell you about the
missing workload.
```

Details:

- the `MonoTargets` pack is missing, or doesn't have the correct
version, and the SDK cannot be loaded (see (2))

- And this in turn causes (1) because:
    - the `UsingTask` for `ReadEmccProps` in `WebAssembly.Sdk`'s
      `WasmApp.Native.targets` uses
      `AssemblyFile=$(JsonToItemsTaskFactoryTasksAssemblyPath)`
    - and `$(JsonToItemsTaskFactoryTasksAssemblyPath)` is set in the
      `MonoTargets.Sdk` pack
    - because of the missing pack the above property is unset, causing
      the `UsingTask` evaluation to fail.

As a workaround, we move the `UsingTask` to `MonoTargets.Sdk` too, which
should cause the real error to surface.
@ghost ghost assigned radical Dec 12, 2022
@radical radical added the arch-wasm WebAssembly architecture label Dec 12, 2022
@radical radical added this to the 6.0.14 milestone Dec 12, 2022
@ghost
Copy link

ghost commented Dec 12, 2022

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

Issue Details

Upgrading from VS 17.3.6 to 17.4.2 caused wasm project builds to break with:

Unhandled exception: Microsoft.Build.Exceptions.InvalidProjectFileException: The result “” of evaluating the value “$(JsonToItemsTaskFactoryTasksAssemblyPath)” of the “AssemblyFile” attribute in element  is not valid. C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.WebAssembly.Sdk\6.0.11\Sdk\WasmApp.Native.targets
    at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
    at Microsoft.Build.Shared.ProjectErrorUtilities.VerifyThrowInvalidProject[T1,T2,T3,T4](Boolean condition, String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, T1 arg0, T2 arg1, T3 arg2, T4 arg3)
    at Microsoft.Build.Shared.ProjectErrorUtilities.VerifyThrowInvalidProject[T1,T2,T3,T4](Boolean condition, IElementLocation elementLocation, String resourceName, T1 arg0, T2 arg1, T3 arg2, T4 arg3)
    at Microsoft.Build.Execution.TaskRegistry.RegisterTasksFromUsingTaskElement[P,I](ILoggingService loggingService, BuildEventContext buildEventContext, String directoryOfImportingFile, ProjectUsingTaskElement projectUsingTaskXml, TaskRegistry taskRegistry, Expander`2 expander, ExpanderOptions expanderOptions, IFileSystem fileSystem) at Microsoft.Build.Evaluation.Evaluator`4.EvaluateUsingTaskElement(String directoryOfImportingFile, ProjectUsingTaskElement projectUsingTaskElement)
    at Microsoft.Build.Evaluation.Evaluator`4.Evaluate() at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, Project project, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive) at Microsoft.Build.Execution.ProjectInstance.Initialize(ProjectRootElement xml, IDictionary`2 globalProperties, String explicitToolsVersion, String explicitSubToolsetVersion, Int32 visualStudioVersionFromSolution, BuildParameters buildParameters, ILoggingService loggingService, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, Nullable`1 projectLoadSettings, EvaluationContext evaluationContext) at Microsoft.Build.Execution.ProjectInstance..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, Nullable`1 projectLoadSettings, EvaluationContext evaluationContext) at Microsoft.Build.Execution.ProjectInstance..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion)
    at Microsoft.DotNet.Workloads.Workload.Restore.WorkloadRestoreCommand.RunTargetToGetWorkloadIds(IEnumerable`1 allProjects)
    at Microsoft.DotNet.Workloads.Workload.Restore.WorkloadRestoreCommand.Execute()
    at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<b__0>d.MoveNext()
    — End of stack trace from previous location —
    at Microsoft.DotNet.Cli.Parser.<>c__DisplayClass17_0.<b__0>d.MoveNext()
    — End of stack trace from previous location —
    at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass11_0.<b__0>d.MoveNext()
    — End of stack trace from previous location —
    at System.CommandLine.CommandLineBuilderExtensions.<>c.<b__17_0>d.MoveNext()
    — End of stack trace from previous location —
    at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass15_0.<b__0>d.MoveNext()
    — End of stack trace from previous location —
    at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass7_0.<b__0>d.MoveNext()

There are two issues here:

  1. The error seen by the user (seen above)
  2. And the real error underneath which is that some workload packs fail to load (possibly because they are missing), but the error gets swallowed by msbuild.

This is explained in
dotnet/sdk#21032 (comment) .

For the workload failure, what is going on is that the workload missing
error comes from running a Target, while the failure about the empty
value for AssemblyFile comes from evaluation. So you get the
AssemblyFile failure before it gets a chance to tell you about the
missing workload.

Details:

  • the MonoTargets pack is missing, or doesn't have the correct version, and the SDK cannot be loaded (see (2))

  • And this in turn causes (1) because: - the UsingTask for ReadEmccProps in WebAssembly.Sdk's WasmApp.Native.targets uses AssemblyFile=$(JsonToItemsTaskFactoryTasksAssemblyPath) - and $(JsonToItemsTaskFactoryTasksAssemblyPath) is set in the MonoTargets.Sdk pack - because of the missing pack the above property is unset, causing the UsingTask evaluation to fail.

As a workaround, we move the UsingTask to MonoTargets.Sdk too, which should cause the real error to surface.

Original issue: #78237

Author: radical
Assignees: radical
Labels:

arch-wasm, area-Build-mono

Milestone: -

…SDK run doesn't have monotargets props on CI
@radical radical marked this pull request as ready for review December 14, 2022 06:32
@carlossanlop
Copy link
Member

@radical if this is ready, please add the servicing-consider label and send an email to Tactics requesting approval.

@radical
Copy link
Member Author

radical commented Jan 12, 2023

@thaystg is kindly helping to test this.

@thaystg
Copy link
Member

thaystg commented Jan 12, 2023

@thaystg is kindly helping to test this.

I replaced WasmApp.Native.targets in C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.WebAssembly.Sdk\6.0.13\Sdk
And RuntimeComponentManifest.targets in C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.MonoTargets.Sdk\6.0.13\Sdk

I tested:

  • create a new blazor wasm app from vs targetting net6.0
    • build in release/debug
    • run in debug
    • publish
  • create a new blazor wasm app from vs targetting net6.0 and add <RunAOTCompilation>true</RunAOTCompilation> to the csproj
    • build in release/debug
    • publish
  • create a new blazor wasm app from command line dotnet new blazorwasm --framework net6.0:
    • dotnet build
    • dotnet publish
    • dotnet run
  • create a new blazor wasm app from command line dotnet new blazorwasm --framework net6.0 and add <RunAOTCompilation>true</RunAOTCompilation> to the csproj:
    • dotnet build
    • dotnet publish

It's all working fine.

@carlossanlop
Copy link
Member

If this is good to go, please send the email to Tactics and add the servicing-consider label. Tomorrow's the last day to merge backports for the February Release.

@radical radical added the Servicing-consider Issue for next servicing release review label Jan 12, 2023
@carlossanlop carlossanlop added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jan 13, 2023
@carlossanlop
Copy link
Member

Approved by Tactics via email (6.0.14).
Signed off by area owner.
No OOB changes needed (mono/wasm).
CI failure unrelated/already fixed: #78778
Ready to merge. :shipit:

@carlossanlop carlossanlop merged commit a608ec6 into dotnet:release/6.0 Jan 13, 2023
@radical radical deleted the wasm-workaround-6.0 branch January 31, 2023 18:34
@ghost ghost locked as resolved and limited conversation to collaborators Mar 2, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-Build-mono Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants