File Linking
In the last section, you created separate class libraries for each platform, which might seem counterproductive to sharing code. The problem is that you cannot simply take a DLL compiled for the full .NET framework, reference it in a project targeting a different platform, and expect it to run flawlessly. While it’s possible that this would actually work, it comes with an unnecessary level of risk. Each platform defines its own profile that it exposes, which specifies which areas of .NET it includes.
Note
The reason for the differences between profiles is that many times
there are parts of the framework that may not make sense everywhere. For
example, the System.Configuration
namespace is found in the full .NET Framework, and is used for handling
configuration data for desktop and web applications. However, this
namespace is intentionally absent from the Windows Phone and mobile Mono
profiles, as it doesn’t apply to those frameworks.
If the DLL uses a method present in the full .NET framework profile but absent from the target platform, your application will crash when it tries to invoke that method. This is a risk present in using a compiled DLL on any platform other than the one it was compiled for, such as using a .NET class library DLL in a Silverlight application, so this problem is not limited to mobile applications.
By compiling the code through these separate projects, you end up with a version of the library compiled specifically against each platform. This allows ...
Get Mobile Development with C# now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.