Serialisation, mixed content and string[]

When you generate a class out of a schema with an element configured to allow mixed content (child attributes and elements as well as text), you should expect the corresponding generated field type to be a string array;

So - if you have a schema that looks like this

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://tempuri.org/XMLSchema.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/XMLSchema.xsd" xmlns:mstns="http://tempuri.org/XMLSchema.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="SomeElement">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element name="Child1" type="xs:string"/>
<xs:element name="Child2" type="xs:string"/>
<xs:element name="Child3" type="xs:string"/>
</xs:sequence>
<xs:attribute name="SomeAttribute" type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:schema>

(‘SomeElement’ being a complex type allowing mixed content)

The fields in the generated class would look like

public partial class SomeElement {

 private string child1Field;

 private string child2Field;

 private string child3Field;

 private string[] textField;

 private string someAttributeField;
.
.
.

The reason for the array of strings (instead of just one string field) is that an XML corresponding to the schema might look like this –

<SomeElement xmlns="http://tempuri.org/XMLSchema.xsd" SomeAttribute="someAttributeValue">
 Some free text
 <Child1>Child1 text</Child1>
 Some more free text
 <Child2>Child2 text</Child2>
 yet some more free text
 <Child3>Child3 text</Child3>
</SomeElement>

And so by using a string array to hold the text the deserialiser can keep string portions separately.

Initially, I thought, this allows the structure to represent the original xml accurately, but this is not exactly the case – you would still not know for certain where each string portion existed, especially if in the source XML you get a few elements that don’t have text between them, which , I suspect, is why when I serialise the instance back to xml I actually get –

<?xml version="1.0"?>
<SomeElement xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" SomeAttribute="someAttributeValue" xmlns="http://tempuri.org/XMLSchema.xsd">
 <Child1>Child1 text</Child1>
 <Child2>Child2 text</Child2>
 <Child3>Child3 text</Child3>
 Some free text

 Some more free text

 yet some more free text
 </SomeElement>

Now, I don’t particularly like this sort of xml, and shy away from mixed content; I don’t believe that xml snippets like my samples above are useful, specifically I don’t think that mixing elements and text is particularly nice.

However, consider an element with an attribute and some text – the following is quite reasonable I think, and yet requires mixed content -

<Phone type="mobile">some text here</Phone>

Supporting both active and passive scenarios in my STS

In a comment on a previous blog post Travis Spencer asked

Can you explain more about how you implemented an STS that supports both active and passive scenarios?

 

So here’s how -

 

To start with – I’ve implemented my STS class with all the logic I needed; this was done as a class library with several classes – my STS implementation, my STS-Configuration class, an STS service factory, my custom WindowsUserNameSecurityTokenHandler implementation and all the classes I needed to support my custom configuration section.

Then, in order to support an active scenario, I’ve created a WCF service and, through the SVC file, I’ve configured it to use my STS service factory class -

 

<%@ ServiceHost Language="C#" Debug="true" Service="<My STS configuration class>"  factory="<My STS Factory class>"%>

 

I’ve then configured the web.config of the wcf service to support my scenario – that included all the relevant binding configuration I needed,  the Geneva framework related configuration (microsoft.IdentityModel) as well as any custom configuration my STS uses.

 

The passive scenario can seem a little bit more confusing -

Obviously I’ve started by creating an asp.net web application; this application basically  has two web pages (admittedly I’m simplifying things a little bit for clarity) – default.aspx and login.aspx

 

Using standard asp.net forms authentication the web site is configured to redirect all unauthenticated users to the Login.aspx page, which in turns has a pretty standard login implementation using my custom username validator logic and the framework’s RedirectFromLoginPage function to set the local forms authentication cookie.

All my web-based reliant parties redirect the user to the default.aspx page; forms-auth then redirects again to login.aspx for authentication and then, once authenticated, the user is redirected back to default.aspx; on this page I’ve simply put the FederatedPassiveTokenService control provided with the geneva framework configured to use my STS configuration class as the service; this takes care of calling the STS and posting the token back to the RP

 

I hope that makes sense…do let me know if it does not!

VS crashes? check your colour depth setting!

Over the last few months we've been seeing quite a few Visual Studio crashes when working with the orchestration designer.

The scenarios vary slightly between machines - some would crash on build, others simply when opening an orchestration in the designer; some would crash very frequently, some only sporadically; some would crash even when opening the solution immediately after a reboot, others would work fine for a while and then crash; the bottom line was that we were having lots of crashes, and we were losing on developer productivity and gaining tons of frustration.

Because the problems did not happen in a very consistent manner, and because there were different manifestations we simply had no clue what might be the cause; we've talked to a few people and searched the web; we’ve followed almost every tip we've received (make sure no documents are open when you build, collapse all shapes in an orchestration before saving it, etc.); some seem to have helped a little bit, but the crashes kept happening.

Sometimes Visual Studio would show an error on the screen – something like -

 

But in other times, it simply crashed without a warning.

Eventually we’ve contacted Microsoft support, and analysing dumps we’ve created they have found the following error -

Exception type: System.InvalidOperationException
Message: BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress.
StackTrace (generated):
System_Drawing_ni!System.Drawing.BufferedGraphicsContext.Dispose(Boolean)
System_Drawing_ni!System.Drawing.BufferedGraphicsContext.Dispose()
System_Drawing_ni!System.Drawing.BufferedGraphicsContext.AllocBufferInTempManager(System.Drawing.Graphics, IntPtr, System.Drawing.Rectangle)
System_Drawing_ni!System.Drawing.BufferedGraphicsContext.Allocate(IntPtr, System.Drawing.Rectangle)
System_Windows_Forms_ni!System.Windows.Forms.Control.WmPaint(System.Windows.Forms.Message ByRef)
System_Windows_Forms_ni!System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
System_Windows_Forms_ni!System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr, Int32, IntPtr, IntPtr)

 

From this it was clear that the issue is related to GDI+ when VS redraws the orchestration and MS have confirmed they have seen this issue elsewhere (outside the BizTalk realm), but we were told that this problem was “aggravated by the fact that BizTalk creates very large device-independent bitmaps and uses the same colour depth than the desktop.”

Unfortunately, according to Microsoft, there are many contributing factors to this issue, and it is virtually impossible to isolate the cause(s) in our case, but two recommendations were made -

• Use a video card with more memory



• Lower colour depth setting from 32 bit to 16 bit in the display settings in windows



• Split large orchestrations to smaller ones

That last recommendation would have been our last resort – not only it would require a significant re-factor-re-test effort as our solution is quite  big, it would seriously decrease our already too long deployment time.

We were quite happy to follow the first recommendation, but obviously trying the second one was pretty effortless we went with that first and what do you know – it worked!

Machines which have changed the colour depth setting to 16 bit stopped having those frequent crashes;

It must be said we’re still experiencing some crashes, so there are other issues as well, but these are more specific, and are another story altogether, one to be told once the end is known!