{"id":307,"date":"2019-03-15T15:48:20","date_gmt":"2019-03-15T20:48:20","guid":{"rendered":"http:\/\/www.p14nd4.com\/blog\/?p=307"},"modified":"2019-03-15T15:48:20","modified_gmt":"2019-03-15T20:48:20","slug":"system-invalidprogramexception-common-language-runtime-detected-an-invalid-program","status":"publish","type":"post","link":"https:\/\/www.p14nd4.com\/blog\/2019\/03\/15\/system-invalidprogramexception-common-language-runtime-detected-an-invalid-program\/","title":{"rendered":"System.InvalidProgramException: Common Language Runtime detected an invalid program"},"content":{"rendered":"

I just spent a while fighting an exception that was being thrown from within a .NET runtime-generated assembly—specifically from Microsoft.Xml.<\/wbr>Serialization.<\/wbr>GeneratedAssembly.<\/wbr>XmlSerializationWriter{MyClassName}.<\/wbr>Write7_{MyClassName}<\/wbr><\/span>. There were plenty of search results that didn’t<\/em> apply to my problem, but I didn’t find any that directly addressed the issue I was encountering, so I wanted to write up a quick post to possibly save someone some time in the future.<\/p>\n

<\/p>\n

tl;dr<\/abbr><\/h3>\n

The object being serialized included this method:<\/p>\n

public static bool ShouldSerializeFoobarProp() => false;<\/code><\/p>\n

Eliminating the static<\/code> declaration made the problem go away[1]<\/a><\/sup>.<\/p>\n

The full story<\/h3>\n

I’ve got a class defined which can be populated from and\/or serialized to XML. It uses a bunch of [XmlElement(\"foobar\")]<\/code> annotations, and is 95% just used as a data structure. It gets serialized to XML thusly:<\/p>\n

XmlSerializer s = new XmlSerializer(typeof(MyFoobarClass));\r\n\r\nusing (StringWriter w = new StringWriter())\r\n{\r\n\tXmlSerializerNamespaces xmlnsEmpty = new XmlSerializerNamespaces();\r\n\txmlnsEmpty.Add(\"\", \"\");\r\n\r\n\ttry\r\n\t{\r\n\t\ts.Serialize(w, myFoobarObject, xmlnsEmpty);<\/code><\/pre>\n
However, there are a few public properties of the class that, while useful elsewhere in the code, don’t necessarily make sense when serializing to XML. I employed the ShouldSerialize{PropertyName}<\/code><\/a> pattern[2]<\/a><\/sup> to selectively serialize certain elements and attributes only when useful, and never<\/em> serialize another property.[1]<\/a><\/sup><\/p>\n
That all worked fine. At some point, I worked through a bunch of code analysis hints, one of which correctly pointed out that CA1822\tMember ShouldSerialize{Foobar} does not access instance data and can be marked as static (Shared in VisualBasic)<\/span>. I didn’t have a unit test for this (tsk, tsk!), so everything looked fine. This serialization doesn’t even run during most normal use of the software, so no red flags were raised for quite a while. Thankfully, before these changes shipped, I did exercise this code path, and was greeted with System.InvalidProgramException: Common Language Runtime detected an invalid program<\/span> thrown from the call to s.Serialize(...)<\/code>.<\/p>\n
Search results for this exception pointed me to corrupt builds, x86\/x64 mismatch, corrupt Visual Studio session data, corrupt .NET runtime installations, etc, none of which was helpful in this case. Eventually I found a StackOverflow answer from Youssef Moussaoui<\/a> that talked about XmlSerializer changes in .NET 4.5.<\/p>\n
I tried changing the .NET targeted runtime for my projects to no avail, but he also included an app.config toggle to force legacy<\/q> behavior. When I tried that, I got a new exception! This one actually occurred earlier in the execution—when attempting to construct the serializer—but more importantly made a reference to my ShouldSerizlier{Foobar}<\/code> static method:<\/p>\n
System.InvalidOperationException: ‘Unable to generate a temporary class (result=1).
\nerror CS0176: Member ‘MyFoobarClass.ShouldSerializeFoobarProp()’ cannot be accessed with an instance reference; qualify it with a type name instead’<\/p><\/blockquote>\n
That was enough to point me to that method, which I saw was marked static. After eliminating the static keyword (and then silencing the resulting code analysis hint), voil\u00e0, everything was happy once again!<\/p>\n
[1]<\/a> This, of course, turns out to not be the right way to universally ignore an element for serialization. The [XmlIgnore]<\/code> annotation\/attribute<\/a> is the much more obvious and easy way to accomplish this.<\/p>\n
[2]<\/a> I’m sure I learned about the ShouldSerialize{PropertyName}<\/code> functionality on StackOverflow, specific to XmlSerializer, but I wasn’t able to easily find official documentation of the feature in that context when writing this post. This reference to winforms was the best I could do.<\/p>\n","protected":false},"excerpt":{"rendered":"
I just spent a while fighting an exception that was being thrown from within a .NET runtime-generated assembly—specifically from Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriter{MyClassName}.Write7_{MyClassName}. There were plenty of search results that didn’t apply to my problem, but I didn’t find any that directly addressed the issue I was encountering, so I wanted to write up a quick post to […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[32,31,19,15],"class_list":["post-307","post","type-post","status-publish","format-standard","hentry","category-technical","tag-net","tag-c","tag-solved","tag-visual-studio"],"_links":{"self":[{"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/posts\/307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/comments?post=307"}],"version-history":[{"count":16,"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/posts\/307\/revisions"}],"predecessor-version":[{"id":323,"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/posts\/307\/revisions\/323"}],"wp:attachment":[{"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/media?parent=307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/categories?post=307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.p14nd4.com\/blog\/wp-json\/wp\/v2\/tags?post=307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}