Ramblings of An OverTaxed Mind

Terrarium Returns

Douglas Marsh — Thu, 17 Jul 2008 04:51:53 GMT

In ancient antiquity, members of the Microsoft .NET Framework team envisioned a universe where creatures would compete for Ecosystem dominance. Terrarium was that universe and it was good.

The .NET Terrarium was a .NET 1.x game/learning tool that allowed developers to develop "creatures" that where then released into a peer networked ecosystem to battle it out for world dominance.
The Terrarium has a large following but as the original developers moved on the universe stagnated and died... until now.

This post on Bil Simsers blog announces the reintroduction of the .NET Terrarium... as a CodePlex project!!!! So not only can you participate in bug battling goodness, you can help develop the next generations of the Terrarium. So go check-out http://www.codeplex.com/terrarium2 and I'll see you on the battlefield.

Cannot locate document specification because multiple schemas matched the message type

Douglas Marsh — Wed, 09 Apr 2008 01:47:31 GMT

I ran into an interesting issue a couple of weeks ago and I thought I would share.

1st, the meat of the post.

If you have extracted the schemas from an XmlSerializable object and deployed those schemas to BizTalk, you can't use that object (or any of its dependant objects) as a BizTalk message type.
Why? Because BizTalk registers XmlSerializable types that are used as messages as schemas. If you have already registered the schema, you will end up with message type duplication.

_____________________________________________________________________________________________________________________________________________________________________
I was working on an application where BizTalk was operating as a SOA messaging bus.
The system was designed to receive data from a number of different systems, map that data to a canonical object model.

The canonical object model consisted of several XmlSerializable classes written in C#.
I used xsd.exe to extract schemas for the objects so that I could use the BizTalk mapper to map to and from the object model.

All of this worked great until I decided to break some common functionality into a separate orchestration.
Since no mapping would occur in the Helper orchestration, I decided to pass the canonical object directly to the orchestration.
I also decided that calling the Helper orchestration via Direct Message Box binding would increase its overall utility and reduce coupling.
The end result was that I created a Message Type and a Port Type that referenced the canonical object instead of the canonical object schemas.

I deployed my changes and submitted a test message.
As soon as my "core" orchestration called the new helper orchestration, I got a familiar error message in an unexpected point in the process.

Cannot locate document specification because multiple schemas matched the message type

My first reaction was total disbelief. I hadn't changed any schemas. In fact, I didn't even redeploy my schema project.
I checked the Schemas folder under BizTalk Application 1 and there was only one schema with the offending namespace#rootnode combination.
So I checked the Schemas folder under <All Artifacts> and there where two schemas... and the new schema was filed under the BizTalk.System Application.

I this point, I was quite confused. You can't deploy to BizTalk.System. It is for system use only.
I dug a little deeper and discovered that my Canonical object C# assembly was the source of the duplicate schema... and then I understood.

My canonical object model was already "registered" in BizTalk via the schema I generated to enable mapping to the object model.
When I used the canonical class as a message type, BizTalk extracted the schema from the serialization metadata and registered the resulting message type with the messaging engine.
Because both schemas are the same, I had duplicate message types.

Luckily the fix was simple. I changed the Message Type and a Port Type to use the canonical object schemas and serialized between the different object representation in the orchestrations before sending the data to the Message Box.

The "Scripting" has [x] input parameter(s), but [y] parameter(s) are excepted

Douglas Marsh — Mon, 31 Mar 2008 01:11:57 GMT

Here is an issue with the BizTalk mapper that resulted in a little hair loss recently.

I was working on a fairly complex BizTalk map that was using scripting functiods to reference functions in an pre-existing .NET assembly.
In a couple of instances, the code in the Helper assembly wasn't quite what needed, so I switched from using the Helper Class function to using inline C#.
Once I changed the functiod to use inline C#, the Configure Functiod Script dialog looked like the screen-shot below.

As you can see, even though the Script type is Inline C#, the configuration for the External Script is still their. This is very important.

For most of the "one-off" functions, I needed more parameters than what was need by the original .NET assembly functions.
So I wired up all of my links, click Build and ended up with the following error.

The "Scripting" functoid has [X] input parameter(s), but [Y] parameter(s) are expected.
Note: X and Y are place holders for the actual number of parameters.

Ok. I've seen this message plenty of time before. I click through each of the scripting functoids in the error list. However, all of them had the right number of parameters.
I clicked build again.

The "Scripting" functoid has [X] input parameter(s), but [Y] parameter(s) are expected.

Ok. Visual Studio must be acting up, so I cycled the entire machine to make sure an potential cache issues are resolved.
Once the machine booted and I got Visual Studio restarted, I tried to build the project again.

The "Scripting" functoid has [X] input parameter(s), but [Y] parameter(s) are expected.

Now I'm mad. I know that the functiods have the right number of parameters. Cycling the box should have fixed any weird "out of synch" errors.
So I start tried a little bit of everything. I disconnect and reconnect links. Nothing. I change the order of the parameters. Nothing.
Finally, I reset the inline script buffer and re-pasted the code... and that function disappeared from the error list.

