Skip to content
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

Referencing Unmanaged Libraries used with Managed APIs in Notebook Editor #1823

Closed
shaggygi opened this issue Oct 9, 2021 · 3 comments
Closed

Comments

@shaggygi
Copy link

shaggygi commented Oct 9, 2021

This issue was created here based on discussion from here. Please let me know if I need to move elsewhere as it is not related to the ML Model Builder.

I have a Class Library wrapper API that includes an unmanaged DLL (with DLLImports on functions) that must be located in the same directory as API and EXEs when using. How do you go about also referencing the unmanaged library within the notebook?

Also note I was not able to do this within the C# Interactive, as well.

Thanks.

@jonsequitur
Copy link

I suspect this issue belongs in either https://github.com/dotnet/interactive or https://github.com/dotnet/roslyn.

Could you provide more detailed repro steps?

@shaggygi
Copy link
Author

shaggygi commented Oct 9, 2021

@jonsequitur thanks for reaching out. I agree, this probably should be in one of your mentioned repos, but added here based on the referenced discussion.

I started to setup some demo code, but for some reason now appears to work in C# Interactive. Completely confused now as I was getting a few errors like "reference not found" which is usually what happens when the unmanaged DLL is not within the folder as .NET API that is calling into.

As for the new Notebook Editor, I have not tried but guessing it should be the same as referencing APIs (e.g. #r ....dll) similar to C# Interactive.

I'm going to close for now. I'll reopen if I can duplicate. Thanks again.

@shaggygi shaggygi closed this as completed Oct 9, 2021
@jonsequitur
Copy link

The #r behavior in all of these cases is the same implementation but one potential reason for different behaviors could be the assembly resolver logic. If you see it happen again, check that the current working directory is the one you expect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants