-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compiler errors when using IAsyncEnumerable<T>
with .NET Standard 2.1 enabled
#5799
Comments
Did you try ML-Agents version: 2.2.1-exp.1 |
@Eelam Yes, the error persists. |
Any thoughts on this? This is making it difficult for me to use ML-Agents. |
Hi, I have the same error "The type 'IAsyncEnumerable' exists in both 'System.Interactive.Async, Version=3.0.1000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263' and 'netstandard, Version=2.1.0.0" |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Describe the bug
Any project that uses
IAsyncEnumerable<T>
with ML-Agents imported and .NET Standard 2.1 enabled will cause compiler errors.Context
The type
System.Collections.Generic.IAsyncEnumerable<T>
is available in both the includedSystem.Interactive.Async
assembly (which is used byGrpc.Core
) and in .NET Standard 2.1. Since around Unity 2021.3, Unity includesIAsyncEnumerable<T>
as part of its .NET Standard 2.1 support; as a consequence, the compiler can't decide whether to importIAsyncEnumerable<T>
fromnetstandard
or fromSystem.Interactive.Async
.This issue probably occurs with other types in
System.Interactive.Async
, but I only checked this one.To Reproduce
IAsyncEnumerable<T>
(in my case, this package)Console logs / stack traces
It depends on the exact library, but here's an example from Razensoft.Mapper:
Environment:
Proposed Fix
I see a couple of possible fixes:
!NET_STANDARD_2_1
to the includedSystem.Interactive.Async
assembly. This way,Grpc.Core
will usenetstandard
when available.System.Interactive.Async
.Grpc.Core
can continue to use that library this way, if you don't mind pulling in redundant library code.Workaround
I see two workarounds:
System.Interactive.Async
, such that theseasmdef
s don't seek it out. (This also worked, but you'd have to do it for every offending assembly.)The text was updated successfully, but these errors were encountered: