A colleague  of mine asked: “What kind of exception is thrown from the xml validation pipeline component?”. The reason was that she had to execute xml validation from within an orchestration, using as receive pipeline. Depending on whether the data was valid or not different actions would be taken. The solution was to put the pipeline execution in a scope and add exception handling. However; in order to catch only validation errors we had to know what kind of error is thrown. I set up this little orchestration:

The answer is that it throws an Microsoft.XLANGs.Pipeline.XLANGPipelineManagerException, which is caught in the first exception block.

So, now you know.

So, I will not be able to attend the Roskilde Festival this year (and MUSE cancelled their show in Stockholm), but the next best thing will kick-start the early autumn.

BizTalk User Group Sweden (or BUGS for short) has invited the crowd for a release party at Microsoft this fall. Not only is this a good pointer as to the actual release date of BizTalk 2010, but it is also a very interesting and cool thing to attend – if you are in to BizTalk and related stuff.

The event will include Richard Seroter (and shameless book-plugs), Ewan Fairweather and Stephen Thomas. Two whole days of fun, excitement, slides and demos. More information, and also a way to get tickets, can be found here.

This is just a personal reminder of the kind of error messages you get when you try to use the log for what it was never intended for. In this case I tried to dump validation errors from an XML validation.

So a “best practise” would be to dump information to the event log like this:

EventLog.WriteEntry("Heading", ex.Message.Substring(0, 32766));

Microsoft just saved me from a nice, warm, weekend in the sun! The BizTalk 2010 beta is now available.

Get it here: http://www.microsoft.com/downloads/details.aspx?FamilyID=0f852e77-f792-4784-b2d4-95113d40db64&displayLang=en#filelist

This is really something to look into and so I will. I heard the following in an interview with Stephen Kaufman and Danny Garber about on Channel 9 about their book.

“If you write a WCF service, I should be hosted in AppFabric.”

‘Nuff said! Learn AppFabric People.

I bit the bullet and bought me a SSD drive when I threw out the old “hay-dryer” since I had heard great things and also because… well what can be more quiet than an SSD? I have installed Windows 7 on the SDD an everything else on the 1TB SATA “classic” disc.

So here are the facts: I used this program to compare this SSD to this auxiliary drive. (I run 64-bit Windows 7).

I noticed that the SSD is actually slower that the classic drive when it comes to sequential writes, and that is about it. However it is actually better than the product specs from Intel. Those state a max of 80.

So, my computer is quiet and reads fast as “Speedy Gonzales” but should you upgrade your laptop to use an SSD go for the ones with faster writes. They are currently rated to 170 MB/s. They do however cost an arm and a leg… and possibly a cornea as well.

Ok read it again …

Yes you are right! BizTalk is looking for an element of the same name in the same namespace and yet it does not validate. What is this?

The answer is that the data uses ElementFormDefault: Qualified and the schema uses ElementFormDefault: Unqualified.

The qualified part of the “Blogpost” element is stripped in the error message, so be on the lookout!

Have you ever got this error message: “The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)” when running a BizTalk application? Perhaps a more precise description and full story is in order…

The error

I read this to a colleague of mine, who had previously stated that “long filenames can get you into trouble when used on pipelines”. Her response was one of recognition and so I began searching for reasons and maximum lengths. Despite Google's lack of answers I found that the main reason is that the fully qualified name of the pipeline is too long.

How long is too long

When developing pipelines, looking at the properties, the combined length of the “Namespace” and “Type name” properties cannot exceed 254. For those of you who wanted extra credit in school and want the number to be 256, well you are right because two more signs (“ ,”) are added between the type name and namespace thus making it 256. However these are added by deployment and you cannot omit them.

To be sure I have tested both the lengths of the type name and the namespace and I am sure that it is the combined length that must not exceed 254.

The reason

I am actually not sure that this is the actual reason (since I do not work for the MSFT product team) but evidence points to this: The reason is that the table column that holds the data in the management database cannot hold more that 256 nvarchar. I am not sure of this so any feedback is welcome.

To make matters worse I have not found any warning when deploying pipelines with long names. Also, the pipelines are imported into BizTalk, they are configurable and does not crash until used in runtime.

The rhyme

When developing BizTalk artefacts with a naming convention that uses long names; beware of the 254/256 limit.

This is only an issue if you are using a computer that is not part of the domain (typically a VPC configured for workgroup).

