我的应用程序不受管理。我从哪里开始引入托管代码？
我的整个应用程序（相当大，有 20MB 可执行文件）是用非托管 C++ 编写的。 因为我可以清楚地看到使用托管代码的优势，所以我想开始在我的应用程序中引入托管代码，但从哪里开始呢？
我可以轻松开始使用 C++/CLI 并将其与应用程序的其余部分链接吗？ （尽管 C++/CLI 语法看起来相当“异国情调”）。
或者迁移到 C# 更好，但是将其与我的非托管 C++ 代码“链接”在一起的最佳方法是什么？
使用 /clr 选项编译我的所有 C++ 代码是否有意义？这行得通吗？
我需要担心编组吗？这是否会产生开销，或者我可以在托管和非托管之间切换而不影响性能（就像 20 年前我混合使用 Fortran 和 C 时所做的那样）。性能在我的应用程序中非常重要，因为它是一个科学应用程序，有时会处理几千兆字节的内存。
或者只有重新设计用户界面才有意义，并且只用 C# 编写，并将应用程序的其余部分（计算逻辑、业务逻辑、数据库接口，...）保留在非托管 C++ 中？
由于我的应用程序有时需要处理几 GB 的内存，因此我有一个 64 位变体。拥有 64 位托管代码容易吗？如果使用那么多内存，垃圾收集器是否仍然有效？
简单地说：我从哪里开始？
帕特里克
My whole application (which is rather big, with a 20MB executable) is written in unmanaged C++.
Because I can clearly see the advantages in using managed code, I want to start introducing managed code in my application, but where do I start?
Can I easily start to use C++/CLI and link it with the rest of my application? (although the C++/CLI syntax seems rather 'exotic').
Or is it better to move to C#, but what is the best way to 'link' this together with my unmanaged C++ code?
Does it make sense to compile all my C++ code with the /clr option? Will this work?
Do I have to worry about marshalling? Does this give an overhead or can I switch between managed and unmanaged without a performance penalty (just as I did 20 years ago when mixing fortran and C). Performance is really important in my application since it is a scientific application that sometimes processes several Gigabytes of memory.
Or does it only make sense to redesign the user interface, and only write this in C#, and keep the rest of my application (calculation logic, business logic, database interface, ...) in unmanaged C++?
Since my application sometimes needs to handle several Gigabytes of memory, I have a 64-bit variant. Is it easy to have 64-bit managed code? Woudl the garbage collector be still efficient if that much memory is used?
Simply state: where do I start?
Patrick
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对应用程序进行分析，决定在哪些集成点可以脱离 C# 逻辑线并进入 C++，反之亦然。将这些安排到一个计划中，让外观设计模式在系统中逐步采用 C# 取代 C++。当决定在每个候选外观/界面切换语言时，最值得关注的是 CPU 和内存成本。
您将希望能够合并编辑，因此您可能最好使用一个源代码集和源代码存储库来存储原始 C++ 代码，并使用另一组和存储库来存储外观和 C#。
然后，当增强/维护工作进入收件箱时，您将其应用到两个代码库，并尝试确保外观在系统中移动，从增强或维护中最不可能更改的代码开始，以尽量减少双倍的更改工作。
还可以理想地构建您的工作，以便在遇到障碍时可以立即回滚到 100% C++。
要测试是否可以将几个特别难以理解的 C++ 模块分为 C++ 部分和 C# 部分，请在使用管道或套接字进行通信的两个不同的 Win32 C++ 进程中运行它们。这样，您可以更好地了解内存管理或性能是否存在需要修复的问题，然后才能拆分调用链。
Profile the app, decide at what integration points you can snap off the C# line of logic and break into C++ and vice versa. Arrange these into a plan to have a Facade design pattern move through the system gradually replacing C++ with C#. Of key concern is the CPU and memory cost when deciding to switch languages at each candidate Facade / interface.
You will want to be able to incorporate edits so you might be best off with one source code set and source code repository for the original C++ code and another set and repository for the facade plus the C#.
Then as enhancements/maintenance work comes in the in-tray you apply it to both code bases, and you try to make sure the facade moves through the system starting with the code least likely to change in enhancements or maintenance to minimise doubling of changes work.
Also ideally structure your work so you can rollback the facade to go back to 100% C++ at the drop of a hat if you hit a snag.
To test whether a couple of particularly inscrutable C++ modules can be separated into a C++ piece and a C# piece, run them in two different Win32 C++ processes communicating using a pipe or a socket. That way you'll get a better idea of whether there are problems with memory management or performance that need fixing before you can split the call chain at that point.
我们完全按照您在数千名用户使用的关键任务应用程序中所描述的方式进行操作。基本上，我们保持现有应用程序原样，因此可执行文件仍然是 100% 非托管可执行文件（不是 C++/CLI）。然后，我们将所有新的 C# 代码放入 .NET dll 中，其中包含业务对象、用户控件和 GUI 代码等......
基本上，所有新代码都是用 C# 编写的。我们有 1 个 dll，它是 C++/CLI，只是胶水。这让我们可以轻松地在托管代码和非托管代码之间进行互操作，而无需对现有的 C++ 代码进行 clr。这限制了我们必须编写的 C++/CLI 代码量。本机代码与混合模式代码对话，混合模式代码可以与托管代码对话。混合模式 dll 可以挂钩 C# 类上的事件，因此 C# 代码可以触发事件来与 C++/CLI（可以与本机代码对话）进行通信。
我们还可以在现有的 C++ 应用程序中托管 .NET UserControls（无论如何，WinForms 只是 WINAPI 的包装器，因此它工作得很好）。
这非常有效，让您可以保留现有代码，而不必用 C# 重写整个 GUI。
We do exactly what you described in a mission critical application that is used by thousands of users. Basically, we kept the existing application as is, so the executable is still a 100% unmanaged executable (not C++/CLI). We then put all of our new C# code in .NET dlls which consists of business objects, user controls and gui code, etc....
Basically, all new code is written in C#. We have 1 dll that is C++/CLI that is just glue. This lets us easily interop between the managed and unmanaged code, without having to make the existing C++ code clr. This limits the amount of C++/CLI code we have to write. The native code talks to the mixed mode code, which can talk to the managed code. The mixed mode dll can hook events on the C# classes so the C# code can just fire the event to communicate to the C++/CLI (which can talk to the native code).
We can also host .NET UserControls in an existing C++ app (WinForms is just a wrapper around the WINAPI anyway, so it works pretty well).
This works very well and lets you keep your existing code without having to rewrite the entire GUI in C#.
目前，这个问题已经结束了。
我意识到答案不是混合 C++ 和 C#，而是首先获得正确的架构。
如果架构正确，并且在需要分离的地方进行分离，那么通过其他模块（外部、其他语言等）更改应用程序的部分应该更容易。
关于编组过程中的性能问题，还得等到.Net进一步成熟之后再说。
For the moment, consider this question closed.
I realized that the answer is not mixing C++ and C#, but getting the architecture right in the first place.
If the architecture is correct, and separated where it needs to be separated, than changing parts of the application by other modules (external, other language, ...) should be easier.
Regarding the performance problems during marshalling, we will have to wait until .Net has further matured.