Hmmm, so what's the difference

Pre-Reset	Post Reset

Resetting the Functoid cleared the External Assembly Configuration.

With this new information in hand, I open the map up a raw XML to take a look at the guts of the situation. This is what I found:

Originally, all of my scripting functoids used methods from the External Assembly. When I decided to use, Inline C#, I modified the existing functiod. Instead of removing the reference to the External assembly function, the functoid added the inline function to the already defined Scripter Code block. Because my inline function required a different number of parameter than the function from the external assembly, I was getting an input parameter count error.

That brings me to the moral of the story, anytime you are changing the way a scripting functoid is being used, hit the "reset" key. It will save you a world of pain.

I'm BAAAACK

Douglas Marsh — Sun, 30 Mar 2008 21:02:05 GMT

To all my readers.
I apologize for the long hiatus (ok temporary blog abandonment) but life happens.
Anyway. I'm making every attempt to do better and keep bring you BizTalk goodness.
I have a couple of posts in the works that will be up in next couple of days.

Thanks for staying around.

Workaround from BizTalk 2006 Enterprise Adapters Binding File Issue (KB923733)

Douglas Marsh — Wed, 15 Aug 2007 19:20:37 GMT

If you've ever worked with the BizTalk 2006 Enterprise Adapters (ie Oracle Database, etc) you might have run into the following error when import a binding file or msi:

Could not validate configuration of Primary Transport of Send Port 'portname' with SSO server.
Specify user name and password (Microsoft.BizTalk.ExplorerOM)

More information is available here: http://support.microsoft.com/kb/923733

There is a hotfix available but waiting to get the fix from Microsoft Support can consume valuable development time, so here is a dirty little workaround that I know works for the Oracle Database Adapter.

Extract a Binding File from the offended application(s).
Open the file in your favorite text editor and find the Send and/or Receive Port that is reference the Oracle Database Adapter.
Find the Configuration Property for Password and changed the masked password for the real plain text password.

This will fix your binding import issue until you can obtain the hotfix.

Exception From HRESULT: 0x800F0901 in Silverlight 1.1 Refresh

Douglas Marsh — Wed, 01 Aug 2007 06:07:43 GMT

Update:
This is a little late but a better workaround was posted on http://silverlightrocks.com/cs/blogs/silverlight_games_101/default.aspx
However, for some reason, I can now longer find the post.

Basically, instead of using creating the Storyboard from XAML, create the StoryBoard in code and using the SetValue method to set the Name Property

StoryBoard animation = new StoryBoard();
animation.SetValue<string>(StoryBoard.NameProperty, "myAnim");

One of the breaking changes in the Silverlight 1.1 Refresh deals with Canvas.Resources

Elements in <*.Resource> blocks must be named

Elements in <*.Resource> blocks must be named.
This means you have to have an x:Name property for all content in a <*.Resources> section.

For example:

XAML

<Canvas.Resources>
    <Storyboard>
        
    </Storyboard>
</Canvas.Resources>

Current:

XAML

<Canvas.Resources>
    <Storyboard x:Name="name">
        
    </Storyboard>
</Canvas.Resources>

Here is the "REAL" breaking change.

Canvas.Resource will no longer accept a Storyboard without a value in the x:Name Property.
If you are constructing a Storyboard in Managed Code using the Storyboard constructor, you will get this RunTime Error on adding the Storyboard to Canvas.Resource

"Exception from HRESULT: 0x800F0901"

You can't assign the x:Name property from code. But there is a workaround using XamlReader.Load();

The xaml string that you use to initialize the Storyboard must include the following namespaces or XamlReader will not load the string.

xmlns='http://schemas.microsoft.com/client/2007'
xmlns:x='http://schemas.microsoft.com/winfx/2006/xaml'

It's a pain but at least there is a workaround.

Tag I'm It

Douglas Marsh — Mon, 23 Jul 2007 03:58:23 GMT

I just got tagged by my buddy Bill.
So I'm the little brother he never had. Nice to know that I mean that much.

Any way, here are a few things I couldn't live without.

My wife Swann.
Many would consider this a cop out but seriously, without Swann I would be stuck in some behind a computer searching Lexus Nexus trying of convince myself that I like to practice law... not a pretty picture.
Plus without Swann as a grounding point, I don't think I would be a very nice person. She has really soften that serious anti-social edge I used to have.

Skittles.
About 6 years ago while getting my degree in MIS from the University of Alabama, I decided that I should cut down on my candy intake. Bad idea. After about 2 weeks Swann mandated that I never try that again. Have I mentioned that I can be a real ahole at times.

Sunflower Seeds.
See above. Replace Sugar with Salt and Fatty Acids.

Books.
I read... a lot. Currently my favorite author is John Ringo but I will read anything Military Sci-Fi that's decently written. At one point I would read anything but I've been forced to reduce my word intake so that I have time to do other things. Since Swann is the Community Relations Manager at Barnes and Nobles Edgewood, I get the benefits of a really sweet employee discount.