People that use BizTalk tend to have a nice image that sports VS, BizTalk, SQL server, and Team Explorer if you use TFS. 9 times out of 10 this image is not part of the domain were the TFS server resides. This means that every single time you open visual studio you have to enter your domain credentials! This is tedious, boring and sometimes quite irritating. The reason is that you do not get that nice little tick box that says; “Remember my password”.

However there is a nice work around.

Open Team Explorer, right-click a project and choose “Show Project Portal”.

You will then get this nice dialog asking for your credentials.

There is that nice little tick box! Simply enter your credentials, tick the box and click OK.

Now you don’t have to enter you credentials again when opening Visual Studio.

[Edit 2010-05-21]

Also, as pointed out by commenter Daniel Brünteson, you can easily add the credentials directly to the “Credential Manager”. This is a really nice way to handle credentials.
However, it is not a part of windows server 2003 or 2008, that tend to be the favoured operating systems when developing server side solutions. If you use Windows Vista (poor thing) or Windows 7 you can take full advantage of the credentials manager.

I have just sat thru a very good webcast called “Road Map for BizTalk Server: Business Automation and Integration Server”, presented by Sudhir Hasbe. For those who have seen the presentation concerning the road ahead for BizTalk at from PDF09 there was really only one important addition; they will upgrade the Trading Partner Management (TPM), but it must be in early beta because nothing specific was said about it.

Also he talked a lot about bringing in WF and still supporting XLANG.

After the presentation at PDF09, a community friend looked for some information about the new mapper and support for WF in the next version (2009R2). These were strong points at the PDC presentation. The thing is that he found the information but from a much earlier PDC (06?). There has also been a video on Channel 9 for ages demonstrating a new mapper.

So this time Sudhir played a video demonstrating the new mapper. My reaction was the same as always; I must have it! Give it to me! I you want to see it, look at the PDC presentation. It is about 25 minutes in.

So with the history of teasing and wetting our appetite I asked if we would actually get it this time and the answer was "*laughter* it's already in the product. It's in the TAP version".

Whohoo!

I for one cannot wait.

This is quite old, however very useful so I thought I would share it. Also I need to “get on the ball” and post something on my blog.

So, you try to delete a dll-file and get the error “could not delete the file because it is used by another process”. Often that process is Visual Studio so a simple restart does the trick. However, sometimes that does not cut it. So how to find the process:

1. Open a command tool (as admin)
2. Type tasklist /m nameofthelockedfile.dll
3. View list.

For more help about tasklist, type tasklist /? for help.

Now that you have the image name, kill the process and go about your marry way.

Windows Virtual PC (no not Microsoft Virtual PC) and I met up about the same time I installed Windows7 and also realized that the company laptop had support hardware assisted virtualization. Then I spent some time developing an image for BizTalk developers. After a while we all started noticing a “degradation in performance” or to put it bluntly; the performance was sh*t.

The problem was finding the solution since a Google search on “virtual pc bad performance” or “virtual pc slow mouse” turns up a lot of posts from people who simply needs a better computer. So I thought I would write a post that would turn up on Google when you search for the things I searched for. If you are a human reading this, you can skip to the solution at the end of the post.

When I started any image with the same settings and giving it as much resources as my laptop could spare (2,5 gb of memory), at first performance was good, but after about 10 minutes things started to slide downwards. Programs reacted slowly, graphics update was slow and things was generally miserable. At the worst point there was a clear delay for about 5 seconds from when I clicked the mouse button to when the interface responded. Of course I checked all the usual things like program priority and limiting SQL-server memory use.

These were the visible symptoms: slow interface and slow mouse.

The “invisible” was: High level CPU usage. Reaching 100% at the slightest provocation.

The solution finally turned up in this blog post. There are other posts pointing out the same thing but this post was the only one I could find that gave an explanation. Not even Virtual PC Guy’s blog said why. The solution is really simple:

1. Turn of your virtual machine.
2. Use Run and type “appdata”.
3. Navigate to the Virtual PC settings file: “Local\Microsoft\Windows Virtual PC” (on Win7 using Microsoft VPC) or "Roaming\Microsoft\Virtual PC" (on Vista using Windows VPC) and open Option.xml
4. Add this to the file after the last <virtual_network>-tag.
   <virtual_machines>
      <enable_idle_thread type="boolean">true</enable_idle_thread> 
   </virtual_machines>
5. Save and reopen your virtual machine.

Personally I found an options-file in %appdata%\Roaming\Microsoft\Virtual PC as well and added the tag there to just to be safe. I don’t think you have to but better safe than sorry.

I used this in on Windows Virtual PC but I think it will work on Microsoft Virtual PC.

