Compile to assembly on linux dotnet core?

[wegel]

Hi,

How would I go about compiling a python source to a dotnet core assembly, using IronPython 2.7.8 on linux? I can't find any pyc.exe or pyc.py in the zipped release.

[slozier]

At this time there is no support for compiling assemblies using .NET Core. There are some APIs relating to saving of assemblies that are missing from .NET Core.

See: https://github.com/dotnet/corefx/issues/4491

[wegel]

Ok, thanks. Can an assembly be built from Windows, targetting .NET standard 2.0, and then used on linux dotnet core? How would one build such an assembly using the Windows tooling? Thanks.

[slozier]

I'm not sure if this works, but you could try using clr.CompileModules to generate the assembly on Windows and then try to execute it with the .NET Core build of IronPython. See https://blogs.msdn.microsoft.com/srivatsn/2008/08/06/static-compilation-of-ironpython-scripts/ for info on CompileModules.

[wegel]

Ok, I'll try that eventually, and report back my findings. Thanks!

[teqdruid]

Reviving this... I've compiled a set of modules in IronPython hosted with net462, then I try to load them in a .NET Core 3.1 hosted IronPython, but no beans:

Could not load type 'System.Runtime.CompilerServices.Closure' from assembly 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. (System.TypeLoadException)
Traceback (most recent call last):
  File "c:\code\HWBuild\support\hwlibs\Questa.hwlib.py", line 55, in final
SystemError: Could not load type 'System.Runtime.CompilerServices.Closure' from assembly 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.```

Unless I'm doing something wrong...?

[slozier]

Unfortunately the System.Core facade of .NET Core does not type-forward System.Runtime.CompilerServices.Closure.

[cwensley]

Looks like there's some movement in the ability to save assemblies in .NET 8 dotnet/runtime#62956

In the meantime, is there any way one would be able to compile using NET4x but then run in .NET Core? Perhaps removing the use of types like System.Runtime.CompilerServices.Closure may be able to get it to run.

This is a pretty big blocker for us to run precompiled ironpython modules and would appreciate any help here, or if someone could point us in the right direction where we might be able to make those changes.

[slozier]

In the meantime, is there any way one would be able to compile using NET4x but then run in .NET Core? Perhaps removing the use of types like System.Runtime.CompilerServices.Closure may be able to get it to run.

Unfortunately the Closure stuff is done under the hood so outside of somehow re-writing the DLL to pick up the type from another assembly I don't have any great ideas.

[cwensley]

Hey @slozier, thanks so much for the feedback. I'll explore the option of rewriting the assembly.

When you say "under the hood", do you mean something in .NET Framework? What exactly is writing/generating that code? I wonder how that code would look if it was generated in .net core. 🤔

[slozier]

@cwensley Yeah, as far as I know, the Closure type isn't used anywhere in IronPython or the DLR so it's not something we can just remove. I believe the .NET Framework is adding it when it's compiling the lambda expressions...

Anyway, I did try some DLL hackery on a very simple example and managed to get something to run on .NET 6:

1. I added the System.Runtime.CompilerServices.Closure type to the .NET version IronPython.dll.
2. Compiled the python code using clr.CompileModules.
3. Using dnSpy, I updated the ResolutionScope of the TypeRef of Closure to point to the IronPython and then saved the DLL. Changing the DLL so Closure comes from IronPython instead of System.Core is basically just changing one byte so probably don't even need dnSpy to do it.
4. Loaded up the assembly in .NET and it worked.

[cwensley]

Thanks @slozier, that sounds very promising! At the very least we should be able to load precompiled python scripts when running in .NET Core by using something like Mono.Cecil to replace that type. Hopefully it's the only one.