An unexpected error condition occurred. Please [file a bug report](https://bugzilla.xamarin.com/enter_bug.cgi?product=Xamarin.Mac) with as much information as possible, including:
* Full build logs, with maximum verbosity (e.g. `-v -v -v -v` in the **Additional mmp arguments**);
* A minimal test case that reproduce the error; and
* All version informations
The easiest way to get exact version information is to use the **Xamarin Studio** menu, **About Xamarin Studio** item, **Show Details** button and copy/paste the version informations (you can use the **Copy Information** button).
### <a name="MM0001">MM0001: This version of Xamarin.Mac requires Mono {0} (the current Mono version is {1}). Please update the Mono.framework from http://mono-project.com/Downloads
### <a name="MM0060">MM0060: Could not find the currently selected Xcode on the system. 'xcode-select --print-path' returned '{0}', but that directory does not exist.
### <a name="MM0071">MM0071: Unknown platform: *. This usually indicates a bug in Xamarin.Mac; please file a bug report at https://bugzilla.xamarin.com with a test case.
This usually indicates a bug in Xamarin.Mac; please file a bug report at [https://bugzilla.xamarin.com](https://bugzilla.xamarin.com/enter_bug.cgi?product=Xamarin.Mac) with a test case.
### <a name="MM0073"/>MM0073: Xamarin.Mac * does not support a deployment target of * (the minimum is *). Please select a newer deployment target in your project's Info.plist.
The minimum deployment target is the one specified in the error message; please select a newer deployment target in the project's Info.plist.
If updating the deployment target is not possible, then please use an older version of Xamarin.Mac.
### <a name="MM0074"/>MM0074: Xamarin.Mac * does not support a deployment target of * (the maximum is *). Please select an older deployment target in your project's Info.plist or upgrade to a newer version of Xamarin.Mac.
Xamarin.Mac does not support setting the minimum deployment target to a higher version than the version this particular version of Xamarin.Mac was built for.
Please select an older minimum deployment target in the project's Info.plist, or upgrade to a newer version of Xamarin.Mac.
### <a name="MM0091"/>MM0091: This version of Xamarin.Mac requires the * SDK (shipped with Xcode *). Either upgrade Xcode to get the required header files or use the dynamic registrar or set the managed linker behaviour to Link Platform or Link Framework SDKs Only (to try to avoid the new APIs).
Xamarin.Mac requires the header files, from the SDK version specified in the error message, to build your application with the static registrar.. The recommended way to fix this error is to upgrade Xcode to get the required SDK, this will include all the required header files. If you have multiple versions of Xcode installed, or want to use an Xcode in a non-default location, make sure to set the correct Xcode location in your IDE's preferences.
One potential, alternative solution, is to enable the managed linker. This will remove unused API including, in most cases, the new API where the header files are missing (or incomplete). However this will not work if your project uses API that was introduced in a newer SDK than the one your Xcode provides.
A second potential, alternative solution, is use the dynamic registrar instead. This will impose a startup cost by dynamically registering types but remove the header file requirement.
A last-straw solution would be to use an older version of Xamarin.Mac, one that supports the SDK your project requires.
### <a name="MM0129"/>MM0129: Debugging symbol file for '*' does not match the assembly and is ignored.
The debugging symbols, either a .pdb (portable pdb only) or a .mdb file, for the specified assembly could not be loaded.
This generally means the assembly is newer or older than the symbols. Since they do not match they cannot be used and the symbols are ignored.
This warning won't affect the application being built, however you might not be able to debug it entirely (in particular the code from specified assembly). Also exceptions, stack traces and crash reports might be missing some information.
Please report this issue to the publisher of the assembly package (e.g. nuget author) so this can be fixed in their future releases.
The accepted format is `[+|-]optimization-name`, where `optimization-name` is one of the values listed in the error message.
See [Build optimizations](https://developer.xamarin.com/guides/cross-platform/macios/build-optimizations) for a complete description of each optimization.
### <a name="MM0135"/>MM0135: Did not link system framework '{0}' (referenced by assembly '{1}') because it was introduced in {2} {3}, and we're using the {2} {4} SDK.
To build your application, Xamarin.Mac must link against system libraries, some of which depend upon the SDK version specified in the error message. Since you are using an older version of the SDK, invocations to those APIs may fail at runtime.
The recommended way to fix this error is to upgrade Xcode to get the needed SDK. If you have multiple versions of Xcode installed or want to use an Xcode in a non-default location, make sure to set the correct Xcode location in your IDE's preferences.
Alternatively, enable the managed [linker](https://docs.microsoft.com/xamarin/mac/deploy-test/linker) to remove unused APIs, including (in most cases) the new ones which require the specified library. However, this will not work if your project requires APIs introduced in a newer SDK than the one your Xcode provides.
As a last-straw solution, use an older version of Xamarin.Mac that does not require these new SDKs to be present during the build process.
### <a name="MM2013">MM2013: Failed to resolve the reference to "{0}", referenced in "{1}". The app will not include the referenced assembly, and may fail at runtime.
### <a name="MM2014">MM2014: Xamarin.Mac Extensions do not support linking. Request for linking will be ignored. ** This message is obsolete in XM 3.6+ **
An unexpected error occured when processing an assembly.
The assembly causing the issue is named in the error message. In order to fix this issue the assembly will need to be provided in a [bug report](https://bugzilla.xamarin.com) along with a complete build log with verbosity enabled (i.e. `-v -v -v -v` in the **Additional mtouch arguments**).
### <a name="MM2108"/>MM2108: '{0}' was stripped of architectures except '{1}' to comply with App Store restrictions. This could break exisiting codesigning signatures. Consider stripping the library with lipo or disabling with --optimize=-trim-architectures");
The App Store now rejects applications which contain libraries and frameworks which contain 32-bit variants. The library was stripped of unused archtectures when copied into the final application bundle.
This is in general safe, and will reduce application bundle size as an added benefit. However, any bundled framework that is code signed will have its signature invalidated (and resigned later if the application is signed).
Consider using `lipo` to remove the unnecessary archtectures permanently from the source library. If the application is not being published to the App Store, this removal can be disabled by passing --optimize=-trim-architectures as Additional MMP Arguments.
### <a name="MM4134">MM4134: Your application is using the '{0}' framework, which isn't included in the MacOS SDK you're using to build your app (this framework was introduced in OSX {2}, while you're building with the MacOS {1} SDK.) This configuration is not supported with the static registrar (pass --registrar:dynamic as an additional mmp argument in your project's Mac Build option to select). Alternatively select a newer SDK in your app's Mac Build options.
### <a name="MM4173"/>MM4173: The registrar can't compute the block signature for the delegate of type {delegate-type} in the method {method} because *.
This is a warning indicating that the registrar couldn't inject the block
signature of the specified method into the generated registrar code, because
the registrar couldn't compute it.
This means that the block signature has to be computed at runtime, which is
somewhat slower.
There are currently two possible reasons for this warning:
1. The type of the managed delegate is either a `System.Delegate` or
`System.MulticastDelegate`. These types don't represent a specific signature,
which means the registrar can't compute the corresponding native signature
either. In this case the fix is to use a specific delegate type for the
block (alternatively the warning can be ignored by adding `--nowarn:4173`
as an additional mmp argument in the project's Mac Build options).
2. The registrar can't find the `Invoke` method of the delegate. This
shouldn't happen, so please file an [issue](https://github.com/xamarin/xamarin-macios/issues/new)
One possible reason for this warning is when manually writing bindings for API
that uses blocks. It's recommended to use a binding project to bind
Objective-C code, in particular when it involves blocks, since it's quite
complicated to get it right when doing it manually.
If this is not the case, please file a bug at [https://bugzilla.xamarin.com](https://bugzilla.xamarin.com/enter_bug.cgi?product=Xamarin.Mac) with a test case.
### <a name="MM4175"/>MM4175: The parameter '{parameter}' in the method '{method}' has an invalid BlockProxy attribute (the type passed to the attribute does not have a 'Create' method).
This is a warning indicating that the parameter in the error message has an
invalid `[BlockProxy]` attribute, where the type passed to the attribute is
### <a name="MM4176"/>MM4176: Unable to locate the delegate to block conversion type for the return value of the method {method}.
This is a warning indicating that the static registrar couldn't find the type
used to convert a delegate to an Objective-C block. An attempt will be made at
runtime to find the method, but it will likely fail as well (with an MM8009
exception).
One possible reason for this warning is when manually writing bindings for API
that uses blocks. It's recommended to use a binding project to bind
Objective-C code, in particular when it involves blocks, since it's quite
complicated to get it right when doing it manually.
If this is not the case, please file a bug at [https://bugzilla.xamarin.com](https://bugzilla.xamarin.com/enter_bug.cgi?product=Xamarin.Mac) with a test case.
### <a name="MM5202">MM5202: Mono.framework MDK is missing. Please install the MDK for your Mono.framework version from http://mono-project.com/Downloads
### <a name="MM5218"/>MM5218: Can't ignore the dynamic symbol {symbol} (--ignore-dynamic-symbol={symbol}) because it was not detected as a dynamic symbol.
### <a name="MM8025"/>MM8025: Failed to compute the token reference for the type '{type.AssemblyQualifiedName}' because {reasons}
This indicates a bug in Xamarin.Mac. Please file a bug at [https://bugzilla.xamarin.com](https://bugzilla.xamarin.com/enter_bug.cgi?product=Xamarin.Mac).
This usually indicates a bug in Xamarin.Mac, because the dynamic registrar should not be linked away if it's needed. Please file a bug at [https://bugzilla.xamarin.com](https://bugzilla.xamarin.com/enter_bug.cgi?product=Xamarin.Mac).
### <a name="MT8027"/>MT8027: Failed to marshal the Objective-C object {handle} (type: {managed_type}). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance.
This occurs when the Xamarin.Mac runtime finds an Objective-C object without a
corresponding managed wrapper object, and when trying to create that managed
wrapper, it turns out it's not possible.
There are a few reasons this may happen:
* If it occurs when deserializing a storyboard/nib/xib and mentioning a
managed type that's used in that storyboard/nib/xib, then the fix is to add
a constructor that takes a single `IntPtr` argument to that managed type.
This constructor should not have any logic (because it's invoked before the
native and managed instances are fully created).
* A managed wrapper existed at some point, but was collected by the GC. If the
native object is still alive, and later resurfaces to managed code, the
Xamarin.Mac runtime will try to re-create a managed wrapper instance. In
most cases the problem here is that the managed wrapper shouldn't have been
collected by the GC in the first place.
Possible causes include:
* Manually calling Dispose too early on the managed wrapper.
* Incorrect bindings for third-party libraries.
* Reference-counting bugs in third-party libraries.
* It could be a bug in Xamarin.Mac. If this is the case, please file a bug at