The explanation for the behaviour is the power management on the laptop. When you start your virtual machine, and start using it, the host OS thinks that it’s not very busy and turns off power to the processor to save energy (stupid I know). The host processor powers down and the guest processor gets even less time and so the guest processor is easily overloaded. The tag makes Windows Virtual PC use the host machine’s system idle thread therefore picking up the slack on the host machine processor.

Let’s hope “they” solve this in the next release.

Sometimes I think there is a grand conspiracy on my part. Somewhere deep within the windows core code there is a line like

if ( Instance.RegisteredUser = "Mikael Sand" )

    GenerallyFThingsUp();

And then I just remember that it probably is my own fault.

There is a strange BUG when you install BizTalk in a single server environment on a virtual machine. Strange being the operative word here. You get this error

Failed to generate and backup the master secret to file: C:\Program Files\Common Files\Enterprise Single Sign-On\SSO0FAB.bak (SSO) Additional Information (0x80070005) Access is Denied.

So what happens is that the SSO Administrators group is never created during install (note that all other groups are created). No SSO Admin group = Unsuccessful authentication = Access is Denied.

The solution is simple though:

1. Unconfigure BizTalk and delete the SSODB and BusinessRulesDB. The wizard does not delete them.
2. Now create the SSO Administrators group manually and add the install account and the BizTalk Service Account to it.
3. Log out and log back in. Restart the installation.

I have been battling the ESB Toolkit installation for a while now, hence the lack of posts. However I can see the light at the end of the tunnel. More stuff to follow.

I do not know what it is about the words “known issue” that ticks me off. Maybe it has to do with the fact that “known” aught to be replaced by “corrected”, or maybe it is the fact that I wasted an hour searching for a solution until I figured out that I could just Google it… Maybe it is both.

Anyway, this MSDN page explains that if you have VS 2008 + BT 2009 installed and then install Service Pack 1 for Visual Studio, you cannot create a new BizTalk project…

The error you get from Visual Studio is “Creating project ‘BizTalk project name’… project creation failed.”. Note that it is displayed in the status bar. A colleague of mine totally missed and just said that “nothing” happened.

The solution is to enable btproj as an extension in Visual Studio, using RegEdit. See MSDN link for more details.

Today I just had to solve a problem I have had for a while. When upgrading to Windows 7, I installed Daemon tools lite and everything was working fine. That is until last week or so when I started to get this strange error: This program requires at least Windows 2000 with SPTD 1.51 or higher. Kernel debugger must be deactivated. (Text in picture in Swedish).

It seemed that I was not the only one having this problem. A quick search on Google and the Daemon Tools forums revealed a barrage of bad language and people using the word “plz” a lot. This daemon tools forum post, is a good example. There were a lot of solutions but no one that worked on my box. Apparently Microsoft issued a patch that has wreaked havoc for many users, including me. One solution from Daemon tools was to uninstall this patch.

Since I am not a fan of uninstalling patches I tried other solutions and I found one that works for me: Turn off “DeepGuard” in F-Secure. Do not turn it off all together(!), just during Daemon tools start-up. Allow Daemon to start and then you can turn it on again. Also note that I had to do this even though the program is marked as safe in F-Secure.

This is not a permanent solution and you cannot use the auto start option in Daemon tools, personally I never did anyway.

[Edit 09-09-09]
It is the stangest thing! Once I disabled F-secure DeepGuard and started Daemon tools, everything is working well, even with DeepGuard turned on. The auto-start option even works.

[Edit 09-11-01]
A commenter named Allan solved the problem by turning off the Windows Firewall. Now this is something I would not recommend, however I might work like it did for me and F-secure. Turn off the firewall, start Daemon, turn on the firewall.

[Edit 09-11-10]
My Dameon Tools installation told me a couple of days ago that there was a new version available. This has full Windows 7 support and uses version 1.62 of SPTD. So, the troubles might be over. Get it at: http://www.disk-tools.com/download/daemon

[Edit 09-12-14]
Since people seem to still have some issues I must ask you to verify that you are using the same version as I, since after installing that I do not have any issues about the product. I am using DAEMON Tools Lite v4.35.5 (with SPTD 1.62), which is the version you get if you download from here. Also note that the good people at Daemon Tools have a forum.

[Edit 10-03-15]
Maikk posted a very useful comment: "for those still asking for help and are using vista/7 try running cmd and type bcdedit /debug off, Vista has a kernel debugger enabled by default, and this needs to be disabled.  forum.daemon-tools.cc/.../kernel-debugger-please-help-19048"