-
Notifications
You must be signed in to change notification settings - Fork 873
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
Automatic load for librdkafka libraries not working in NetFramework projects with 2.6.0 #2328
Comments
We face same blocking issue. I cloned |
Can you try with 2.6.1? We've added back |
I'll give it a try as soon as I can, right now we're in the final stage of our release cycle so the dependencies are fixed. |
I have validated this by running your own unit tests against net48 and that works. With 2.6.0 that failed. I would still love to see your automated tests extended to also cover NET Framework to avoid this mistake from repeating itself in future. |
I am still encountering this issue. I have a NET Framework 4.8 project that references 2.6.1 and receive the following error at runtime: No issue in my NET 6 project referencing 2.6.1. |
Finally we were able to do the update and, same as @UBSaxo, the code is working fine now with |
Description
When using the libraries in Net 4.8 project (in particular a WebAPI), as of
2.6.0
the initialization of theConfluent.Kafka.Impl.Librdkafka
initialization fails with aDllNotFoundException
and the message:How to reproduce
In a NetFramework project, reference to the latest version of the
Confluent.Kafka
package; as soon as the runtime reaches the Kafka initialization (ie: using theProducerBuilder<,>
) the exception is thrown even if the redist assemblies are in place (in particular in thebin\librdkafka
as thelibrdkafka.redist
package targets take care of).Root cause Analysis
I believe that the problem is hapenning because
2.6.0
has not included the target fornet462
; therefore the initialization goes through the netstandard variation without the automatic path resolution that is present for the cases of net462.Workaround
This can be avoided by simply including a call to
Library.Load(path)
wherepath
contains the location for thelibrdkafka.dll
(which in case can beripped ofinspired by the logic used by the implementation of theLoadNetFrameworkDelegates
.The text was updated successfully, but these errors were encountered: