StaticWebAssets.xml not found when using SDK 6.0.100 and targeting NET5

[jsheetzati]

Hello,

We recently upgraded our build servers to use SDK 6.0.100. When running dotnet test / dotnet publish, we get an error message indicating that StaticWebAssets.xml was not found. The issue happens when we are targeting a NET5 project with the NET6 SDK.

F:\BuildAgents\vsts-agent-4-1\_work\_tool\dotnet\sdk\6.0.100\Microsoft.Common.CurrentVersion.targets(5100,5): error MSB3030: Could not copy the file "F:\BuildAgents\vsts-agent-4-1\_work\4\s\DotNetCore\Source\WebApi\obj\release\net5.0\staticwebassets\WebApi.StaticWebAssets.xml" because it was not found. [F:\BuildAgents\vsts-agent-4-1\_work\4\s\DotNetCore\Source\WebApi.Test\WebApi.Test.csproj]

This error seems very similar to other issues, but we are still running into the problem with SDK Version 6.0.100. https://github.com/dotnet/sdk/issues/21056 https://github.com/dotnet/sdk/issues/20008 https://github.com/dotnet/sdk/issues/19665 https://github.com/dotnet/aspnetcore/issues/35345

[RestoreMonarchy]

I have the same issue since I installed .NET 6 on my Ubuntu 20.04 VPS. My Jenkins started failing when building .NET 5 applications

+ sudo dotnet publish implementations/mock/MockWebAPI/MockWebAPI.csproj -c Release -o /var/www/nakope/api/mock/
Microsoft (R) Build Engine version 17.0.0+c9eb9dd64 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored /var/lib/jenkins/workspace/nakope.pl - master/api/Revel.API.Web/Revel.API.Web.csproj (in 206 ms).
  Restored /var/lib/jenkins/workspace/nakope.pl - master/api/Revel.API/Revel.API.csproj (in 5 ms).
  Restored /var/lib/jenkins/workspace/nakope.pl - master/implementations/mock/MockWebAPI/MockWebAPI.csproj (in 1.23 sec).
  Revel.API -> /var/lib/jenkins/workspace/nakope.pl - master/api/Revel.API/bin/Release/net5.0/Revel.API.dll
  Revel.API.Web -> /var/lib/jenkins/workspace/nakope.pl - master/api/Revel.API.Web/bin/Release/net5.0/Revel.API.Web.dll

/usr/share/dotnet/sdk/6.0.100/Microsoft.Common.CurrentVersion.targets(5100,5): error MSB3030: Could not copy the file "/var/lib/jenkins/workspace/nakope.pl - master/api/Revel.API.Web/obj/Release/net5.0/staticwebassets/Revel.API.Web.StaticWebAssets.xml" because it was not found. [/var/lib/jenkins/workspace/nakope.pl - master/implementations/mock/MockWebAPI/MockWebAPI.csproj]
Build step 'Execute shell' marked build as failure
Sending notification to Discord.
Finished: FAILURE

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[jsheetzati]

With this being moved to the NET7 milestone, what is the workaround in the mean time? I thought the SDK is backwards compatible with older runtimes. This is blocking us from upgrading our build servers to use SDK6.

[madelson]

This is happening to me as well using VS2022.

[ghost]

Hi @jsheetzati. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[javiercn]

@jsheetzati is this still happening to you?

If so, please provide a minimal repro project with steps on how to reproduce this issue.

We believe this was likely caused by building the project from a dirty state with a new SDK. Doing a one time clean of the bin and obj folders should likely solve the problem after you've upgraded to a 6.0 SDK

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[madelson]

We believe this was likely caused by building the project from a dirty state with a new SDK. Doing a one time clean of the bin and obj folders should likely solve the problem after you've upgraded to a 6.0 SDK

@javiercn isn't this still a bug that should be fixed? I feel like you shouldn't have to do a clean in order to change things like Configuration, TargetFramework, etc. but in my experience VS often struggles with that.

[javiercn]

@madelson these types of issues are rare and appear when people switch SDK versions, not necessarily target framework, configuration, etc.

We do our best to thoroughly test these things, but the reality is that there are too many variables here that is almost impossible not to miss some of them.

In addition to that, it is generally hard to automate testing these types of scenarios as it requires building with an old version of the SDK, upgrading and then performing another build, which means we need to have an older version of the SDK setup on our test infrastructure to test these type of incrementalism issues, which we don't currently have because its expensive to do/maintain.

Finally, in the end these issues, while ideally avoidable, in most cases are transient, deleting the bin/obj normally makes the problem go away forever and over time there is less and less people that run into the situation.

We ourselves also experience this upgrade pain, and while we try our best to avoid it (and avoid it for other people) the reality is that it's something we need to live with when we upgrade, its simpler to make sure your build environment is clean than to try and make sure that any dirty environment builds successfully after an upgrade.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.