dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.23k stars 1.35k forks source link

Internal MSBuild Error: Unexpected CopyLocal flag #4072

Closed peterhuene closed 8 months ago

peterhuene commented 5 years ago

Steps to reproduce

See original discussion on https://github.com/dotnet/cli/issues/10452.

Using a preview 1 .NET Core SDK (3.0.100-preview-009812) with MSBuild version 16.0.225.48734 on macOS or Linux:

dotnet new console
dotnet add package akka.multinodetestrunner
dotnet build

Expected behavior

The project builds successfully, but warns for each unexpected native assembly without managed metadata found in lib/netcoreapp1.1.

Actual behavior

The project fails with the following error:

/usr/local/share/dotnet/sdk/3.0.100-preview-009812/Microsoft.Common.CurrentVersion.targets(2114,5): error MSB4018: The "ResolveAssemblyReference" task failed unexpectedly. [/Users/peterhuene/tmp/repro/repro.csproj]
/usr/local/share/dotnet/sdk/3.0.100-preview-009812/Microsoft.Common.CurrentVersion.targets(2114,5): error MSB4018: Microsoft.Build.Shared.InternalErrorException: MSB0001: Internal MSBuild Error: Unexpected CopyLocal flag. [/Users/peterhuene/tmp/repro/repro.csproj]
/usr/local/share/dotnet/sdk/3.0.100-preview-009812/Microsoft.Common.CurrentVersion.targets(2114,5): error MSB4018:    at Microsoft.Build.Tasks.CopyLocalStateUtility.IsCopyLocal(CopyLocalState state) [/Users/peterhuene/tmp/repro/repro.csproj]
/usr/local/share/dotnet/sdk/3.0.100-preview-009812/Microsoft.Common.CurrentVersion.targets(2114,5): error MSB4018:    at Microsoft.Build.Tasks.ResolveAssemblyReference.LogResults(ReferenceTable dependencyTable, List`1 idealAssemblyRemappings, List`1 idealAssemblyRemappingsIdentities, ArrayList generalResolutionExceptions) [/Users/peterhuene/tmp/repro/repro.csproj]
/usr/local/share/dotnet/sdk/3.0.100-preview-009812/Microsoft.Common.CurrentVersion.targets(2114,5): error MSB4018:    at Microsoft.Build.Tasks.ResolveAssemblyReference.Execute(FileExists fileExists, DirectoryExists directoryExists, GetDirectories getDirectories, GetAssemblyName getAssemblyName, GetAssemblyMetadata getAssemblyMetadata, GetLastWriteTime getLastWriteTime, GetAssemblyRuntimeVersion getRuntimeVersion, GetAssemblyPathInGac getAssemblyPathInGac, IsWinMDFile isWinMDFile, ReadMachineTypeFromPEHeader readMachineTypeFromPEHeader) [/Users/peterhuene/tmp/repro/repro.csproj]
/usr/local/share/dotnet/sdk/3.0.100-preview-009812/Microsoft.Common.CurrentVersion.targets(2114,5): error MSB4018:    at Microsoft.Build.Tasks.ResolveAssemblyReference.Execute() [/Users/peterhuene/tmp/repro/repro.csproj]
/usr/local/share/dotnet/sdk/3.0.100-preview-009812/Microsoft.Common.CurrentVersion.targets(2114,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/Users/peterhuene/tmp/repro/repro.csproj]
/usr/local/share/dotnet/sdk/3.0.100-preview-009812/Microsoft.Common.CurrentVersion.targets(2114,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/Users/peterhuene/tmp/repro/repro.csproj]

Note that the referenced package has incorrectly been packaged. It contains native PEs in lib/netcorelib1.1, which we do get warnings for:

