pywebview / pythonnet runtime auto-adaptation issue report
Summary
On Windows, pythonnet currently defaults to netfx when PYTHONNET_RUNTIME is not explicitly set. In environments where netfx fails but coreclr works, this leads to startup failures for applications that rely on pythonnet through pywebview.
I suggest that pythonnet should automatically detect whether netfx or coreclr is available and switch to the working runtime instead of relying on the current Windows default.
Environment
- OS: Windows 10/11
- Python: 3.12.9
- pythonnet: 3.0.5
- clr_loader: 0.2.10
- pywebview: 6.2.1
Observed behavior:
pythonnet.load() without PYTHONNET_RUNTIME fails
PYTHONNET_RUNTIME=coreclr works successfully
Problem description
When PYTHONNET_RUNTIME is not set, pythonnet uses the following default logic:
def set_runtime_from_env() -> None:
from os import environ
spec = environ.get("PYTHONNET_RUNTIME", "default")
runtime = _create_runtime_from_spec(spec)
set_runtime(runtime)
And inside _create_runtime_from_spec():
if spec == "default":
was_default = True
if sys.platform == "win32":
spec = "netfx"
else:
spec = "mono"
So on Windows, pythonnet always tries netfx first.
In my case, that default fails with:
RuntimeError: Failed to resolve Python.Runtime.Loader.Initialize
from ...\pythonnet\runtime\Python.Runtime.dll
But if I explicitly set:
os.environ['PYTHONNET_RUNTIME'] = 'coreclr'
then pythonnet.load() succeeds.
Why this is a problem
netfx is the legacy .NET Framework runtime, while coreclr is the modern .NET runtime. On Windows, many systems now have coreclr available and working, while netfx may fail due to runtime/assembly compatibility issues.
For applications that use pywebview on Windows, the startup path often triggers pythonnet indirectly. If pythonnet chooses the wrong runtime by default, the entire GUI startup fails.
This makes the default behavior fragile for modern Windows environments.
What netfx and coreclr mean
netfx
netfx refers to .NET Framework, the older Windows .NET runtime.
Characteristics:
- Primarily for Windows
- Depends on the system-installed .NET Framework
- Common in older projects, WinForms, WPF, and legacy desktop assemblies
- Stable for legacy compatibility, but older in design
coreclr
coreclr refers to .NET Core / modern .NET runtime.
Characteristics:
- Microsoft’s newer cross-platform runtime
- Works on Windows, Linux, and macOS
- Modern .NET libraries and assemblies typically use this path
- Better aligned with current .NET ecosystem direction
Suggested improvement
I recommend that pythonnet add automatic runtime detection on Windows, such as:
- Try
netfx
- If
netfx fails to load or initialize, automatically fall back to coreclr
- Optionally allow explicit override through
PYTHONNET_RUNTIME
A smarter auto-detection flow could look like:
- If
PYTHONNET_RUNTIME is set, respect it
- Otherwise, on Windows:
- try
netfx
- if initialization fails, try
coreclr
- On non-Windows:
- continue with the current platform-specific default
This would make the library much more robust in real-world applications.
Expected result
With auto-adaptation in place:
- Users would not need to manually set
PYTHONNET_RUNTIME
- Startup would succeed more often on Windows
- Applications using
pywebview would avoid unnecessary crashes caused by runtime selection
- Compatibility would be improved for both legacy and modern Windows environments
Actual result
Without manual override:
pythonnet defaults to netfx on Windows
netfx may fail to initialize
- Applications crash during startup
With manual override:
PYTHONNET_RUNTIME=coreclr
- startup succeeds
Reproduction steps
Failing case
C:\D\Github-Project\GJ_GenericAgent\python\python.exe -c "import pythonnet; pythonnet.load()"
Result:
- fails with
Failed to resolve Python.Runtime.Loader.Initialize
Working case
C:\D\Github-Project\GJ_GenericAgent\python\python.exe -c "import os; os.environ['PYTHONNET_RUNTIME']='coreclr'; import pythonnet; pythonnet.load(); print('ok')"
Result:
Conclusion
The current Windows default of netfx is too rigid for modern setups.
I suggest pythonnet implement automatic runtime detection and fallback between netfx and coreclr so that applications can start reliably without manual environment configuration.
pywebview / pythonnet runtime auto-adaptation issue report
Summary
On Windows,
pythonnetcurrently defaults tonetfxwhenPYTHONNET_RUNTIMEis not explicitly set. In environments wherenetfxfails butcoreclrworks, this leads to startup failures for applications that rely onpythonnetthroughpywebview.I suggest that
pythonnetshould automatically detect whethernetfxorcoreclris available and switch to the working runtime instead of relying on the current Windows default.Environment
Observed behavior:
pythonnet.load()withoutPYTHONNET_RUNTIMEfailsPYTHONNET_RUNTIME=coreclrworks successfullyProblem description
When
PYTHONNET_RUNTIMEis not set,pythonnetuses the following default logic:And inside
_create_runtime_from_spec():So on Windows,
pythonnetalways triesnetfxfirst.In my case, that default fails with:
But if I explicitly set:
then
pythonnet.load()succeeds.Why this is a problem
netfxis the legacy .NET Framework runtime, whilecoreclris the modern .NET runtime. On Windows, many systems now havecoreclravailable and working, whilenetfxmay fail due to runtime/assembly compatibility issues.For applications that use
pywebviewon Windows, the startup path often triggerspythonnetindirectly. Ifpythonnetchooses the wrong runtime by default, the entire GUI startup fails.This makes the default behavior fragile for modern Windows environments.
What
netfxandcoreclrmeannetfxnetfxrefers to .NET Framework, the older Windows .NET runtime.Characteristics:
coreclrcoreclrrefers to .NET Core / modern .NET runtime.Characteristics:
Suggested improvement
I recommend that
pythonnetadd automatic runtime detection on Windows, such as:netfxnetfxfails to load or initialize, automatically fall back tocoreclrPYTHONNET_RUNTIMEA smarter auto-detection flow could look like:
PYTHONNET_RUNTIMEis set, respect itnetfxcoreclrThis would make the library much more robust in real-world applications.
Expected result
With auto-adaptation in place:
PYTHONNET_RUNTIMEpywebviewwould avoid unnecessary crashes caused by runtime selectionActual result
Without manual override:
pythonnetdefaults tonetfxon Windowsnetfxmay fail to initializeWith manual override:
PYTHONNET_RUNTIME=coreclrReproduction steps
Failing case
Result:
Failed to resolve Python.Runtime.Loader.InitializeWorking case
Result:
okConclusion
The current Windows default of
netfxis too rigid for modern setups.I suggest
pythonnetimplement automatic runtime detection and fallback betweennetfxandcoreclrso that applications can start reliably without manual environment configuration.