Forum Discussion
which .net version to use?
We are building a .net API (or wrapper) for a service of us. This service is a native service and we also provide a native dll with a C-interface (and COM-like interfaces). Now this wrapper. It's written in C++/CLI and we compiled it for .net Framework 4.0 and .net Core 3.1 ... the question is now, if we do have to recompile this project for .net 6, .net 7 and .net 8 or if that's not needed and our customers can still use the one that has been built for .net Core 3.1.
Is there anything that won't work? Or could there be a security risk by doing this? (e.g. if you use our assembly in a .net 7 project?).
What if we compile this assembly for .net 8... could it still be used in older .net core 3.1 projects which may still be around? or in .net 6/7 projects? ... what's the best approach here?
1 Reply
I have tried to respond to your query, addressing key concerns and suggesting best practices in some level of detail:
The first things that come to my mind are Compatibility and Potential Issues:
General Compatibility: .NET Core 3.1 assemblies often work in newer .NET versions (6, 7, 8), but not always.
Also, I would like to address a few specific concerns:
C++/CLI: It has known compatibility limitations in newer .NET versions.
COM-Like Interfaces: Check for compatibility with newer .NET runtimes.
Native Dependencies: Ensure they're compatible with target platforms.
Security Risks: Using outdated assemblies might expose vulnerabilities if newer .NET versions address them.
Recompiling for .NET 8:
Backward Compatibility: Assemblies compiled for .NET 8 generally cannot be used in older .NET Core 3.1 or .NET 6/7 projects due to potential breaking changes.
Best Practices:
Recompile for Newer .NET Versions: Prioritize recompiling for .NET 6 or 7 as they are LTS (Long-Term Support) versions, ensuring stability and security updates.
Thorough Testing: Conduct rigorous testing to identify and address compatibility issues proactively.
Multiple Builds: If maintaining compatibility with older .NET Core 3.1 projects is crucial, consider providing separate builds for different .NET versions.
Continuous Updates: Stay updated with .NET releases and address potential compatibility concerns early on.
Additional Considerations:
Consider Alternatives: Explore alternative technologies or approaches for the wrapper if C++/CLI's limitations in newer .NET versions pose significant challenges.
Monitor Microsoft Guidance: Stay informed about Microsoft's recommendations and support for C++/CLI in future .NET releases.
