Exception is: COMException – Retrieving the COM class factory for component with CLSID {093CB055-4B2E-4700-BAEB-7EE2DED9CB8B} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0×80040154 (REGDB_E_CLASSNOTREG)).

This was very strange as instantiating the service directly worked fine. StackOverflow to the rescue again. It appears that because my service was running in a 64bit app pool, the host process couldn’t locate the registration (There are separate portions of the registry used to store 32-bit and 64-bit applications)

The fix was simply to set the app pool to enable 32-bit support

def getStarSign(name):
    return name,42,'Taurus'

name, age, starSign = getStarSign('Jason Hyland')

print name, age, starSign

This just feels so intuitive. The alternatives in C# are just unsatisfactory: out params, returning tuples or dictionaries or other such ‘hacks’

Because I treat messages in BizTalk the same way that DTO’s are used in traditional domain driven development – the are merely a mechanism of passing data from the UI (or in my case an integration point) to the next layer.

However, I came across an error generating the class today referring to an ‘element is not declared’

After some head scratching I realised that it was complaining about a node that I’d imported from another schema. I guess this would have caused the generator a bit of a problem. Thankfully Google came to the rescue with this post from Martin Brown . I reproduce the code here (the post is almost 8 years old);

Schema 1

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/XMLSchema1.xsd"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:examp1="http://example.com/XMLSchema1.xsd"
    xmlns:examp2="http://example.com/XMLSchema2.xsd">

    <xs:import namespace="http://example.com/XMLSchema2.xsd" schemaLocation="XMLSchema2.xsd" />

   <xs:element name="example">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="test" type="examp2:myType" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

Schema 2

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/XMLSchema2.xsd"
    xmlns:examp2="http://example.com/XMLSchema2.xsd"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:complexType name="myType">
        <xs:sequence>
            <xs:element name="test" type="xs:string" />
        </xs:sequence>
    </xs:complexType>
</xs:schema>

So, the key trick is to pass in the imported schema in the XSD command line. The other thing to remember if you aren’t setting the output filename is to put the “real” instance schema at the end of the list of schemas otherwise you’ll get a file named after your imported schema.

xsd.exe schema1.xsd schema2.xsd /c

Thanks google!

Unless you are very lucky, when embarking on a major enterprise transformation you will have to deal with a significant base of legacy code. To you and many of your developers it’s probably seen as badly designed, poorly implemented code that someone else wrote and left you to maintain - or more commonly known as “not invented here” syndrome.  It has probably been serving the company well and making it money for many years. Your options are either a complete rewrite or integration with the current code base – or somewhere in between those extremes. Of course, you could have taken on so much technical debt maintaining your systems that you’ve now become bankrupt and defaulted. Even then, Uncle Bob cautions on the big redesign in the sky.

The company (they are the people that pay your salary) are likely to have limited sympathy anyway for most suggestions which involve the wholesale rewrite of this legacy code. Of course you can always roll out the trite arguments that the system will be easier to maintain, it will be able to adapt to new opportunities and can meet changing needs of the business much more quickly, it will save money in the long run. And do you know what they may even go for it. But, don’t underestimate the risk you are taking before embarking on a complete rewrite.

So, before you pull the trigger on the nuclear option, take some time to consider how you can live with a staged migration of systems and components.

The first thing we wanted to do is ensure that where possible, any new components or services we create utilise our new solution design. This would be pretty straight forward if our new components lived in isolation. Yeah, right. Think of all those little features that any new business requirement needs – for example, cross cutting concerns like configuration, logging, exception handling etc. So you start thinking about migrating some of these as well. Then you realise that if you migrate these, then you’ll soon be migrating other dependencies or worse, duplicating config stores, log locations etc.

As soon as you start pulling at the edges of your code base to look at what can be migrated to the new solution you soon run into these difficulties. A web of dependencies. One strategy to deal with this is to get your new and old code to integrate in a way which doesn’t pollute your new environment but allows you to leverage your existing infrastructure whilst staging the migration. Thankfully, Microsoft have thought this through and have given us some great tools to get components talking together.

In this series of posts I’m going to look at how we could deliver that integration

• How COM components can call WCF services
• How WCF services can expose legacy COM components
• How well does .NET/COM integration perform

If you want to learn more about the integration between .NET and COM I’d strongly suggest getting a copy of .NET and COM: The Complete Interoperability Guide. Whilst it’s almost 10 years old, much of the COM complexities are covered in great detail.