At the technical support team, we have recently received a number of questions regarding support for the Universal Windows Platform. For those not in the know, UWP was designed by Microsoft to improve portability of applications between all possible Windows-style devices. In the older .NET Framework, porting an existing app to a new device family (e.g. wearables, XBox, etc.) is a non-trivial task. UWP aims to solve this problem by introducing a unified backbone that is compatible with all device families, and ensures that an app can be used on all devices that run on a Windows 10 operating system.
It turns out that UWP is based on .NET Core, which is a new development platform for .NET, similar but not equal to the .NET Framework. The .NET Core and the .NET Framework platforms are not 100% binary compatible, meaning that apps designed for the .NET Framework have a significant risk of not running on .NET Core, and by extension on UWP, without some code changes. More poignantly for iText Software and its customers, libraries that are used by these applications may also be unusable on UWP. Some of our customers and prospects have confirmed that there is indeed a compatibility problem for iTextSharp. The known issues are currently:
-
When adding the iTextSharp DLL as a reference to your UWP solution via NuGet
- error message:
- iTextSharp 5.5.8 is not compatible with UAP, Version=v10.0
- result:
- iTextSharp cannot be added to the UWP project through NuGet
-
After manually adding the iTextSharp DLL or source code to your UWP project
- error message:
- depends on which binary incompatibility is first encountered at runtime. Most frequently, a reflection problem like Could not load type 'System.ICloneable' from assembly 'mscorlib [...]'.
- result
- iTextSharp can be added to the UWP project and the build may succeed, but iTextSharp functionality is unusable when running the app.
The engineering team at iText Software is currently researching how to elegantly support .NET Core and UWP, of course without dropping support for the .NET Framework. This is most definitely feasible technically, but we have only begun looking for the most complete solution that suits every relevant .NET version. We of course prefer to avoid duplicating all our source code, because that would introduce the danger that the two repositories go out of sync.
This issue has a high priority for us, but we must take care to choose a sustainable path with as little long-term overhead as possible. We will be forced to look at what other leading software libraries have done to address this and other backwards compatibility issues. Fortunately, a similar breaking change has happened before in the .NET ecosystem, with the now obsolete Microsoft Silverlight engine. This rich Internet application framework introduced a lot of incompatibilities – most of them the same as for UWP – with the traditional .NET Framework, so we will start out by looking at what other open source libraries have done to support Silverlight.