/usr/local/share/dotnet/sdk/3.0.100-preview-009812/Microsoft.Common.CurrentVersion.targets(2114,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Assembly file '/Users/peterhuene/.nuget/packages/akka.multinodetestrunner/1.3.11/lib/netcoreapp1.1/API-MS-Win-Base-Util-L1-1-0.dll' could not be opened -- PE image doesn't contain managed metadata. [/Users/peterhuene/tmp/repro/repro.csproj]
...

The expected behavior then would provide these warnings but RAR should ignore them entirely for both referencing and copy-local.

Environment data

$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-009812
 Commit:    e3abf6e935

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.14
 OS Platform: Darwin
 RID:         osx.10.14-x64
 Base Path:   /usr/local/share/dotnet/sdk/3.0.100-preview-009812/

Host (useful for support):
  Version: 3.0.0-preview-27122-01
  Commit:  00c5c8bc40

.NET Core SDKs installed:
  2.1.302 [/usr/local/share/dotnet/sdk]
  2.1.502 [/usr/local/share/dotnet/sdk]
  2.2.101 [/usr/local/share/dotnet/sdk]
  3.0.100-preview-009812 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-18579-0056 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview-27122-01 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
dotnet msbuild /version
Microsoft (R) Build Engine version 16.0.225-preview+g5ebeba52a1 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

16.0.225.48734
MarkKharitonov commented 4 years ago

I have just faced the same problem with 16.5. We have a big nuget package containing all the dependencies within. Adding it to the project resulted in this error. Any workaround?

whihathac commented 4 years ago

+1

MarkKharitonov commented 4 years ago

I have found the reason why it happens for us. The NuGet packs a certain Asp.Net Core with all of its dependencies using a NuSpec file. It packs both the platform dependent executable and the .Net Core DLL. The presences of both seems to kill msbuild. Once we excluded the EXE from the package file it worked.

drfbwilliams commented 4 years ago

I'm currently hitting this.

I've not modified any of the nuget packages that my solution is consuming - now all of a sudden I get this same build error both locally and in devops

MSB0001: Internal MSBuild Error: Unexpected CopyLocal flag

Microsoft.Build.Shared.InternalErrorException: MSB0001: Internal MSBuild Error: Unexpected CopyLocal flag. at Microsoft.Build.Tasks.CopyLocalStateUtility.IsCopyLocal(CopyLocalState state) at Microsoft.Build.Tasks.ResolveAssemblyReference.LogResults(ReferenceTable dependencyTable, List1 idealAssemblyRemappings, List1 idealAssemblyRemappingsIdentities, List1 generalResolutionExceptions) at Microsoft.Build.Tasks.ResolveAssemblyReference.Execute(FileExists fileExists, DirectoryExists directoryExists, GetDirectories getDirectories, GetAssemblyName getAssemblyName, GetAssemblyMetadata getAssemblyMetadata, GetLastWriteTime getLastWriteTime, GetAssemblyRuntimeVersion getRuntimeVersion, GetAssemblyPathInGac getAssemblyPathInGac, IsWinMDFile isWinMDFile, ReadMachineTypeFromPEHeader readMachineTypeFromPEHeader) at Microsoft.Build.Tasks.ResolveAssemblyReference.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) /usr/share/dotnet/sdk/3.1.302/Microsoft.Common.CurrentVersion.targets(2081,5): error MSB4018: The "ResolveAssemblyReference" task failed unexpectedly. [/home/vsts/work/1/s/DRF.Portal.Web/DRF.Portal.Web/DRF.Portal.Web.csproj] /usr/share/dotnet/sdk/3.1.302/Microsoft.Common.CurrentVersion.targets(2081,5): error MSB4018: Microsoft.Build.Shared.InternalErrorException: MSB0001: Internal MSBuild Error: Unexpected CopyLocal flag. [/home/vsts/work/1/s/DRF.Portal.Web/DRF.Portal.Web/DRF.Portal.Web.csproj] /usr/share/dotnet/sdk/3.1.302/Microsoft.Common.CurrentVersion.targets(2081,5): error MSB4018: at Microsoft.Build.Tasks.CopyLocalStateUtility.IsCopyLocal(CopyLocalState state) [/home/vsts/work/1/s/DRF.Portal.Web/DRF.Portal.Web/DRF.Portal.Web.csproj] /usr/share/dotnet/sdk/3.1.302/Microsoft.Common.CurrentVersion.targets(2081,5): error MSB4018: at Microsoft.Build.Tasks.ResolveAssemblyReference.LogResults(ReferenceTable dependencyTable, List1 idealAssemblyRemappings, List1 idealAssemblyRemappingsIdentities, List1 generalResolutionExceptions) [/home/vsts/work/1/s/DRF.Portal.Web/DRF.Portal.Web/DRF.Portal.Web.csproj] /usr/share/dotnet/sdk/3.1.302/Microsoft.Common.CurrentVersion.targets(2081,5): error MSB4018: at Microsoft.Build.Tasks.ResolveAssemblyReference.Execute(FileExists fileExists, DirectoryExists directoryExists, GetDirectories getDirectories, GetAssemblyName getAssemblyName, GetAssemblyMetadata getAssemblyMetadata, GetLastWriteTime getLastWriteTime, GetAssemblyRuntimeVersion getRuntimeVersion, GetAssemblyPathInGac getAssemblyPathInGac, IsWinMDFile isWinMDFile, ReadMachineTypeFromPEHeader readMachineTypeFromPEHeader) [/home/vsts/work/1/s/DRF.Portal.Web/DRF.Portal.Web/DRF.Portal.Web.csproj] /usr/share/dotnet/sdk/3.1.302/Microsoft.Common.CurrentVersion.targets(2081,5): error MSB4018: at Microsoft.Build.Tasks.ResolveAssemblyReference.Execute() [/home/vsts/work/1/s/DRF.Portal.Web/DRF.Portal.Web/DRF.Portal.Web.csproj] /usr/share/dotnet/sdk/3.1.302/Microsoft.Common.CurrentVersion.targets(2081,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/home/vsts/work/1/s/DRF.Portal.Web/DRF.Portal.Web/DRF.Portal.Web.csproj] /usr/share/dotnet/sdk/3.1.302/Microsoft.Common.CurrentVersion.targets(2081,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/home/vsts/work/1/s/DRF.Portal.Web/DRF.Portal.Web/DRF.Portal.Web.csproj]

