Roslyn: Requiring references to dependency after upgrading to preview8 SDK

[smitpatel]

Source code: https://github.com/dotnet/efcore/

We use Microsoft.Azure.Cosmos version 3.12.0 in one of our package we ship. It was building fine with preview7 SDK.
When we upgraded to preview8 SDK, we started getting compile time error.

CSC : error CS0012: The type 'PartitionKeyInternal' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Azure.Cosmos.Direct, Version=3.11.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. [D:\code\efcore\src\EFCore.Cosmos\EFCore.Cosmos.csproj]

Looking at the package Microsoft.Azure.Cosmos.Direct it is implementation detail of Microsoft.Azure.Cosmos and not supposed to be consumed directly. Further, we are not using PartitionKeyInternal type in our project at all.

After adding dependency to Cosmos.Direct manually, everything works correctly. But it should not be needed.
Any pointers?

[smitpatel]

Tagging @Pilchie - this is something we need for 5.0 release.

[Pilchie]

This actually sounds like the compiler, not the SDK. Moving to dotnet/roslyn, and tagging @jaredpar to help understand why this dependency is showing up.

[Pilchie]

In general, these transitive references may be required by the compiler whenever they are seen by the compiler, even if they aren't directly used. (The example I remember best is if the compiler considers an overload that contains the type, even if it isn't used).

[DmytryEmery]

I was also experienced this exact error.

It started with ~5.0 preview 8
and I just tried, and it's still an issue with 5.0 RC1

Downgrading to 3.1 resolves the issue for me.

[DmytryEmery]

After looking around a bit more, it appears RC2 will potentially have the fix:
https://github.com/dotnet/efcore/pull/22449

[jongio]

I'm seeing this in SDK Version: 5.0.100-rc.2.20479.15

Added this to csproj
<PackageReference Include="Microsoft.Azure.Cosmos.Direct" Version="3.4.1.0" />

azsdke2e

[HiroyukiSakoh]

I had the same problem after updating to VS 16.8.0.
Is this a problem with the compiler?

[JonathanLydall]

I have the same problem today after having upgraded to VS 16.8.0.

According to this commit, it looks like Microsoft.Azure.Cosmos 3.15.0 will make the problem go away.

[KTOmega]

Also having this issue after upgrading to 16.8.0. Upgrading to Microsoft.Azure.Cosmos version 3.15.0-preview still produced the same error.

error CS0012: The type 'TokenCredential' is defined in an assembly that is not referenced. You must add a reference to assembly 'Azure.Core, Version=1.3.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8'.
error CS0012: The type 'PartitionKeyInternal' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Azure.Cosmos.Direct, Version=3.14.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

[AjaySewradj]

I also got the same problem after upgrading to VS 16.8.1.
The problem was fixed when I updated the Microsoft.Azure.Cosmos package to version 3.15.1-preview

[pellea]

I also have the issue after upgrading VS to 16.8.1 and installing .NET 5.0.100.
But my project has a global.json with sdk version set to 3.1.201 so I'm not really sure why I have this error. This should not be using the .NET 5 framework but the one specified.

.NET SDKs installed:
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.505 [C:\Program Files\dotnet\sdk]
  2.1.508 [C:\Program Files\dotnet\sdk]
  2.1.801 [C:\Program Files\dotnet\sdk]
  2.2.401 [C:\Program Files\dotnet\sdk]
  3.0.100 [C:\Program Files\dotnet\sdk]
  3.1.201 [C:\Program Files\dotnet\sdk]
  5.0.100 [C:\Program Files\dotnet\sdk]

[i3anaan]

Experiencing this same issue.
A colleague of my got this problem after updating visual studio, additionally a pipeline of ours suddenly started failing on this error.

Edit: upgrading Microsoft.Azure.Cosmos to version 3.15.0 fixed it
Double edit: version 3.15 fixed it for the pipeline, not on our local machines when using Visual Studio 16.8.2. The problem still persists.

[SameerDoshi]

I am also running into this issue. Interestingly, after moving to 3.15.0-preview (1 or 2) everything builds, but when I run CosmosClient.getDatabase("myDB").getContainer("myContainer) I get the error again.
I do not have a resolution to this.

[SameerDoshi]

I was able to resolve my issue by moving to functions v3.
This link explains why dotnet functions needed to be updated after 10/31: https://github.com/Azure/azure-functions-host/wiki/Platform-upgrade-from-Azure-Functions-runtime-v2-to-v3

This link explains how to upgrade a function: https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions#migrating-from-2x-to-3x

Hope this helps!!!

[pellea]

Unfortunately I'm not in an Azure Function project but a simple .NET Standard class library.

[jkonecki]

This is exteremly worrying that compiler can be broken for months and released to general public!
I have a project that I cannot compile anymore just because I've upgraded VS and got .NET 5 installed (which I'm not using).
Why the global.json doesn't work anymore? The whole point of .Net Core is to support side-by-side installation.

[debolakoya]

I have the same problem today after having upgraded to VS 16.8.0.

According to this commit, it looks like Microsoft.Azure.Cosmos 3.15.0 will make the problem go away.

This fixed the issue for me. I had initially upgraded to 16.8.0, when I encountered the issue, I downgraded back to 16.7.8. After trying to upgrade again to 16.8.3, hoping the issue would have been resolved, alas, it was still there!!! Upgrading Microsoft.Azure.Cosmos to 3.15.0 fixed the issue.

[jkonecki]

That's not the best solution for me. I maintain a library that uses
CosmosDB and changing the dependency will require all users of my library
to upgrade CosmosDB as well.

SDK locking down is a principal feature of Core and should work.

On Sun, 20 Dec 2020, 00:50 Bola Adekoya, [e-mail] wrote:

I have the same problem today after having upgraded to VS 16.8.0.

According to this commit
https://github.com/dotnet/efcore/issues/22231#ref-commit-e19f30b, it
looks like Microsoft.Azure.Cosmos 3.15.0 will make the problem go away.

This fixed the issue for me. I had initially upgraded to 16.8.0, when I
encountered the issue, I downgraded back to 16.7.8. After trying to upgrade
again to 16.8.3, hoping the issue would have been resolved. It was still
there but upgrade Microsoft.Azure.Cosmos to 3.15.0 fixed the issue.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/roslyn/issues/47304#issuecomment-748546061,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANRNDYEX4PTYI2G5CGCNTLSVVC4BANCNFSM4QQZXMKA
.