2 ms·

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 th

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.
- neonsunset 2y ago
  It can go both ways, there are engineers who use their prior knowledge to understand where the design principles come from yet acknowledge the current state of affairs and there are engineers which use it as an excuse to ignore anything that happened past their active learning phase. I worked with sufficient amount of the latter type to remind myself everyday to be wary of this failure mode, and to appreciate the former when such people do come by.
  - pjmlp 2y ago
    I agree, but hardly any of your replies were into the sense of what WinDev is doing to support .NET on Windows like Swift are Java/Kotlin are on their respective platforms, instead of their usual COM and C++ agenda, rather what DevDiv, rogue engineers we should be thankful for their sice project efforts, and FOSS .NET community. Yes the community is doing lots, WinDev is not.
    - neonsunset 2y ago
      My goal was to provide context on what is out there in terms of consumption of Windows APIs (many people are hand-rolling bindings, where they could have added CsWin32/Rt and two lines to an imports file, or write a complex C++ sandwich for DX12 where they could have consumed it, effectively, directly) and to that extent it is achieved :) We don't know what is current WinDev situation, FWIW COM interop changes in .NET are "official" rather than grassroots, but then again, MSFT is pretty much a huge conglomerate of smaller sized companies rather than a huge monolithic entity.

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.

neonsunset 2y ago
It can go both ways, there are engineers who use their prior knowledge to understand where the design principles come from yet acknowledge the current state of affairs and there are engineers which use it as an excuse to ignore anything that happened past their active learning phase. I worked with sufficient amount of the latter type to remind myself everyday to be wary of this failure mode, and to appreciate the former when such people do come by.
- pjmlp 2y ago
  I agree, but hardly any of your replies were into the sense of what WinDev is doing to support .NET on Windows like Swift are Java/Kotlin are on their respective platforms, instead of their usual COM and C++ agenda, rather what DevDiv, rogue engineers we should be thankful for their sice project efforts, and FOSS .NET community. Yes the community is doing lots, WinDev is not.
  - neonsunset 2y ago
    My goal was to provide context on what is out there in terms of consumption of Windows APIs (many people are hand-rolling bindings, where they could have added CsWin32/Rt and two lines to an imports file, or write a complex C++ sandwich for DX12 where they could have consumed it, effectively, directly) and to that extent it is achieved :) We don't know what is current WinDev situation, FWIW COM interop changes in .NET are "official" rather than grassroots, but then again, MSFT is pretty much a huge conglomerate of smaller sized companies rather than a huge monolithic entity.