Azure-cosmos-dotnet-v3: error MSB4018: System.ArgumentException: Invalid input specification: Found multiple entries with the same BundleRelativePath

[Zheltov]

I was creating new .net core console application with just one nuget reference "Microsoft.Azure.Cosmos" and tried publish single file. And i was getting error when published:
The "GenerateBundle" task failed unexpectedly. System.ArgumentException: Invalid input specification: Found multiple entries with the same BundleRelativePath.

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishSingleFile>true</PublishSingleFile> <RuntimeIdentifier>win-x64</RuntimeIdentifier> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.Azure.Cosmos" Version="3.0.0" /> </ItemGroup> </Project>

As discussed here, this is a bug in sdk. Another way it`s fix problem in a package directly.

[j82w]

What operating system are you using?

[ausfeldt]

I know what the issues is. It will be fixed in the next release of the SDK. As a workaround you can delete the build folder in "packagesmicrosoft.azure.cosmos3.3.0". If you are using SDK Direct Mode and not Gateway Mode, and you run into an error that say it can not find Microsoft.Azure.Cosmos.ServiceInterop.dll, set DisableSkipInterop = 0 in either your app.config or environment variable.

[kirankumarkolli]

Isn't "GenerateBundle" task part of project system (or build time)?
ServiceInterop loop-up is runtime, how are these two related?

Also V3 SDK always by-pass this check and look for existence of native interop DLL.

[ausfeldt]

The targets in the package copy the native DLLs in runtimes to the output directory. When using single file publish in .NET Core 3.0, it also copies the DLLs to the output directory, by copying the whole runtimes folder to the output directory. GenerateBundle fails because it has 2 path to the native DLLs and does not know what to do, or what to pick, and throws. So it is either you fix GenerateBundle to have logic to pick, or fix in the packages by making sure it does not copy to the output directory if target framework is .NET Core 3.0.

[kirankumarkolli]

Using VS version 16.4.3, not able to repro it.
Please validate with latest toolsets and re-open with repro.

[heebaek]

this problem still exists in
Visual Studio Community 2019 for Mac
Version 8.4.3 (build 12)

[j82w]

@heebaek are you using the latest 3.6.0 release?

[heebaek]

yes. and i checked @ausfeldt 's workaround also works in mac environment.
(delete build folder in ~/.nuget/packages/microsoft.azure.cosmos/3.6.0)

[j82w]

Did you do the suggestion with DisableSkipInterop = 0 in either your app.config or environment variable?

[heebaek]

No i did not. my project was asp.net core application, not console app.

[penyland]

Hi!
This still repros on 3.13.0 when building a self contained. NET5 RC1 WebApi for RID win10-x64. Builds without problems when using RID linux-x64 .

Easy to reproduce by doing:
dotnet new webapi -n TestApi -f net5.0
dotnet add TestApi package Microsoft.Azure.Cosmos -v 3.13.0
dotnet publish .TestApiTestApi.csproj -c release -r win-x64 /p:PublishSingleFile=true --self-contained

Removing the build folder (~/.nuget/packages/microsoft.azure.cosmos/3.13.0) solves the issue for win10-x64.

[Callindrill]

Same issue. I'm trying to publish an exe with

dotnet publish <csproj> --configuration "Release" --output "bin\Release\netcoreapp3.1\publish\" --self-contained -r win-x64 /p:PublishSingleFile=true

Examining the diag logs from that publish reveals these two DLLs that are being copied twice (appear to be the same DLL, but picked up for two different reasons).

~\.nuget\packages\microsoft.azure.cosmos\3.13.0\runtimes\win-x64\native\Microsoft.Azure.Cosmos.ServiceInterop.dll
    CopyToPublishDirectory=PreserveNewest
    RelativePath=Microsoft.Azure.Cosmos.ServiceInterop.dll
    TargetPath=Microsoft.Azure.Cosmos.ServiceInterop.dll
~\.nuget\packages\microsoft.azure.cosmos\3.13.0\runtimes\win-x64\native\Microsoft.Azure.Cosmos.ServiceInterop.dll
    AssetType=native
    CopyLocal=true
    CopyToPublishDirectory=PreserveNewest
    DestinationSubPath=Microsoft.Azure.Cosmos.ServiceInterop.dll
    NuGetPackageId=Microsoft.Azure.Cosmos
    NuGetPackageVersion=3.13.0
    PackageName=Microsoft.Azure.Cosmos
    PackageVersion=3.13.0
    PathInPackage=runtimes/win-x64/native/Microsoft.Azure.Cosmos.ServiceInterop.dll
    RelativePath=Microsoft.Azure.Cosmos.ServiceInterop.dll

and

~\.nuget\packages\microsoft.azure.cosmos\3.13.0\runtimes\win-x64\native\Cosmos.CRTCompat.dll
    CopyToPublishDirectory=PreserveNewest
    RelativePath=Cosmos.CRTCompat.dll
    TargetPath=Cosmos.CRTCompat.dll
~\.nuget\packages\microsoft.azure.cosmos\3.13.0\runtimes\win-x64\native\Cosmos.CRTCompat.dll
    AssetType=native
    CopyLocal=true
    CopyToPublishDirectory=PreserveNewest
    DestinationSubPath=Cosmos.CRTCompat.dll
    NuGetPackageId=Microsoft.Azure.Cosmos
    NuGetPackageVersion=3.13.0
    PackageName=Microsoft.Azure.Cosmos
    PackageVersion=3.13.0
    PathInPackage=runtimes/win-x64/native/Cosmos.CRTCompat.dll
    RelativePath=Cosmos.CRTCompat.dll

[j82w]

@Callindrill have you tried using the following flag? /p:IncludeNativeLibrariesInSingleFile=true

[Callindrill]

@j82w I hadn't before, but that results in the same error as earlier. The only thing that seems to help is, as @penyland said, deleting the build folder located in the package folder.