-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Requiring references to dependency after upgrading to preview8 SDK #47304
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Tagging @Pilchie - this is something we need for 5.0 release. |
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. |
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). |
I was also experienced this exact error. It started with ~5.0 preview 8 Downgrading to 3.1 resolves the issue for me. |
After looking around a bit more, it appears RC2 will potentially have the fix: |
I'm seeing this in SDK Version: 5.0.100-rc.2.20479.15 Added this to csproj azsdke2e |
I had the same problem after updating to VS 16.8.0. |
I have the same problem today after having upgraded to VS 16.8.0. According to this commit, it looks like |
Also having this issue after upgrading to 16.8.0. Upgrading to
|
I also got the same problem after upgrading to VS 16.8.1. |
I also have the issue after upgrading VS to 16.8.1 and installing .NET 5.0.100.
|
Experiencing this same issue. Edit: upgrading |
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 was able to resolve my issue by moving to functions 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!!! |
Unfortunately I'm not in an Azure Function project but a simple .NET Standard class library. |
This is exteremly worrying that compiler can be broken for months and released to general public! |
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 |
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, ***@***.***> wrote:
I have the same problem today after having upgraded to VS 16.8.0.
According to this commit
<dotnet/efcore#22231 (reference)>, 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
<#47304 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANRNDYEX4PTYI2G5CGCNTLSVVC4BANCNFSM4QQZXMKA>
.
|
…K - dotnet/roslyn#47304 Upgraded CosmosDB dependency to cope with issue caused by .NET 5.0 SDK - dotnet/roslyn#47304
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.
Looking at the package
Microsoft.Azure.Cosmos.Direct
it is implementation detail ofMicrosoft.Azure.Cosmos
and not supposed to be consumed directly. Further, we are not usingPartitionKeyInternal
type in our project at all.After adding dependency to Cosmos.Direct manually, everything works correctly. But it should not be needed.
Any pointers?
The text was updated successfully, but these errors were encountered: