Back in the Nineties there was a lot of fuss about \u201cpure Java\u201d. This meant Java code without any native code invocations that tie the application to a specific operating system.<\/p>\n
It is possible to write cross-platform Java code that invokes native code, but it adds to the complexity. If it is an operating system API you need conditional code so that the write API is called on each platform. If it is a custom library it will have to be compiled separately for each platform.<\/p>\n
Over on the Microsoft .NET site, developers have tended to have a more casual approach. After all, in the great majority of cases the code would only ever run on Windows. Further, Microsoft tended to steer developers towards Windows-only dependencies like SQL Server. After all, that is the value of owning a developer platform.<\/p>\n
Times change. Microsoft has got the cross-platform bug, with its business strategy based on attracting businesses to its cloud properties (Office 365 and Azure) rather than Windows. The .NET Framework has been forked to create .NET Core, which runs on Mac and Linux as well as Windows. SQL Server is coming to Linux. <\/p>\n
Another issue is porting applications from 32-bit to 64-bit, as I was reminded recently when migrating some ASP.NET applications to a new site. If your .NET code avoids P\/Invoke (Platform Invoke) then you can compile for \u201cAny CPU\u201d and 64-bit will just work. If you used P-invoke and want to support both 32-bit and 64-bit it requires more care. IntPtr, used frequently in P\/Invoke calls, is a different size. If you have custom native libraries, you need to compile them separately for each platform. The lazy solution is always to run as 32-bit but that is a shame.<\/p>\n
What this means is that P\/Invoke should only be used as a last resort. Arguably this has always been true, but the reasons are stronger today.<\/p>\n
This is also an issue for libraries and components intended for general use, whether open source or commercial. It is early days for .NET Core support, but any native code dependencies will be a problem.<\/p>\n
Breaking the P\/Invoke habit will not be easy but \u201cPure .NET\u201d is the way to go whenever possible.<\/p>\n","protected":false},"excerpt":{"rendered":"
Back in the Nineties there was a lot of fuss about \u201cpure Java\u201d. This meant Java code without any native code invocations that tie the application to a specific operating system. It is possible to write cross-platform Java code that invokes native code, but it adds to the complexity. If it is an operating system … Continue reading Time for another look at \u201cpure .NET\u201d<\/span>