Azure-cosmos-dotnet-v2: One or more errors occurred. (Unable to load DLL 'Microsoft.Azure.Documents.ServiceInterop.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E))

[WillRock19]

I am using a Azure Function that calls a class library where I've put my documentDB call and specific methods. The class library is a:

1 .NET Standar 2.0;

1. Using Microsoft.Azure.DocumentDB.Core (1.9.1)

When I try to create a table or a collection, everything works. But When I try to create a query (as it follows), it generate the exception. What should I do? I've look into the web for some solutions, found somethings abou copying the DLL to an specific foulder, but nothing saying if that whould work when I publish my app.

Can someone help me, please? It's kind an urgent matter!

[jackbond]

Welcome to hell. Supposedly this issue was fixed in the 1.9.1 Nuget, guess not.

https://github.com/Azure/azure-documentdb-dotnet/issues/202

[kirankumarkolli]

@ausfeldt please look into this.

[ausfeldt]

@WillRock19 A fix for this is in code review. The package is missing the targets to copy the native assemblies to the output directory.

What is in the missing Microsoft.Azure.Documents.Client.targets file

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <ItemGroup>
      <ContentWithTargetPath Include="$(MSBuildThisFileDirectory)..\runtimes\win7-x64\native\Microsoft.Azure.Documents.ServiceInterop.dll">
        <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
        <TargetPath>Microsoft.Azure.Documents.ServiceInterop.dll</TargetPath>
        <Visible>False</Visible>
      </ContentWithTargetPath>

      <ContentWithTargetPath Include="$(MSBuildThisFileDirectory)..\runtimes\win7-x64\native\DocumentDB.Spatial.Sql.dll">
        <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
        <TargetPath>DocumentDB.Spatial.Sql.dll</TargetPath>
        <Visible>False</Visible>
      </ContentWithTargetPath>
    </ItemGroup>

</Project>

Here is a package that has the targets and will also gracefully fallback if the native assemblies are not found. Microsoft.Azure.DocumentDB.Core.1.9.1.nupkg

[jackbond]

@ausfeldt Your response is confusing. You say a fix is in code review, but 1.9.1 should fail gracefully, but he's using 1.9.1???

[ausfeldt]

@jackbond You suggested the graceful fallback idea. I created and posted a package in #202 implementing that idea before 1.10.0 was released . The fix never made it into the 1.10.0 release as it is still in review.

[NickBrooks]

A fix for this would be good... Any idea when?

[Alexandre-Nourissier]

I encountered this issue and I worked around it by moving the Microsoft.Azure.Documents.ServiceInterop.dll into my bin folder, then I added the bin folder to the path in my Startup class. ( more at https://stackoverflow.com/a/4598747/2151623)

String _path = String.Concat(Environment.GetEnvironmentVariable("PATH"), ";", System.AppDomain.CurrentDomain.BaseDirectory);
        Environment.SetEnvironmentVariable("PATH", _path, EnvironmentVariableTarget.Process);

It's not great but since I know my environment will be 64 bits it's good enough until they release the 1.10.0.

[ausfeldt]

@Alexandre-Nourissier Can you try out Microsoft.Azure.DocumentDB 2.0.0-preview. It has the build.props to copy the native assemblies to the bin. It also will try to gracefully fallback and not use the native dependencies if they are not found.

[WillRock19]

@ausfeldt I'm going to try the new version...

Just to help everyone out: I could manage to bypass the problem using bot versions of documentDB, the one for .Net standard and the one for the other versions together in my project