3 ms·

Agreed. I had the exact same question. From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writin

Agreed. I had the exact same question. From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code)." I don't understand what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it.

delta_p_delta_x 2y ago
> I don't understand what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it. I don't think the author is talking about interop here, but rather the fact that GUI front-end code written in C++/CLI still ends up being managed rather than compiled to native code. I suppose the author insists on the front-end executable being nothing but a PE x86-64 binary without any runtime/GC embedded in it, pure native code.
- alkonaut 2y ago
  That insistence isn’t motivated in the post in any way, which makes it a really weird and arbitrary requirement.
smileybarry 2y ago
C++/CLI is managed code, it’s basically C++ compiled into .NET IL. If you’re writing C++ code running on .NET / .NET Framework, you’re basically writing masochistic C#.
- alkonaut 2y ago
  But why even use C++ for the front end if it’s going to be .NET? Managed C++ is mostly useful as a shim, not as a platform language. It’s not really an alternative to C# on the .NET runtime but just some C++ extensions for interop with it. If you make a WPF/WinForms frontend then that should be the exe entry point, and that would likely be managed. Then your business logic would be the auxiliary DLL (which can be embedded into the managed exe). There could be a layer of C++/CLI between these to layers (C# front end and native backend) because it would make the interop a bit easier than having to do C-style interop.
  - smileybarry 2y ago
    > But why even use C++ for the front end if it’s going to be .NET? Because the author of the article wanted to use C++, I don’t know why. That’s why I called it “masochistic C#”.
- pjmlp 2y ago
  Actually I find it much easier to write C++/CLI, than getting right all P/Invoke marshaling, specially if COM is also part of the picture. Also C++/CLI can also generate native code when specific code patters are used, that is why there are some compiler flags to disable it, and such assemblies are considered unsafe.
TheDudeMan 2y ago
Same here. People are confused because the author gave two options: 1. Bundle the .dll as a resource into the app and make it extract it to some temporary folder, then use P/Invoke and call the compiled .dll from within the C#/.NET app. 2. Use C++/CLI. And then a single "problem" paragraph that didn't make it clear which problems go with which approach.

delta_p_delta_x 2y ago

> I don't understand what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it. I don't think the author is talking about interop here, but rather the fact that GUI front-end code written in C++/CLI still ends up being managed rather than compiled to native code. I suppose the author insists on the front-end executable being nothing but a PE x86-64 binary without any runtime/GC embedded in it, pure native code.

alkonaut 2y ago
That insistence isn’t motivated in the post in any way, which makes it a really weird and arbitrary requirement.

smileybarry 2y ago

C++/CLI is managed code, it’s basically C++ compiled into .NET IL. If you’re writing C++ code running on .NET / .NET Framework, you’re basically writing masochistic C#.

alkonaut 2y ago
But why even use C++ for the front end if it’s going to be .NET? Managed C++ is mostly useful as a shim, not as a platform language. It’s not really an alternative to C# on the .NET runtime but just some C++ extensions for interop with it. If you make a WPF/WinForms frontend then that should be the exe entry point, and that would likely be managed. Then your business logic would be the auxiliary DLL (which can be embedded into the managed exe). There could be a layer of C++/CLI between these to layers (C# front end and native backend) because it would make the interop a bit easier than having to do C-style interop.
- smileybarry 2y ago
  > But why even use C++ for the front end if it’s going to be .NET? Because the author of the article wanted to use C++, I don’t know why. That’s why I called it “masochistic C#”.
pjmlp 2y ago
Actually I find it much easier to write C++/CLI, than getting right all P/Invoke marshaling, specially if COM is also part of the picture. Also C++/CLI can also generate native code when specific code patters are used, that is why there are some compiler flags to disable it, and such assemblies are considered unsafe.

TheDudeMan 2y ago

Same here. People are confused because the author gave two options: 1. Bundle the .dll as a resource into the app and make it extract it to some temporary folder, then use P/Invoke and call the compiled .dll from within the C#/.NET app. 2. Use C++/CLI. And then a single "problem" paragraph that didn't make it clear which problems go with which approach.