MSI (s) (DC:EC) [20:59:41:496]: Product: Windows Fabric -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action DoFabricSetup, location: C:\Program Files\Windows Fabric\bin\Fabric\Fabric.Code.1.0\MSIHiddenAppLauncher.exe, command: FabricSetup /operation:install /gac /trace:"C:\ProgramData\Windows Fabric\Fabric\log" /fabricDataRoot:"C:\ProgramData\Windows Fabric\\" /traceBufferSizeInKB:128 /traceFileSizeInMB:128 /fabricPrincipal:"domain\user"

The cause of the failure is, in Italian, the time format is 00.00.00 instead of 00:00:00. This is a localization bug of Windows Fabric installer on Italian OS.

There’s no fix available, but there’re some easy workarounds to unblock the installation.

1. Change the following registry setting to HH:MM:SS and install Windows Fabric (without restarting the services/machine).
• HKEY_CURRENT_USER\Control Panel\International\sTimeFormat = h:mm:ss tt
2. Instead of messing up the registry, you should be able to achieve the same by changing the Date/Time format in control panel.

Note: Don’t forget to revert the change to the time format after the installation is done.

Today I‘m investigating a WCF compatibility issue reported by a customer. The scenario is: The customer has a WCF service running on a machine with .NET 4.0, and a WCF client running on another machine with .NET 4.0 and everything works fine. Then the customer upgrades the client machine to .NET 4.5 and all of a sudden the client and service are not able to communicate.

Here is the DataContract being used:

[DataContract(Namespace = "https://temp/schemas")]

public abstract class BaseClass

{

    [DataMember(IsRequired = false, EmitDefaultValue = false)]

    private int _rowId;

    [DataMember(IsRequired = false, EmitDefaultValue = false)]

    private DateTime _addDate;

    [DataMember(IsRequired = false, EmitDefaultValue = false)]

    private string _developerNotes;

    [DataMember(Order = int.MaxValue, IsRequired = true, Name = "IsDirty", EmitDefaultValue = true)]

    public bool IsDirty { get; set; }

}

Looking at the XML serialization produced by WCF 4.0 and 4.5, we can see the members are ordered differently, no wonder the client and the service cannot talk to each other.

XML serialization produced by WCF in .NET 4.0:

<BaseClass xmlns="https://temp/schemas" xmlns:i="https://www.w3.org/2001/XMLSchema-instance">

<IsDirty>true</IsDirty>

<_addDate>2013-04-01T01:01:02</_addDate>

<_developerNotes>DeveloperNotes</_developerNotes>

<_rowId>1</_rowId>

</BaseClass>

XML serialization produced by WCF in .NET 4.5:

<BaseClass xmlns="https://temp/schemas" xmlns:i="https://www.w3.org/2001/XMLSchema-instance">

<_addDate>2013-04-01T01:01:02</_addDate>

<_developerNotes>DeveloperNotes</_developerNotes>

<_rowId>1</_rowId>

<IsDirty>true</IsDirty>

</BaseClass>

The cause

My initial thought is there might be some changes in WCF that caused the member order to be changed, but I would also be surprised if that’s the case as this would be a big breaking change. It turned out to not be the case. But there must be something changed, right? Exactly! It turned out what has changed was the sort algorithm in BCL.

Wait, you might ask, shouldn’t the sort algorithm change be transparent to upper level applications? Well, theoretically it should be, but there’re always situations when reality rear its ugly head.

Before WCF serializes data contract classes into XML, it will sort the members according to its ordering rule. In short, a member that has an order specified will appear after a member that doesn’t have an order specified. If both members have order specified, the one with smaller order will appear first. If both has the same order value, then alphabetic order will be used.

In fact the ordering rule is a bit complicated, especially when a comparer is concerned. But WCF managed to implement one simple comparer that worked almost perfectly – until Int.MaxValue comes into the picture.

Below is the comparer class that WCF implemented, to make sure members that has no order specified appear before members that have orders specified, it used a trick, i.e. to assign them an order of -1. In this way, it can treat all members in a unified way.

internal class DataMemberComparer : IComparer<DataMember>
{
    public int Compare(DataMember x, DataMember y)
    {
        int num = x.Order - y.Order;
        if (num != 0)
        {
            return num;
        }
        return string.CompareOrdinal(x.Name, y.Name);
    }
}

