我正在开发一个与之对话的项目，SQL Server并且大部分后端代码都在C++.
这是一个应用程序，可在将少量流体加载到载体中时控制它们的流动。与控制器通信的一些后端模块反过来控制流体的流动C++。由于它们存在内存泄漏和其他一些错误，因此已尝试将它们迁移到.Net.
我的理解是，当我们使用后端模块时，性能.Net会下降。所以我的意见不是将这些后端模块转换为 .Net，而是解决 C++ 本身的问题。
讨论中的代码是与控制器固件交互的应用程序。它基本上需要一些命令并从控制器获得响应。此代码没有 UI，并且相同的代码SQL也与之交互以更新数据。两者都是一个exe的一部分。
.Net当预期性能不严格时，被认为是好的。如果必须编写新代码，尤其是涉及 UI 设计时，这将是合适的。另一种思想流派是，.Net 适用于较高层，但不适用于多层架构中的较低层。
我想从不同的角度了解其他人的意见。需要考虑的一些方面是：
请从重写现有代码的角度发表评论。如果我们决定去做的话，这将是一对一的 C++ 行到 C# 的转换。
快速回答：
如果您有能够使用调试器并了解他们的应用程序域以及如何使用控制器的有能力的 C++ 程序员，那么仔细审查并修复内存错误和问题可能会更容易。毕竟，时间和精力已经花在代码上了，除非是琐碎的代码，否则用 C# 重写可能会引入新的逻辑错误。
OP的问题：
讨论中的代码是与控制器固件交互的驱动程序代码。它基本上需要一些命令并从控制器获得响应。此代码没有 UI，并且相同的驱动程序代码也与 SQL 交互以更新数据
您是在谈论您命名为“驱动程序”的用户模式软件，还是在谈论内核模式设备驱动程序？
如果您可以提供有关这些控制器运行控制流体流动的固件的更多信息，将会有所帮助。C++ 后端是否通过 RS232（串行）连接到控制器？以太网？USB？TCP/IP？PCI？
如果您通过 TCP/IP 或 RS232（串行）连接到控制器硬件，C#/.NET 可以很好地处理该任务。对于 USB、PCI、以太网等其他任何东西，您将需要一个设备驱动程序，该驱动程序必须根据驱动程序的要求用 C 或 C++ 编程。当然你可以封装 C++ 中的用户模式部分，或者封装直接调用 Win32，但它会给你的项目增加更多的开发任务。
显然，现有 C++ 代码的唯一问题是内存泄漏。
在我看来，这似乎不足以用 C# 重写它。
相反，我建议运行内存泄漏检测软件来查找泄漏。
“语言有其独特之处” 伙计，我需要一个拥抱，真的。不要因为代码写得不好而改变语言……编写更好的代码并使用可用的资源。
每种语言都有自己的特殊性，您应该找出最适合该场景的语言
不要因为一些错误而用不同的语言重写整个程序——新产品中只会有不同的错误，而问答周期将不得不重新开始。我会修复 C++ 程序中的错误。如果问题是内存管理，我会强烈研究std::auto_ptror std::tr1::shared_ptr，它会在完成后自动为您删除内存。如果这不是一个选项，我敢肯定，通过 valgrind 运行某些东西甚至为商业内存检查器付费会比重写整个东西（在时间和金钱上）更便宜。