3 ms·

As of now, I think almost the entirety of WinRT should be accessible from .NET via https://github.com/microsoft/CsWinRT https://github.com/microsoft/CsWinRT Th

As of now, I think almost the entirety of WinRT should be accessible from .NET via https://github.com/microsoft/CsWinRT https://github.com/microsoft/CsWinRT There is also a pre-release which enables NativeAOT support (note that AOT compatibility there is driven by individual engineers that want to make it happen, there are no "instituted from above" projects regarding it but I may be wrong)

pjmlp 2y ago
There are still no proper bindings for DirectX, Win2D (full API surface as in C++ UWP version), Windows 11 context menus, shell extensions, and plenty other stuff. Additionally the folks in WinAppSdk apparently never used .NET as they keep coming up with writing C in C# APIs. It wasn't after lots of complaints that WinUI 3.0 Windows, finally got as usable from .NET as in Forms and WPF, instead of the calling directly Win32 boilerplate. Kudos to those engineers, unfortunately it has been the .NET story on WinDev side, many would rather that their world would have kept being VB 6, MFC and ATL. There is even a Build session on this. Even projects like Managed DirectX and XNA, grew out of such engineers, only to die after they weren't no longer around to argue for them, and DirectX TK was born.
- neonsunset 2y ago
  There are*: https://github.com/dotnet/Silk.NET https://github.com/dotnet/Silk.NET, https://github.com/terrafx https://github.com/terrafx and https://github.com/microsoft/Win2D https://github.com/microsoft/Win2D Now, I don't know (or care, to be fair) about the internal aspect of the culture on what is in vogue in various MSFT teams, but there is a rich ecosystem of libraries in .NET to massively simplify interaction with pretty much anything that can be called from C or C++ on Windows. * Not sure about Windows 11 shell integration, but I'm generally unhappy with the way W11 is - what kept me on Windows were games and certain Visual Studio extensions, and with both issues being almost completely addressed on Linux (and on macOS too, surprisingly, with the latest GPTK2), it is time to move.
  - pjmlp 2y ago
    They aren't from WinDev, rather those valiant engineer efforts. There are many Windows APIs that cannot be cannot directly, because they expect C or C++ semantics, hence why there are enough wrapper libraries that still reach out to C++/CLI to ease the task. Additionally anything that requires in-proc COM, or apartment threading models not supported on .NET, can only be implemented in C and C++. Eventually Rust. Usually the work around is to implement the binding glue in C++ and then RPC into a .NET process, if one is really keen in using .NET for such use cases. That is something that isn't covered by Native AOT, and was supported by .NET Native in WinRT, mostly because deep down .NET on WinRT is like VB 6 with COM, and not regular .NET.
    - neonsunset 2y ago
      I don't think there is anything left that is actively maintained and production-grade (e.g. above packages) that uses C++/CLI. It is important to acknowledge that it did and still does exist, but I'm unaware of anyone seriously using it over regular C# + P/Invoke (generated or otherwise). .NET has COM interop (from its inception?). In .NET 6, a newer ComWrappers API was introduced, which then also gained the capability to be source-generated to work with AOT in .NET 8. Links: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/cominterop https://learn.microsoft.com/en-us/dotnet/standard/native-int... https://learn.microsoft.com/en-us/dotnet/standard/native-interop/com-wrappers https://learn.microsoft.com/en-us/dotnet/standard/native-int... https://learn.microsoft.com/en-us/dotnet/standard/native-interop/comwrappers-source-generation https://learn.microsoft.com/en-us/dotnet/standard/native-int...
      - pjmlp 2y ago
        You are not seeing inside every company in the world that is doing Windows development. The COM interop in .NET is mostly for consumption, not implementation, other than other userspace applications, Office automation style. For the Windows extension points that use COM, writing those implementations in COM is not an option, when they are, again, in-proc COM, and use apartment models not covered by interop. I use .NET since the prerelease days, when it was only available to MSDN partners with draft documentation written in red, and Windows itself since 3.0, you won't tell me nothing on Windows system programming that I haven't seen before.

pjmlp 2y ago

There are still no proper bindings for DirectX, Win2D (full API surface as in C++ UWP version), Windows 11 context menus, shell extensions, and plenty other stuff. Additionally the folks in WinAppSdk apparently never used .NET as they keep coming up with writing C in C# APIs. It wasn't after lots of complaints that WinUI 3.0 Windows, finally got as usable from .NET as in Forms and WPF, instead of the calling directly Win32 boilerplate. Kudos to those engineers, unfortunately it has been the .NET story on WinDev side, many would rather that their world would have kept being VB 6, MFC and ATL. There is even a Build session on this. Even projects like Managed DirectX and XNA, grew out of such engineers, only to die after they weren't no longer around to argue for them, and DirectX TK was born.

neonsunset 2y ago
There are*: https://github.com/dotnet/Silk.NET https://github.com/dotnet/Silk.NET, https://github.com/terrafx https://github.com/terrafx and https://github.com/microsoft/Win2D https://github.com/microsoft/Win2D Now, I don't know (or care, to be fair) about the internal aspect of the culture on what is in vogue in various MSFT teams, but there is a rich ecosystem of libraries in .NET to massively simplify interaction with pretty much anything that can be called from C or C++ on Windows. * Not sure about Windows 11 shell integration, but I'm generally unhappy with the way W11 is - what kept me on Windows were games and certain Visual Studio extensions, and with both issues being almost completely addressed on Linux (and on macOS too, surprisingly, with the latest GPTK2), it is time to move.
- pjmlp 2y ago
  They aren't from WinDev, rather those valiant engineer efforts. There are many Windows APIs that cannot be cannot directly, because they expect C or C++ semantics, hence why there are enough wrapper libraries that still reach out to C++/CLI to ease the task. Additionally anything that requires in-proc COM, or apartment threading models not supported on .NET, can only be implemented in C and C++. Eventually Rust. Usually the work around is to implement the binding glue in C++ and then RPC into a .NET process, if one is really keen in using .NET for such use cases. That is something that isn't covered by Native AOT, and was supported by .NET Native in WinRT, mostly because deep down .NET on WinRT is like VB 6 with COM, and not regular .NET.
  - neonsunset 2y ago
    I don't think there is anything left that is actively maintained and production-grade (e.g. above packages) that uses C++/CLI. It is important to acknowledge that it did and still does exist, but I'm unaware of anyone seriously using it over regular C# + P/Invoke (generated or otherwise). .NET has COM interop (from its inception?). In .NET 6, a newer ComWrappers API was introduced, which then also gained the capability to be source-generated to work with AOT in .NET 8. Links: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/cominterop https://learn.microsoft.com/en-us/dotnet/standard/native-int... https://learn.microsoft.com/en-us/dotnet/standard/native-interop/com-wrappers https://learn.microsoft.com/en-us/dotnet/standard/native-int... https://learn.microsoft.com/en-us/dotnet/standard/native-interop/comwrappers-source-generation https://learn.microsoft.com/en-us/dotnet/standard/native-int...
    - pjmlp 2y ago
      You are not seeing inside every company in the world that is doing Windows development. The COM interop in .NET is mostly for consumption, not implementation, other than other userspace applications, Office automation style. For the Windows extension points that use COM, writing those implementations in COM is not an option, when they are, again, in-proc COM, and use apartment models not covered by interop. I use .NET since the prerelease days, when it was only available to MSDN partners with draft documentation written in red, and Windows itself since 3.0, you won't tell me nothing on Windows system programming that I haven't seen before.