msbuild silently ignores workload pack import, if the expected version of the pack is not found #21032
Comments
dotnet-issue-labeler
bot
added
Area-NetSDK
untriaged
radical
changed the title
|
Our test projects are also severely impacted by this error, as it effects projects building for target .NET Framework 4.6.1 intermittently using Dotnet SDK. Any guidance would be highly appreciated!
|
|
@cheenamalhotra that doesn't seem related to workloads. Please correct me if I'm wrong. |
|
The props file seems absent in binlog. (Strangely, this happens intermittently)
|
|
It is although available in NuGet: https://nuget.info/packages/Microsoft.SourceLink.Common/1.0.0 |
|
I would suggest filing an issue in https://github.com/dotnet/sourcelink . |
|
I think there was one issue in that repo: dotnet/sourcelink#644 which seems to be tracked in dotnet/project-system#4781, I didn't get any response from them before so I left those threads. But due to some reason the props file isn't loading and properties are missing, it seems an underlying msbuild/sdk issue to me. |
|
The sourcelink error is different from the workload error. It sounds like the sourcelink issue may have to do with how Visual Studio NuGet restore works. If that's the case, then a full restore from the command line might work around the issue. 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 Is there a scenario where this would happen besides someone manually renaming things in the packs directory? If you wanted to fix this specific issue, an easy fix might be to move the ReadEmccProps |
|
closing older issues as this isn't a mainline scenario. If this is still impacting, please reactivate. |
|
This is hit on dotnet/runtime#78237 by upgrading from VS 17.3.6 to 17.4.2 . There was no manual renaming done here. cc @lewing |
|
It would be useful to get the errors in such a case.
I will backport this fix for 6.0 . We already have this in newer versions. |
I was mistaken. The fix you suggested would move I will move the |
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.
) * [wasm] Work around an issue in VS upgrade 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. * Add UsingTask for ReadEmccProps to LocalBuild targets, because WBT/EMSDK run doesn't have monotargets props on CI * Add UsingTask to InTree targets also
If I install
wasm-toolsworkload. Then change the version of one of the packs, saypacks/Microsoft.NET.Runtime.MonoTargets.Sdkto something other than the one mentioned inWorkloadManifest.json. And build a project that uses this, thendotnet builddoes not complain about the missing import, and continues on to fail at a later point because of missing properties etc.To reproduce:
Wasm-toolsworkloadmv packs/Microsoft.NET.Runtime.MonoTargets.Sdk/{version} packs/Microsoft.NET.Runtime.MonoTargets.Sdk/1.2.3dotnet new blazorwasm; dotnet build -p:RunAOTCompilation=true.. it fails with
The log has a single line for that pack -
Resolving SDK 'Microsoft.NET.Runtime.MonoTargets.Sdk'....I can reproduce this with dotnet
6.0.100-rc.2.21463.12.cc @dsplaisted @sfoslund @rainersigwald @lewing @steveisok
The text was updated successfully, but these errors were encountered: