I made a small practice effort and ported Evil-DICOM to .NET Core (.NET Standard 1.5). As you can see there are very few source code changes involved, most notably
a few changes to Async methods (synchronous methods do not exist in .NET Core) which are invoked synchronously for now
Change of IMessage.DynPayload return type to object to avoid using the considerably slower dynamic runtime.
Using GetEntryAssembly instead of non-existing GetCallingAssembly in EVIL_DICOM_IMP_VERSION definition.
Conditional use of TcpClient.Dispose for .NET Core and TcpClient.Close for .NET Framework 4.5, since there is no common support on both platforms.
The EvilDICOM.csproj project has been replaced with an .xproj file and a project.json file which builds both a .NET Core assembly and a .NET Framework 4.5 assembly to be used e.g. in the unit tests.
Eventually, when VS 2017 is publicly released, it will make sense to change back to the new .csproj format, although I have not accounted for that in this PR.
Hi Rex,
I made a small practice effort and ported Evil-DICOM to .NET Core (.NET Standard 1.5). As you can see there are very few source code changes involved, most notably
Asyncmethods (synchronous methods do not exist in .NET Core) which are invoked synchronously for nowIMessage.DynPayloadreturn type toobjectto avoid using the considerably slower dynamic runtime.GetEntryAssemblyinstead of non-existingGetCallingAssemblyinEVIL_DICOM_IMP_VERSIONdefinition.TcpClient.Disposefor .NET Core andTcpClient.Closefor .NET Framework 4.5, since there is no common support on both platforms.The EvilDICOM.csproj project has been replaced with an .xproj file and a project.json file which builds both a .NET Core assembly and a .NET Framework 4.5 assembly to be used e.g. in the unit tests.
Eventually, when VS 2017 is publicly released, it will make sense to change back to the new .csproj format, although I have not accounted for that in this PR.
I hope you find this PR worthwhile to apply.
Best, Anders @ Cureos