Any thoughts or help here would be amazing.

MarkKharitonov commented 4 years ago

@drfbwilliams - are you consuming any NuGet packages developed internally by your organisation?

drfbwilliams commented 4 years ago

@MarkKharitonov thanks for your reply.

The answer is yes, and that appears to be the source of the issue.

One of the projects that is a .Net Core 3.1 console app moves through devops and outputs a nuget package. The problem being that this project also contains our datacontext and should be generating EF migrations sql scripts in our build pipeline - but that too is failing in the most crazy ways.

I am going to create a new project and transplant everything to see if the issue comes back. For now, it appears entirely a conflict in terms of referenced resources between two solutions, one being consumed as a nuget by the other solutions.

MarkKharitonov commented 4 years ago

@drfbwilliams - check if your internal NuGet package contains both exe and dll with the same name. E.g., if the NuGet packages a web application (off by default, but you could have enabled it) or an executable, then .Net Core 3 would pack both the dll and the platform dependent executable, i.e. exe on windows. If you have both .exe and .dll - modify the build process for the NuGet to exclude either .exe or .dll, because it is unlikely you need both in the same NuGet package.

drfbwilliams commented 4 years ago

Thanks @MarkKharitonov - It is definitely this issue with both being packed.

image

This is a problem in my particular situation - EF can only generate SQL scripts from a startup exe, that is why the datacontext sits in that full fat web project.

For anyone else who comes across this - ensure that in the project properties => package, you have not checked Generate NuGet package on build.

image

If you are using the devops NuGet Pack Task, you will need create a basic .nuspec file which needs to exclusively executed (as opposed to allowing the Task to pack from the .csproj file) in order to exclude the exe

In the nuspec file, just include a package sibling section for file(s) to include and exclude such as the following:

image

MarkKharitonov commented 4 years ago

The NuGet Pack Task should not be used on a project. Rather on the solution. Inside the csproj file you can set <IsPackable>false</IsPackable> if you want to skip packing the project at all.

If you do want to pack it, but avoid having both exe and dll, then I suppose there should be a build property that suppresses the generation of the framework dependent executable. I just do not know it. Or you could have a post build step that deletes it.

In my opinion it is more convenient than having a custom nuspec.

drfbwilliams commented 4 years ago

@MarkKharitonov I have the Task on the solution - which contains several projects that are libraries. Every project needs to be packed.

I find no build property to suppress the exe, but as I say, generating an exe is required, because of the issue with EF migration script generation on the data context(s).

The other reason to use a nuspec is for the metadata. The nuget task just doesn't respect the assembly info in the csproj so you end up with an utter mess in your artifact feed, all with no author or description information.

Versions are of course a giant mess, so all in all, it is a considerable investment to get this all working correctly with versioned, detailed nuget packages.

Thanks for your help Mark.

amandal1810 commented 4 years ago

I am facing this same issue. I am using an internal NuGet package which generates C# classes based on certain inputs.

amandal1810 commented 4 years ago

Okay! I figured it out... but it might be specific to my case:

I made this change in the .csproj file where I am referencing the internal nuget package: I changed from this:

    <PackageReference Include="Microsoft.Omex.CodeGenerators.SettingsGenerator" Version="20.4.10820.11105" />

to this:

    <PackageReference Include="Microsoft.Omex.CodeGenerators.SettingsGenerator" Version="20.4.10820.11105">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
Stoyanov8 commented 3 years ago

After doing the steps mentioned above, I did two more steps:

  1. Deleted C:\Users[user].nuget .packages folder
  2. Deleted C:\Program Files\dotnet\sdk NuGetFallbackFolder

That fixed the problem for me.

bsolovij-ebsco commented 3 years ago

I have found the reason why it happens for us. The NuGet packs a certain Asp.Net Core with all of its dependencies using a NuSpec file. It packs both the platform dependent executable and the .Net Core DLL. The presences of both seems to kill msbuild. Once we excluded the EXE from the package file it worked.

This was absolutely it for my issue. Had a nuspec file which was gobbling up the xUnit exe - fixed the exclude and publish specs and a return to sanity was achieved. Thanks for the nudge, @MarkKharitonov !

wiisaacs commented 1 year ago

Are there any updates on this? Any way to get more information for what the root issue is when it fails? I had added the exclude for */.exe and yet the package still fails to install with the same message: "Internal MSBuild Error: Unexpected CopyLocal flag."

Forgind commented 1 year ago

I suspect this was resolved by #7937. Can anyone confirm or refute that?

dotnet-policy-service[bot] commented 9 months ago

This issue is marked as stale because feedback has been requested for 30 days with no response. Please respond within 14 days or this issue will be closed due to inactivity.

dotnet-policy-service[bot] commented 8 months ago

This issue was closed due to inactivity. If you can still reproduce this bug, please comment with the requested information, detailed steps to reproduce the problem, or any other notes that might help in the investigation.