@lostmsu This approach (Python.Loader.dll explicitly modifies and adjusts Python.Runtime.dll) works nicely for embedding into Python, but I can't get it to work in the other direction right now (embedding Python in C#), as the Python.Runtime seems to be eagerly loaded. Do you still have your branch were you stubbed out the Python functions into an interface? We can discuss this a bit more on Thursday.

Recap: The main reason we have to do something like this is that __Internal as the DLL name for P/Invoke only works on Mono (allows us to preload the DLL using the respective dynamic linkers, for which we already have a working implementation), and it's possible to do something similar for .NET Core, but definitely not for .NET Framework.

#987 is relevant.

@filmor I am actually working on #987. It is currently blocked on the release of dotnet/roslyn#49760 . From the looks of it, will be released with the next VS 2019 16.9.x preview hopefully in a couple of weeks (maybe early Jan because of holidays).

Expect to be able to set Runtime.PythonDLL before calling PythonEngine.Initialize(...) or maybe have an Initialize overload, that takes DLL path.

Oh, forgot to mention. I expect the default value for Runtime.PythonDLL to be null, and behave identical to __Internal, so loader should not need to change it.

On all runtimes?

Yes. However, I think we need to have TypeOffset code on Python side. E.g. clr module should pass a dict describing TypeOffset to Python.Runtime during initialization. That way we can have single Python.Runtime handle any version of Python.

I'll have a look into this. Worst case, we just run our pycparser once on first start and generate and cache the data in an easily readable format.