Using .Net Standard to Enable Cross-Use
Microsoft developed a shim technology to allow .Net Framework compatibility with .Net Standard and .Net Core. Before .Net Standard 2.0, the shim was incomplete. If you have .Net Framework 4.x-based class libraries that you want to share with .Net Core 1.x projects, you can create a .Net Standard 1.x class library project to enable cross-use.
Creating a .Net Standard class library means that you intend it to be shared by .Net Framework and .Net Core projects. If you have a new .Net Core project that needs to use your existing .Net Framework class libraries, and migrating/porting/upgrading them to .Net Standard is not an option (yet), you can instead create a .Net Standard class library as a wrapper.
Reminder!!! The technique described here can be used for .Net Standard 1.x class library projects. You may not need this when working with .Net Standard 2.0. You can consider this technique as a temporary solution, until you find the opportunity to actually fully port your .Net Framework class library into a .Net Standard class library.
The first thing that you need to check is to find out what .Net Framework version is compatible with what .Net Standard version. If you find your versions are matching in the matrix, then you can continue with this technique.
Now, when you create your .Net Standard class library, target the .Net Standard version that matches the .Net Framework version used by the library to wrap.
Next, you need to get the Microsoft.NETCore.Portable.Compatibility package from NuGet. This package resolves the necessary .Net Framework dependencies.
Finally, add a reference to your .Net Framework-based library. Try to build. If all references are found, then the build will include them in the output. If all is well, and the build is successful, you can then start creating your wrapper class, exposing the features that you want to share with your .Net Core projects.
One example where this is applicable is when you have a .Net Framework-based cryptography class library named MyCrypto.dll, which may feature custom and complex cryptography strategies and techniques. Let's say for example that it is currently used by existing .Net Framework applications in production, and there is no plan to update them (yet). It is also possible that there is no budget/time to try porting MyCrypto.dll in to .Net Standard, more so to spend budget/time for regression testing. Crunch time, if you need to use the existing MyCrypto.dll in your new .Net Core applications, you can use this technique to create a .Net Standard class library wrapper named MyCryptoWrapper.dll, exposing Encrypt() and Decrypt() methods that internally consume the existing MyCrypto.dll classes. And then, in your .Net Core applications, you can reference MyCryptoWrapper.dll instead. Problem solved! Your .Net Framework applications are untouched, and you can keep going with your .Net Core projects.
As always, test, test and test! Make sure that the .Net Standard-based library/wrapper works with your .Net Core project.
Have fun!
Creating a .Net Standard class library means that you intend it to be shared by .Net Framework and .Net Core projects. If you have a new .Net Core project that needs to use your existing .Net Framework class libraries, and migrating/porting/upgrading them to .Net Standard is not an option (yet), you can instead create a .Net Standard class library as a wrapper.
Reminder!!! The technique described here can be used for .Net Standard 1.x class library projects. You may not need this when working with .Net Standard 2.0. You can consider this technique as a temporary solution, until you find the opportunity to actually fully port your .Net Framework class library into a .Net Standard class library.
The first thing that you need to check is to find out what .Net Framework version is compatible with what .Net Standard version. If you find your versions are matching in the matrix, then you can continue with this technique.
Now, when you create your .Net Standard class library, target the .Net Standard version that matches the .Net Framework version used by the library to wrap.
Next, you need to get the Microsoft.NETCore.Portable.Compatibility package from NuGet. This package resolves the necessary .Net Framework dependencies.
Finally, add a reference to your .Net Framework-based library. Try to build. If all references are found, then the build will include them in the output. If all is well, and the build is successful, you can then start creating your wrapper class, exposing the features that you want to share with your .Net Core projects.
One example where this is applicable is when you have a .Net Framework-based cryptography class library named MyCrypto.dll, which may feature custom and complex cryptography strategies and techniques. Let's say for example that it is currently used by existing .Net Framework applications in production, and there is no plan to update them (yet). It is also possible that there is no budget/time to try porting MyCrypto.dll in to .Net Standard, more so to spend budget/time for regression testing. Crunch time, if you need to use the existing MyCrypto.dll in your new .Net Core applications, you can use this technique to create a .Net Standard class library wrapper named MyCryptoWrapper.dll, exposing Encrypt() and Decrypt() methods that internally consume the existing MyCrypto.dll classes. And then, in your .Net Core applications, you can reference MyCryptoWrapper.dll instead. Problem solved! Your .Net Framework applications are untouched, and you can keep going with your .Net Core projects.
As always, test, test and test! Make sure that the .Net Standard-based library/wrapper works with your .Net Core project.
Have fun!
Comments
Post a Comment