A Computer
I've loved computers every since my parents bought a little 33mhz Packard Bell with 4 megs of ram running windows 3.11. I spent hours on that thing hacking batch scripts and command files trying to tweak every hertz of power I could out of it. We didn't have network access to everything was trail and error. Anybody else remember HIGH MEMORY and LOW MEMORY. MOUSE.COM. Manually loading Sound Blaster 16 drivers. Ahh the good ole days... I really need to upgrade my home desktop.

TV
Network Television Sucks... but I'm addicted to the boob-tube and the state of currently television is surely destroying my braincells. I always find myself watching between 2 and 4 hours of TV a day. Most of the time I'm reading or performing some other activity while the TV is on but I will always catch myself vegging out at least a couple of times a week. Fortunately cable is getting really good. My favorite channel is Military History. Swann's is the Food Network. A safe compromise is The Discovery Channel. Having a Geek for a wife is great.

Now here is the hard part of being tagged. Tagging someone else. Well, this chain is going to stop with me. I've been online for a while but very few people know I exist.
So the couple of people that I could tag have already been tagged.

Solving the ‘Object Already Defined’ Error in BizTalk

Douglas Marsh — Thu, 12 Jul 2007 19:07:05 GMT

One of the weird BizTalk errors that's been around since version 2004 goes something like this:

Error    35
symbol 'MyNamespace.DataObject' is already defined; the first definition is in assembly c:\Development\Library\MyObjects.dll
C:\Development\Examples\BizTalk\ObjAlreadDefined.odx    169    50

This error has been blogged about several times. Example 1 Example 2
The standard "fix" is to remove the C# code that is found at the end of the orchestration file by:

Open the orchestration in notepad or as XML
Find (Ctrl-F) #endif // __DESIGNER_DATA
Delete all of the code found below #endif // __DESIGNER_DATA
Save and Recompile

Recently, I discovered a critical issue with that fix.
The code that you are removing is the code that allows BizTalk to export that orchestration as a public object.
So if you use the standard fix, you can't call the orchestration from another orchestration.

I believe that I have found the root of the problem and a much simpler fix.
The "Already Defined" object in my example is a reference object called MyNamespace.DataObject.AbstractData which is defined in MyObjects.dll. This object is used to create a varible instance called DataObject.
If I rename the variable DataObject to DataObject_AbstractData the compile issue goes away.

IMHO, when a Web Reference is added to the project, the orchestration compiler is no longer able to distinguish between part of a namespace and a variable instance of the same name.

So the moral of the story is to make sure your variable names don't conflict with any part of a namespace that in reference by your project. This "rule" goes for any variable.

Copying Elements with No Namespace in XSLT 1.0

Douglas Marsh — Sat, 07 Jul 2007 18:26:13 GMT

XSLT 2.0 is a wonderful standard.
One of the very useful additions is the ability to control the copying of namespace attribute within the copy and copy-of functions.
However, you don't always have the opportunity to work with the latest and greatest standard.

Below is a set of XSLT templates that will copy an Element in it's entirely without dragging along the namespaces.
Here is an example of how to call the template to copy and element to the destination document.
The example creates an Destination Name call Data the contains all of the contents of the Source node XmlData.

<xsl:element name="Data">
    <!—COPY CURRENT ELEMENT without Namespaces -->
    <xsl:call-template name="copy-node" >
        <xsl:with-param name="node" select="/XmlData" />
    </xsl:call-template>
</xsl:element>



<xsl:template name="copy-node" >

<xsl:param name="node" />

<xsl:call-template name="copy-element" >

<xsl:with-param name="element" select="$node" />

</xsl:call-template>
</xsl:template>





<xsl:template name="copy-element" >

<xsl:param name="element" />

<xsl:if test="$element" >

<xsl:element name="{name($element)}">



<xsl:call-template name="copy-attribute" >

<xsl:with-param name="attribute" select="$element/@*" />

</xsl:call-template>



<xsl:value-of select="$element/text()"/>



<xsl:for-each select="$element/*" >

<xsl:call-template name="copy-node" >

<xsl:with-param name="node" select="." />

</xsl:call-template>

</xsl:for-each>

              </xsl:element>

</xsl:if>

</xsl:template>





<xsl:template name="copy-attribute" >

       <xsl:param name="attribute" />

       <xsl:if test="$attribute" >

              <xsl:attribute name="{name($attribute)}">

                     <xsl:value-of select="$attribute" />

              </xsl:attribute>

       </xsl:if>

</xsl:template>

Keep Common Message and Port Types in an Empty Orchestration

Douglas Marsh — Thu, 05 Jul 2007 23:23:12 GMT

I'm working on a project where we are using a lot of common message types to abstract message handling logic.
Early on it became a real pain to recreate the same Multi-part message types and Ports for each Orchestration that was using these common messages.
To simplify development and maintenance of these types, I created a "Common Types" orchestration.
There is no logic in the Orchestration; it just defines commonly used schemas as Multi-Part Message Types. The associated Port Types are also defined.
Just define the type as public and reference the Common Types projects in the other Orchestration projects and you are ready to go.