Now let’s look at what happens during sorting. Below is the first comparison that happens on .NET 4.0 and .NET 4.5. Can you see what’s wrong there?

Can you see the difference? And can you see what’s wrong there?

Actually there’re 2 issues here. The first issue is that the comparison WCF did in .NET 4.0 produces incorrect result, it’s a typical wrap around error that happens in boundary cases. Mathematically, Int.MaxValue - (-1) = Int.MaxValue + 1 = 2147483648, still a positive value, however, in reality, the maximum positive integer that a 32 bit integer can represent is 2147483647, adding 1 would cause overflow and the result becomes -2147483648 (Int.MinValue), which is negative and wrong.

The second issue is that in .NET 4.5, the change of sort algorithm causing the 2 members to be passed in in the reverse order. This time because a 32 bit integer can represent 1 more negative value than positive value, the comparison produces the right result: -1 - Int.MaxValue = –2147483648 = Int.MinValue.

The compatibility issue is caused by the combination of these 2 issues. Even if WCF in .NET 4.0 sorted members incorrectly, as long as it’s talking to .NET 4.0, everything is fine as the other side would be expecting the same (wrong) order. Same for .NET 4.5. But when .NET 4.0 and 4.5 are mixed, the problem arises as the two side are expecting different orders.

Had WCF implemented the comparison correctly, it would be resilient to any sort algorithm changes. Had the sort algorithm not changed in .NET 4.5, WCF would continue to produce the same (incorrect) result and interact well across different versions.

The options

OK, now we’ve understood the root cause, let’s have the joy of evaluating different options.

The first option is to revert the change to the BCL sort algorithm. But in fact it didn’t do anything wrong, as long as you implement the comparer correctly, it will still produce the right sort result – and in a much faster way! The change to the BCL sort algorithm in .NET 4.5 is for the good, even if you don’t do anything to your application, your application would get a much faster sort for free when moving from .NET 4.0 to 4.5. In my specific case, the sort used to take 17 comparisons in .NET 4.0, but now it only takes 6 comparisons in .NET 4.5. That should give you a better idea regarding how faster it is. So 99.99% of the .NET 4.5 customers would benefit from this change. Does it make sense to revert it just for a few customers? This choice might not be too hard. Check out here if you are interested in the new sort algorithm implemented in .NET 4.5.

The second option is to fix the comparer in WCF. However this isn’t an easy task for several reasons. First we can only fix the behavior in .NET 4.5 and later versions, as that’s where the behavior change happened. But on the other hand in our case the comparison is done correctly. So in order to make it produce the same result as 4.0, we’ll need to emulate the wrong behavior in 4.0. That indeed is a mission impossible as there’s simply no way to emulate the wrong behavior in 4.0, as the wrong behavior can also happen in .NET 4.5 – it depends on the initial order. The only possible way might be to have WCF duplicate the sort algorithm from .NET 4.0 into .NET 4.5, so that the comparison sequences remain unchanged, but obviously that’s not an easy task, let alone there’s no guarantee you can achieve 100% compatibility. Second, even worse, since .NET 4.5 has been released for a while and a lot of new applications could have been written based on the new behavior, reverting to 4.0 behavior means breaking these new applications. What a dilemma!

The third option is to fix the application. Compare with the above 2 options, this might be the most straightforward option. Just change Int.MaxValue to another values (e.g. Int.MaxValue - 1) and you’re guaranteed to have the same member order across different .NET versions.

Conclusion

If you run into this exact issue, you should already know what to do to solve this issue by reading this far.

I think WCF should check the value of Order when validating data contracts and disallows the use of Int.MaxValue as Order, but unfortunately that didn’t happen and might never happen. That’s the whole point of this post: To raise people’s awareness of this issue and hopefully to prevent it from happening in the future.

The only thing you should remember is, as the title says, if you’re using data contracts, don’t ever set DataMember.Order to Int.MaxValue, otherwise this issue will bite you some time later when your service are deployed on to different versions of .NET (4.0- vs. 4.5+).

The Issue

First let’s briefly review the issue.

1. The installation of Service Bus was successful. This issue existed since Service Bus 1.0 RTM, so it doesn’t matter whether you’re installing RTM version or CU1.
2. After the installation you try to configure Service Bus with either the wizard or PowerShell cmdlet, but that will never succeed. If you open Control Panel => Administrative Tools => Services, look at Service Bus Message Broker service, you’ll find that it’s always in Starting state and will never transition into Started state.
3. Your domain name contains only one segment, or put it another way, your domain name doesn’t contain a dot. So your domain name looks like MyDomain and your fully qualified machine name looks like MyMachine.MyDomain, instead of MyDomain.com and MyMachine.MyDomain.com.

