[release/6.0][wasm] Partially fix issue caused during VS upgrade #79572
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
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
assigned 
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsUpgrading from VS 17.3.6 to 17.4.2 caused wasm project builds to break with: There are two issues here:
This is explained in Details:
As a workaround, we move the Original issue: #78237
|
…SDK run doesn't have monotargets props on CI
|
@radical if this is ready, please add the |
|
@thaystg is kindly helping to test this. |
I replaced I tested:
It's all working fine. |
|
If this is good to go, please send the email to Tactics and add the |
carlossanlop
added
Servicing-approved
lewing
approved these changes
Jan 13, 2023
|
Approved by Tactics via email (6.0.14). |
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.
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.targetsThere are two issues here:
This is explained in dotnet/sdk#21032 (comment) .
Details:
the
MonoTargetspack 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
UsingTaskforReadEmccPropsinWebAssembly.Sdk'sWasmApp.Native.targetsusesAssemblyFile=$(JsonToItemsTaskFactoryTasksAssemblyPath)- and$(JsonToItemsTaskFactoryTasksAssemblyPath)is set in theMonoTargets.Sdkpack - because of the missing pack the above property is unset, causing theUsingTaskevaluation to fail.As a workaround, we move the
UsingTasktoMonoTargets.Sdktoo, 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.