Closed peterhuene closed 8 months 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?
+1
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.
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, List
1 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, List
1 idealAssemblyRemappings, List1 idealAssemblyRemappingsIdentities, List
1 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.
@drfbwilliams - are you consuming any NuGet packages developed internally by your organisation?
@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.
@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.
Thanks @MarkKharitonov - It is definitely this issue with both being packed.
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.
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:
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.
@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.
I am facing this same issue. I am using an internal NuGet package which generates C# classes based on certain inputs.
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>
After doing the steps mentioned above, I did two more steps:
That fixed the problem for me.
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 !
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."
I suspect this was resolved by #7937. Can anyone confirm or refute that?
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.
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.
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:
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:
Note that the referenced package has incorrectly been packaged. It contains native PEs in
lib/netcorelib1.1
, which we do get warnings for:The expected behavior then would provide these warnings but
RAR
should ignore them entirely for both referencing and copy-local.Environment data