@filmor tested this with my end users, it indeed works just fine

Are any tests expected for this PR?

My bad, I should've checked the behavior on .NET Core too. @filmor could you please approve the workflows to run again?

Bump, just need tests to be approved to run.

Is there any way I can help speed up the review/merge?

@filmor sorry for bothering, any ETA on the merge?

Two issues:

1. The new csproj is missing from the manifest, I'll fix that.
2. This increases the wheel size substantially. Seeing that you seem to be the only one who needs this, would it work for you if our distributed wheels were still built directly and you could build your own wheel with an environment variable for internal distribution? Do you even need the wheels?

1. Thanks for the help, overlooked this one.

2. The wheels are a preferred choice. If it's a critical thing, I can of course point uv to git, however, it's more trouble than just pre-built wheels, so I'd be happy if it was available on pypi. For example, uv caching caused issues with tag-based versioning when I was building the packages from source and did a partial fork, which cost me some hours figuring out what the issue was. I am sure there are other hidden nuances like this one.

   (I was sure that there's an ability to ship "variants" of a wheel, but turns out it was just extra packages via package[extra] syntax. Not sure if it's possible to have somehting like pythonnet[net461], it looks like not).

   Initialize() crash from .NET Framework application #2205 SerializationException when PythonEngine.Shutdown() #2221 Cannot import pandas in pythonnet #2222 python lambda doesn't match expression lambda #2425 seem all to be mentioning 4.6.1 in environment and are past 3.0. Likely not every user submits an issue, yet alone a PR to fix the issue, so I don't think I am the only one; there are probably other users who would benefit from this.

   As for the size increase - I checked, and the size seems to be increased from 0.2 MB to 1.6 MB. I feel like on an absolute scale even after increase that's negligible in 2026. Popular packages like numpy, pandas, cryptography are all multple megabytes worth, like 2-10 MB, and I've never heard this to be a problem.

Well, I don't want to join the large-package-size cohort if not necessary. Wheel variants don't exist, yet (there is an open PEP on this), otherwise that would have been the preferred way.

I think I will simply add a Windows wheel build that includes the .NET 4.6, then at least we don't carry all of the shim DLLs around on other platforms.

@lostmsu, what is your take on this?

I feel like I am missing something, is 1.6 MB really that large? to me it looks like an increase from microscopic to just small 🤔

That works too, of course, just wondering if there's really a point in keeping it separate.