ModuleNotFoundError on import of namespace from custom dll #1689

As I have already described before, you need to properly publish things with .NET Core. You can't just use an arbitrary .runtimeconfig.json from somewhere (or maybe you can, but that's outside of what has been tested). Create a project, add Someones.Platform.Custom.Client as a PackageReference and publish it somewhere. Then load the runtime for this configuration. Are you able to load the DLL directly with Assembly.Load("...")?

@filmor partially related to that issue, but shouldn't AddReference fail if there was a problem loading the assembly?

I'll continue to try as you instruct, and I appreciate your forbearance, as all these .NET concepts that are familiar to you are near-gibberish to me at this point.

So I've gone back and asked some more experienced .NET coworkers, and we're still kind of confused here.

First off, it's not exactly clear what is meant by "publish it somewhere". When I right click the existing solution > "publish to folder" I get a build that does not contain any .runtimeconfig.json, though it does produce the DLL I expect. I am guessing that this is because the solution is set up to build as a "Library"?

I am not exactly sure how to create a new project that works as you describe so here is what I tried: I did create a new console application, and added the package reference. When I build, I get a DLL and the runtimeconfig.json (which appears trivial):

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "3.0.0"
    }
  }
}

I then tried loading both the DLL and config file into the image and updating the demo.py to refer to this new config: no change in output.

@filmor I am facing similar issue. Could you please help in fixing this?
I am using .Net Core 5.0
python 3.8

@ssharmamt This is not a support forum, please behave yourself. Your code is definitely wrong in that it first imports clr and only then sets a proper runtime. That's not the same issue as the one reported in this thread.

I'm facing the same issue on the master.

I've build a very simple .NET project, DynMetaObjectTest.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
</Project>

with the following class, TestMeSimple.cs

namespace DynMetaObjectTest
{
    public class TestMeSimple
    {
        public string MyPublicProperty { get; set; }

        public string StringObjectCamelCase { get; set; }

        public TestMeSimple()
        {
        }
    }
}

The python script it's pretty straight forward, TestMe.py:

import clr, os, sys
sys.path.append(r"D:\git\TestMe\bin\Debug\netstandard2.0")
clr.AddReference("DynMetaObjectTest")
from DynMetaObjectTest import TestMeSimple

Output

import clr, os, sys

sys.path.append(r"D:\git\TestMe\bin\Debug\netstandard2.0")

clr.AddReference("DynMetaObjectTest")
<System.Reflection.RuntimeAssembly object at 0x036C4EE8>
from DynMetaObjectTest import TestMeSimple
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name 'TestMeSimple' from 'DynMetaObjectTest' (unknown location)

Note that the same code runs on pythonnet 2.5.2 :

import clr, os, sys

sys.path.append(r"D:\git\TestMe\bin\Debug\netstandard2.0")

clr.AddReference("DynMetaObjectTest")
<System.Reflection.RuntimeAssembly object at 0x000001ECEDF920D0>
from DynMetaObjectTest import TestMeSimple

I tried to build the DLL against netstandard2.1, net45, net48 without changes in the master's behavior.

The zipped DLL (netstandard2.0) can be found here:
DynMetaObjectTest.zip

@igiona

1. I don't think this is the same case. The OP is trying to load a DLL in a .NET Core VM, while you are using the "old" .NET Framework VM.
2. I can't reproduce this, for me the provided DLL works just fine in exactly the way you lined out. Could it be that your Python.NET installation is broken?

@filmor

1. my issues was reproducible also if I compile against netstandard2.1 or net5
2. on the machine I'm working now, I did a clean install of python (3.9.7-64bits) & newly cloned the repository (master@HEAD) and now I can't as well reproduce the issue.
   As soon as I go back on the other machine I'll gather more information (py version + head) and see weather with everything up-to-date I still have the issue or not

@filmor somehow my whole repo "was broken" on my "other machine".
Installing pythonnet-dev from that repo was always causing that issue.
After a clean clone, the issue disappeared.
I'm not sure what was wrong since "git status" was clean.
I'll keep an eye on this and see if I somehow able to break it again :)

I am encountering this issue as well, and am curious as to the current support for .Net Core 5. I don't see any mention of it and this is the only applicable issue that references Core 5 in any way that I have found.

We have a in-house .Net library for communicating with a number of servers via their api interfaces, and I had been working to migrate this library from .Net Framework 4.8 to .Net Core 5 so I actually have a copy of it in each format for testing.

When I import the Framework version of the library, there are no errors. I am able to add the reference, import the namespace, and call the functions. The results aren't exactly what I expect, but its workable (One function returns a string, but when I print it in python its a tuple containing the string and an object type of the parent object it came from).

When I use the Core 5.0 version of the library I am able to add the reference, but when I attempt to import the namespace I get a ModuleNotFoundError.

Assuming support for .Net Core 5.0 isn't currently supported, is there a timeline when it should be?

@TCVZ .NET 5 is supported

If you believe there's a bug, you need to provide clear reproducible steps as in the example above: #1554 (comment)

I'm not sure what all I can provide that hasn't already been provided. I can't provide my dll files for security reasons, but the structures between the two are nearly identical, the only difference is the target framework. Both work without error when being referenced in .Net applications.

Basically the files are named Test.dll and contain a single root namespace of Test. Within Test are a few classes, along with a handful of nested namespaces.

In Python I am simply performing the following:

sys.path.append(<path to dll folder>)
import clr
clr.AddReference("Test")
import Test

<code to connect to the api, do things>

When pointing to the folder containing the Framework version of the code executes without error. When using the 5 dll though I get "ModuleNotFoundError: No module named 'Test'" on the import statement, but AddReference doesn't complain. I have also tried "from Test import Thing" and get the same result.

We have a second library that I was also migrating to .Net 5, and see the same results. Is there a way to see what namespaces it thinks a dll has to see if something is getting named in a weird way?

@TCVZ where's your runtimeConfigPath then?

I don't have one... runtimeConfigPath is not referenced anywhere in the documentation that I can find. In both the readme and extended documentation this code block is provided as all that is needed to load the dll library:

import clr
clr.AddReference("System.Windows.Forms")
from System.Windows.Forms import Form

I was in a rush to get out the door earlier and missed that the thread OP is using 3.0dev. I installed via PIP this morning and have 2.5.2 if that affects the support for .Net 5.