If you meet all above 3 conditions, then read on. Otherwise you might be running into a different issue.

The cause

The root cause of the issue is the domain name doesn’t qualify as a fully qualified domain name (FQDN), while the current implementation of Service Bus server requires a FQDN to be used. A FQDN must be in the form of Prefix.Suffix, where Prefix and Suffix cannot be empty strings.

Service Bus supports Windows Server 2008 R2 and later OS, on which you won’t be able to create a domain with a name that only contains one segment. However, this is possible with Windows Server 2003. It will give you a warning but will still allow you to do so if you insist. I suppose Windows Server 2000 won’t even warn you.

The solution

The solution is fairly straightforward, just put your Service Bus server in a domain with a FQDN. However, simple as it is, in reality it might be impossible to implement as normally domain name is something out of your control.

I can’t imagine why someone would create a new domain without a FQDN, Windows Server 2008 R2 won’t let you do that anyway. But I can imagine corporates that had their domains created a decade ago and used it ever since – domain structure isn’t something that can be easily changed or is desirable to be changed in a corporate environment.

So is there a way to make it work without a FQDN? The good news is there is!

The workaround

The workaround is a bit complicated, so you’ll need to follow the steps carefully.

To avoid getting you lost in the details, first let’s look at the outline of the workaround:

1. Create a new certificate with full machine name.
2. Edit Window Fabric setting to use full machine names.
3. Re-configure Service Bus farm.

With the outline in mind, now let’s go into all the details. Let’s say the domain name is MyDomain and the machine name is MyMachine, replace them with your own domain name and machine name when applying the workaround.

1. Create a new certificate with full machine name.

1.1 Make a copy of "C:\Program Files\Service Bus\1.0\Scripts\GeneratedClusterCert.inf" to another folder, let’s say C:\Temp.

1.2 Modify the following 2 lines, replace CloudSpecificHostName and *.CloudSpecificDomainName with your full machine name.

• Before change:
• Subject = "CN=CloudSpecificHostName"
• _continue_ = "DNS=*.CloudSpecificDomainName"
• After change:
• Subject = "CN=MyMachine.MyDomain"
• _continue_ = "DNS=MyMachine.MyDomain"

1.3 Open an administrator command line prompt and go to C:\Temp, run the following command, this will generate a new certificate AppfabricSSL.cer in current directory.

• certreq.exe -cert AppServerGeneratedSBCA -new GeneratedClusterCert.inf AppfabricSSL.cer

1.4 Open the generated AppfabricSSL.cer, copy out the Thumbprint and remove any spaces in between, this will be used in step 3.

1.5 [Optional] View the certificate store and make sure the generated certificate has been installed.

2. Edit Window Fabric setting to use full machine names.

2.1 Open "C:\Program Files\Windows Fabric\bin\Fabric\Fabric.Config.1.0\Settings.xml"

2.2 Replace *.MyDomain in the following lines with full machine name.

• Before change:
• <Parameter Name="ClusterAllowedCommonNames" Value="*.MyDomain" />
• <Parameter Name="ClientAuthAllowedCommonNames" Value="*.MyDomain" />
• <Parameter Name="ServerAuthAllowedCommonNames" Value="*.MyDomain" />
• After change:
• <Parameter Name="ClusterAllowedCommonNames" Value="MyMachine.MyDomain" />
• <Parameter Name="ClientAuthAllowedCommonNames" Value="MyMachine.MyDomain" />
• <Parameter Name="ServerAuthAllowedCommonNames" Value="MyMachine.MyDomain" />

c. Save the file.

3. Re-configure Service Bus farm by running the following commands in SB PowerShell.

3.1 Remove-SBHost

3.2 Set-SBCertificate -EncryptionCertificateThumbprint {ThumPrint} -FarmCertificateThumbprint {ThumPrint}

• The {ThumPrint} is what you write down in 1.4

3.3 Add-SBHost

After following the steps above, now SB Message Broker service should be started in a few minutes and you can send/receive messages to/from SB queues.

Note: The workaround described here is for single machine farms only. It might also work for multi machine farms with a few modifications, but I haven’t tried that.

