COR_E_INVALIDOPERATION when running release branch

[rogerlord]

Environment

• Pythonnet version: release branch
• Python version: 3.7.14
• Operating System: Debian Bullseye (running under Windows Subsystem for Linux 2, Ubuntu 20.04, on Windows 10 21H2)
• .NET Runtime: .NET Core 3.1.29

Details

I am trying to load the CoreCLR with the following statements:

from pythonnet import load  
load("coreclr", runtime_config="pythonnet.json")     

where pythonnet.json contains the following:

{
  "runtimeOptions": {
   "tfm": "netcoreapp3.1",
   "framework": {
    "name": "Microsoft.NETCore.App",
    "version": "3.1.29"
    }
   }
}

The error message I get is as follows (note - the same happens if I try using .NET 6.0 instead of .NET Core 3.1):

Python 3.7.14 (default, Sep 13 2022, 02:30:55)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pythonnet import load
>>> load("coreclr", runtime_config="pythonnet.json")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/root/pythonnet/pythonnet/__init__.py", line 137, in load
    func = assembly.get_function("Python.Runtime.Loader.Initialize")
  File "/usr/local/lib/python3.7/site-packages/clr_loader/types.py", line 94, in get_function
    return ClrFunction(self._runtime, self._path, name, func)
  File "/usr/local/lib/python3.7/site-packages/clr_loader/types.py", line 58, in __init__
    self._callable = runtime._get_callable(assembly, typename, func_name)
  File "/usr/local/lib/python3.7/site-packages/clr_loader/hostfxr.py", line 101, in _get_callable
    check_result(res)
  File "/usr/local/lib/python3.7/site-packages/clr_loader/util/__init__.py", line 42, in check_result
    raise error
clr_loader.util.clr_error.ClrError: 0x80131509: COR_E_INVALIDOPERATION => An operation is not legal in the current state.

Attached the docker file I am using to build PythonNet and subsequently run the above statements in it.

[rogerlord]

The Dockerfile that was used is as follows:

FROM python:3.7-slim

USER root
SHELL ["/bin/bash", "-c"]

RUN apt-get update -y && apt-get install --no-install-recommends -y \
	dirmngr \
	gnupg \
	apt-transport-https \
	ca-certificates \
	software-properties-common \
	gpg \
	wget \
	nano &&
	rm -rf /var/lib/apt/lists/*

RUN wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
RUN dpkg -i packages-microsoft-prod.deb
RUN rm packages-microsoft-prod.deb

RUN apt-get update && \
	apt-get install -y dotnet-sdk-3.1

# Install requirements for building PythonNet
RUN apt-get update && apt-get install --no-install-recommends -y \
	clang \
	libglib2.0-dev \
	git \
	build-essential \
	python3-dev && \
	rm -rf /var/lib/apt/lists/*

WORKDIR /root/
RUN git clone https://github.com/pythonnet/pythonnet && cd ./pythonnet && git checkout release && pip install -r requirements.txt && pip install -v ./

CMD [ "/bin/bash" ]

[filmor]

A few up-front comments on the docker file:

• There is an \ missing after nano &&, are you sure that this is the exact same file that you used for testing?
• Python.NET does not require any of those packages anymore
• The package updates result in Python getting updated to 3.9, if I see that correctly

[filmor]

I can't reproduce the error. With the following Dockerfile, everything works as expected:

FROM python:3.7-slim

USER root
SHELL ["/bin/bash", "-c"]

RUN apt-get update -y && apt-get install --no-install-recommends -y \
        dirmngr \
        gnupg \
        apt-transport-https \
        ca-certificates \
        software-properties-common \
        gpg \
        wget \
        nano \
    git && \
        rm -rf /var/lib/apt/lists/*

RUN wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.deb && \
    dpkg -i packages-microsoft-prod.deb && \
    rm packages-microsoft-prod.deb

RUN apt-get update && apt-get install -y dotnet-sdk-3.1 && \
    rm -rf /var/lib/apt/lists/*

WORKDIR /root/
RUN git clone https://github.com/pythonnet/pythonnet && cd ./pythonnet && git checkout release && pip install -r requirements.txt && pip install -v ./

CMD [ "/bin/bash" ]

[rogerlord]

Hi @filmor - apologies for the omission of the . I tried your slimmer container, and still get the same results unfortunately (see below). Wondering what it could be that's causing it... are you running it on a Windows machine as well?

Python 3.7.14 (default, Sep 13 2022, 02:30:55)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pythonnet import load
>>> load("coreclr", runtime_config="pythonnet.json")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/root/pythonnet/pythonnet/__init__.py", line 137, in load
    func = assembly.get_function("Python.Runtime.Loader.Initialize")
  File "/usr/local/lib/python3.7/site-packages/clr_loader/types.py", line 94, in get_function
    return ClrFunction(self._runtime, self._path, name, func)
  File "/usr/local/lib/python3.7/site-packages/clr_loader/types.py", line 58, in __init__
    self._callable = runtime._get_callable(assembly, typename, func_name)
  File "/usr/local/lib/python3.7/site-packages/clr_loader/hostfxr.py", line 101, in _get_callable
    check_result(res)
  File "/usr/local/lib/python3.7/site-packages/clr_loader/util/__init__.py", line 42, in check_result
    raise error
clr_loader.util.clr_error.ClrError: 0x80131509: COR_E_INVALIDOPERATION => An operation is not legal in the current state.

[rogerlord]

@filmor - I can confirm that on a Linux machine (Ubuntu 20.04.4 LTS) I don't have the above issue. I will see if I can do some more investigations on what could be causing it - if you want more information from me to help narrow it down, let me know.

[rogerlord]

Hi @filmor - after a few reboots and recent commits to the release branch this problem has been solved by the looks of it. It's most likely some state of my machine or Windows / Linux interoperability that was being triggered, because I went back to the state of the release branch on Sunday, and can confirm that works too.

So as far as I'm concerned this can be closed...

[filmor]

Sounds good to me :)