search

MHDante / pythonnet-stub-generator

Creates Python Type Hints for Python.NET libraries
MIT License
19 stars 9 forks source link

.net 8 compatability #5

Open elan-slovelock opened 5 months ago

elan-slovelock commented 5 months ago

There is an issue when trying to generate stubs for target runtimes > .net 6. See the output before for the .net 8 case. According to https://github.com/dotnet/sdk/issues/9917 it seems like a tool has to have a single fixed framework version. I wonder if it makes sense to update to .net 8 now as that should allow stub generation for .net 8 and below. It would mean whoever currently uses it will need to ensure they also have .net 8, but I think it is worth it for the future of the project.

error: failed generating stubs | Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at System.Reflection.RuntimeAssembly.GetExportedTypes()
   at PythonNetStubGenerator.StubBuilder.BuildAssemblyStubs(DirectoryInfo destPath, FileInfo[] targetAssemblyPaths, DirectoryInfo[] searchPaths) in C:\Repos\pythonnet-stub-generator\csharp\PythonNetStubGenerator\StubBuilder.cs:line 30
   at PythonNetStubTool.Program.Main(DirectoryInfo destPath, String targetDlls, DirectoryInfo[] searchPaths) in C:\Repos\pythonnet-stub-generator\csharp\PythonNetStubTool\Program.cs:line 42
MHDante commented 5 months ago

Yes, I think it's worth updating the tool to .NET 8.

Technically, any user should work as long as the TFM of the target library works with .net8. The tool itself can be of a higher TFM than the project it was used in. (e.g. I mainly used this in unity which is a 4.5 offshoot)

I think this outlines a major implementation issue with the way this tool works in that it loads the assembly of the dll that it is targeting. This means that the TFM of the loaded assembly needs to be a subset of the TFM of the tool. See here for more info: https://learn.microsoft.com/en-us/dotnet/standard/frameworks#net-5-os-specific-tfms

This means that this tool has almost no chance of supporting OS-Specific TFMs without it being rebuilt from source.

I think there's two ways to ameliorate the situation long-term: 1) move the logic into an assembly that is called into by a configurable entry point that loaded the appropriate frameworks. 2) It may have been a better idea to use some sort of metadata extraction process that avoids loading the assembly.

If I'm able to find some help, I will look either of these. (Likely for a V2)

In the meantime, I will check to see if there are any problems with the upgrade and publish a new version. I'm a bit busy at the moment, so it might be a week or two.

(Might as well go up to .NET 9 🤭)