However, in some rare cases you might want to fine tune the generated XML serialization assembly. This isn’t something officially supported, but the fact that an XML serialization assembly pre-created by SGen.exe is allowed leaves us with an extensibility point and makes this possible. In this post I’m going to show you how to do exactly this.

There’re 3 key steps involved:

1. Modifying the source code.
2. Naming the serialization assembly.
3. Setting ParentAssemblyId.

Let’s walk through these steps in detail.

1. Modifying the source code

This step is obvious, but the questions is how do you get the source code that would be used to compile the XML serialization assembly. This is well supported, just add the following snippet into your configuration file and run your application.

<configuration>

  <system.diagnostics>

    <switches>

      <add name="XmlSerialization.Compilation" value="1" />

    </switches>

  </system.diagnostics>

</configuration>

By setting this switch you’re telling XML serialization to preserve the source code it uses to generate the dynamic assembly, and by running it you’re having XML serialization to generate the source code for you. The generated assembly and the source code can be found in %temp% folder. The name of the file looks like a combination of some random characters, such as x5n5uhgy.dll and x5n5uhgy.cs.

Now you have the source file and it’s straightforward to fine tune it to suit your need.

2. Naming the serialization assembly

In order to build the serialization assembly, you also need a project. Just create a class library project with Visual Studio and add the source file into the project. When naming the assembly, you’ll need to follow the name convention. Let’s say the type being serialized lies in YourApplication.exe (or YourLibrary.dll), then the serialization assembly should be named YourApplication.XmlSerializers.dll (or YourLibrary.XmlSerializers.dll). You got the idea.

Now you build the project and get the serialization assembly, and you cannot wait to test it. It might work sometimes, in this case you’re done.

But sometimes, to your frustration, it doesn’t work, you find out XML serialization is still generating and using dynamic assembly even you’ve provided your own. Why?

3. Setting ParentAssemblyId

To answer this question let’s take a look at the following scenario: You created an assembly MyDataContracts.dll, and pre-created a serialization assembly MyDataContracts.Serialzation.dll for it. Later on you made some modifications to the type being serialized and recompiles MyDataContracts.dll, now there is a mismatch between the type inside MyDataContracts.dll and the serialization code inside MyDataContracts.Serialzation.dll, you can imagine what will happen if this old MyDataContracts.Serialzation.dll is being used with the new MyDataContracts.dll.

To solve this problem XmlSerializerVersionAttribute is introduced, it’s defined in System.Xml, the purpose is to prevent outdated pre-generated XML serialization assembly from being used. XmlSerializerVersionAttribute is used in generated assembly to save the identity information of its parent assembly (where the type being serialized lies in), and during run time, XML serialization will check if the identity information saved in the generated assembly matches the parent assembly, if the attribute doesn’t exist or the ID or version doesn’t match, the pre-generated serialization assembly will be ignored and dynamic assembly will still be generated.

If you look at the source code generated by XML serialization, you’ll find one line similar to the below:

[assembly: System.Xml.Serialization.XmlSerializerVersionAttribute(ParentAssemblyId = @"60d7b267-090e-4055-93a9-01d5489fa2ea,", Version = @"4.0.0.0")]

Mostly the answer to the previous question is that it fails the check of ParentAssemblyId, this happens when you rebuild the parent assembly which causes ParentAssemblyId to be changed – even if you didn’t change a single line of code!

Its obvious and easy to fix if there is a version mismatch, but for ParentAssemblyId mismatch, how can you get the right one? Using Reflector on System.Xml.dll you can find a method named GenerateAssemblyId, it’s the one that XML serialization uses to generate the ParentAssemblyId.

private static string GenerateAssemblyId(Type type)
{
    Module[] modules = type.Assembly.GetModules();
    ArrayList list = new ArrayList();
    for (int i = 0; i < modules.Length; i++)
    {
        list.Add(modules[i].ModuleVersionId.ToString());
    }
    list.Sort();
    StringBuilder builder = new StringBuilder();
    for (int j = 0; j < list.Count; j++)
    {
        builder.Append(list[j].ToString());
        builder.Append(",");
    }
    return builder.ToString();
}

You can write a simple console application and use this method to calculate the right ParentAssemblyId. Once you’ve got the new ParentAssemblyId, set it in the XmlSerializerVersionAttribute and recompile the project.

With that, XML serialization will happily load you pre-generated assembly!