.NET Core Support #984
Comments
|
Come here and see every few days, hoping to use it as soon |
|
When I create a .NET Standard 2.0 library project in VS2019 and add a NuGet reference to pythonnet_35_dotnet, I get this error: Error NU1202 I tried changing the project's .NET Standard version to both 1.6 and 1.0 and received a similar error message. What am I missing? |
|
@ericjohannsen Latest Python.NET 3.0 previews support .NET Standard, .NET Core, and .NET 5+ |
|
Thank you for that pointer. Why, though, does the original comment state, "Python.NET can be compiled as a .NET Standard DLL"? |
|
@ericjohannsen you can do that right now if you build from source. But the NuGet package is very outdated. Current release is 2.4.1, and the nuget is for 2.3.0. We are working on releasing a new NuGet in a month or two. |
This requires Python3.7 (tries to load python37.dll). Any chance of getting an update that works with 3.8? Or simple instructions on how to build src for dotnet, because current .sln files don't have that in it. |
|
@tig try setting |
|
That worked! Thanks. This is just a PoC so I'm good with the not official status for now. Thanks! |
|
Hello everyone, Is .net core support in active implementation phase? When would it be possible to expect a release? Thanks ! |
|
We are interested in case 2, "Embedding .NET into Python". In our planning, it would be very useful to know whether this work is "indefinitely blocked" or merely taking a break. Particularly interested in using this from dotnetcore and Linux. |
|
@filmor, |
|
@renedacosta Work is on its way, we'll support the "running .NET Core from Python" use-case soon on master. |
|
.NET Core support is now merged into master. The API is not final, yet, but here is an example: from clr_loader import get_coreclr
from pythonnet import set_runtime
rt = get_coreclr("path/to/your.runtimeconfig.json")
set_runtime(rt)
import clr |
This is amazing! But I tried it out locally (windows 10, python 3.8.3) with build: https://ci.appveyor.com/project/pythonnet/pythonnet/branch/master/job/p8gu64su5snt30nt/artifacts and this runtime config (self-contained dll): I get the following error message when running For none self-contained dll it works just fine :) I hope this can be of help in debugging the solution :) Thanks for all the good work! |
|
I haven't tested self-contained deployments yet, will do that now :) |
|
Great achievement, thank you for this. I have just tried the latest master with self-contained deployment, it works properly on my side. I use the .NET 5.0.2 runtime with this config: Additionally, I tested the |
|
Well, this is not a self-contained deployment then. Self-contained means that the frameworks are listed under the The |
|
You are right, I was not accurate in my description. This is really not a self-contained application but a library collection with standalone .NET runtime. This solution is a workaround for my original goal to load libraries from a self-contained application that is not yet supported by .NET Core: dotnet/runtime#35329 (Starting a self-contained application is possible but in the case of Python.NET, I believe, it is not an option.) Thank you for the clear explanation, this was my understanding. From the user's point of view, this could be slightly confusing since |
|
(I have found a bug with virtual environment: #1388) |
|
When I install pythonnet but still not find pythonnet module, Can some one help me? I use m1 Mac book, dotnet 6.0.0. When pip install pythonnet, It build with mono, Then I import clr will got error: ❯ python
Python 3.9.2 | packaged by conda-forge | (default, Feb 21 2021, 05:00:30)
[Clang 11.0.1 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen(/Users/lisa/mambaforge/lib/python3.9/site-packages/clr.cpython-39-darwin.so, 0x0002): symbol not found in flat namespace '_mono_assembly_get_image'So I want to change the runtime lib, but I can't import the pythonnet: >>> from clr_loader import get_coreclr
rt = get_coreclr("/Users/lisa/Documents/nncase/runtimeconfig.json")
from pythonnet import set_runtime
set_runtime(rt)>>> rt = get_coreclr("/Users/lisa/Documents/nncase/runtimeconfig.json")
['/usr/local/share/dotnet/host/fxr/6.0.0/libhostfxr.dylib']
>>>
>>> from pythonnet import set_runtime
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'pythonnet' |
|
@zhen8838 The currently released version of pythonnet (2,5,2) does not support dotnet yet. |
|
@anders-wind Thanks, Now I successfully use dotnet core in Mac m1 (python 3.9) from master branch, Hope Pythonnet can make new stable release. |
|
@filmor @anders-wind
I used following app.runtime.json file to load .NET 5.0 DLL
and here is the code I used to load .NET 5.0 DLL
But when I tried to load .NET 5.0 DLL I got following errors in import clr
I successfully tested this code on Windows OS with same pythonnet package and same DLL. but on Linux it is not working. |
|
@filmor @anders-wind |
|
@weixu02 we are targeting January-February 2022 |
This comment has been minimized.
This comment has been minimized.
|
Should this issue really be closed given that it has not been delivered yet? PythonNet is a super helpful library. Many thanks to the team for providing it ❤️ |
|
The issue is closed because support has been merged into master. We don't have the time to track released features separately right now, we might do that once 3.0 is out. |
There are two major modes of using Python.NET:
Each of them has a distinct "support" status for .NET Core.
The first case should already be possible, as Python.NET can be compiled as a .NET Standard DLL that can be referenced within .NET Core.
The second case is actively being worked at in #857, I'll open a corresponding PR this weekend. There is a previous attempt in #612 that uses the older (in fact second)
coreclrhosting API and significantly complicates the build-process, which is already annoyingly complicated.Furthermore, we have to simplify the way how
libpythonis loaded in the embedding case, which @lostmsu has already tried out and we'll look into further once the new loading mechanism has landed.The text was updated successfully, but these errors were encountered: