TL;DR I'm getting some errors with a PCL assembly (managed) that I built on Mac OSX using MDK version 4.2.1 (mcs command-line compiler). The Windows Phone 8 and Windows Store - Universal 10 build targets produce no errors during builds with this library. The two errors [exception reports] that I receive are extremely similar. Here's the portion that's the same: Code (CSharp): System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Collections, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x00000] in <filename unknown>:0 at Mono.Cecil.DefaultAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x00000] in <filename unknown>:0 at Mono.Cecil.MetadataResolver.Resolve (Mono.Cecil.TypeReference type) [0x00000] in <filename unknown>:0 at Mono.Cecil.ModuleDefinition.Resolve (Mono.Cecil.TypeReference type) [0x00000] in <filename unknown>:0 at Mono.Cecil.TypeReference.Resolve () [0x00000] in <filename unknown>:0 I've attached the complete output as two separate files to this post. We build the DLL with Unity 5.1.4f1 (build scripts, packaging) on Mac OSX and use the DLL with Unity 5.2.2f1 on Windows 10. Both produce the same errors. TL;DR Question Why would a Portable Class Library build cause this kind of output? How do I fix it? Detailed Version I'm creating a package for the Unity Asset Store that does not reference any platform-specific functionality. Our build system is currently running on Mac OSX. One of our assemblies uses some C# APIs that certain Windows platforms don't play nicely with (Phone/Store). To support those Windows platforms we build multiple versions of the Assembly: LibForEditor: A version that is only used while running in the Unity Editor. This enables extra GUI-related features that runtimes can't link against. LibForWinRT: A version that can link against all WinRT platforms (WinPhone/WinStore). Core: Used for all other platforms in Unity (as they all use Unity's Mono). To build the WinRT version, we link against the following during compile time: WinRTLegacy (copied from a Unity Windows installation to a Mac) Assemblies found in the .NETPortable Profile78 (the PCL profile) We pass the -noconfig and -nostdlib flags to the compiler to ensure that we aren't targeting a specific .NET Framework as well as the profile. We place this generated assembly in a separate folder, next to the Core version. We use the Plugin Inspector to instruct Unity to use that version for Windows Phone 8 and Windows Store builds. Builds using this assembly complete without issue when targeting Windows Phone 8 and Windows Store - Universal 10 (we're setting up an environment to test the rest, of course). The Problem Something in Unity is unhappy with this Assembly. We've found two scenarios that produce errors: MonoImporter.SetExecutionOrder (old link; still available as of Unity 5.2) CheckForObsoleteAPIUsage In both of these cases, the call stack eventually leads to the stack portion I wrote above. I have included the actual output of both errors as files attached to this post. As I mentioned above, we build the DLL with Unity 5.1.4f1 (build scripts, packaging) on Mac OSX and use the DLL with Unity 5.2.2f1 on Windows 10. Both produce the same errors. Note that this does not appear to cause any issues at runtime. The SetExecutionOrder error only occurs during our build process (as that's where we're setting the Execution Order) and the CheckForObsoleteAPIUsage error appears to only occur during initial import of the assembly. Once its in the AssetDatabase, everything seems fine. Ideally, I would have an assembly that worked as intended and did not produce any error output. One workaround for users would be to package the assembly as a .unitypackage that developers could unpack to gain support for those platforms - an opt-in solution. We'd have to tell the users that the error is expected and harmless, of course. As for the issue at hand, my guess is that the versions of the Frameworks that our assembly can reference aren't in Unity's lookup paths while attempting to resolve the assembly references during these processes. Is there a way to work around this issue? Or any way to compile a PCL that doesn't cause this error?