Bug 12465 - XmlSerialization can't find default constructor
Summary: XmlSerialization can't find default constructor
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: mmp ()
Version: 1.4.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Sebastien Pouliot
Depends on:
Reported: 2013-05-30 02:02 UTC by Tony
Modified: 2013-06-04 20:37 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Tony 2013-05-30 02:02:41 UTC
When running a Release build and trying to deserialize an XML file, the default constructor for the target class can't be found. This occurs when another constructor is defined in the class (and of course a default constructor is also defined)
Comment 1 Aaron Bockover [MSFT] 2013-06-03 10:13:58 UTC
Sounds like this might be a linker issue. Tony, do you have a simple test case we could try?
Comment 2 Tony 2013-06-03 10:50:16 UTC
Just found out the problem.

And indeed, it was a linker issue.

The project had Mac OS X Packaging -> Code Generation Options -> Linker Behavior set to "Link All"

What I did before I found the solution for the issue, was to remove all constructors from the serialized class, which solved the problem.

When setting the Linker Behavior to Don't Link, the problems disappeared.
This is true for bug "[Bug 12466] MailSettingsSectionGroup generates error" 

Here's a simple example that generates the problem...

		void SerializeCrash ()
			string filepath = Path.Combine( Environment.GetFolderPath(Environment.SpecialFolder.Personal), "testfile.xml");

			var serializer = new XmlSerializer(typeof(SerializeMe));
			serializer.UnknownAttribute += (object sender, XmlAttributeEventArgs e) => {

			using (var stream = File.OpenRead(filepath))
				using (var xreader = new XmlTextReader(stream))
				SerializeMe item = serializer.Deserialize(xreader) as SerializeMe;

		public class SerializeMe
			int SetMe {

			public SerializeMe()
				this.SetMe = 1;


...and the XML...

<?xml version="1.0" encoding="utf-8"?>
<SerializeMe xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" SetMe="1">
Comment 3 Sebastien Pouliot 2013-06-03 11:05:32 UTC
The linker removes all unused code based on static analysis. When reflection is used (i.e. dynamic use of code) then the linker cannot, without outside help, detect if the code is used.

The linker (for iOS*) is smart and when it see a type with [Xml*] attributes it will keep the default constructor. The same occurs when the [Serializable] attribute decorates a type.

* I'll look at porting this feature to the OSX linker (I thought it was already present)
Comment 4 Sebastien Pouliot 2013-06-04 20:37:13 UTC
Fixed in f3e2728a73821b86076d0fbefb2906d19d0a4b20
QA: regression test added to the build