I run into something really annoying this morning with Itinerary DSL in VS.NET designer. The only way to create an itinerary is to create it in a project of a library type. This is confusing, since for a simple application, I should be able to achieve the same with a plain BizTalk project. The ironic part is that within BizTalk project creation of itinerary IS an option, but when selected, add a new (standard) BizTalk item dialog shows up, with no itinerary in it. A bug?

In order for a send port to subscribe, it has to filter messages dynamically, based on several Itinerary schema properties (as described in documentation). Properties and values are:

• IsRequestResponse = False
• ServiceName = Some_Service_Name
• ServiceState = Pending
• ServiceType = Messaging

Filtering is done on promoted property from Microsoft.Practices.ESB application. In order to use those promoted properties, first Microsoft.Practices.ESB application should be referenced. Basic knowledge for an experienced BizTalk developer, but wheel spinning time for someone new.

This is history repeating itself, so I wanted to share the story in case it will help someone.

For my cell phones I use Nokia. My next phone I wanted was N900 model. I was waiting for it, but it’s coming too slow to N. American market. So about a month ago I bought one on eBay, making sure it’s not a fake (asking the seller all kind of questions). The guy was a total jerk and lied all about it. I ended up getting a fake, which I complained about and got my money back (by PayPal) as a part of buyers protection plan which is great. Either way, this is not story about how I get tricked every time I buy a Nokia on eBay (yeap, it happened with previous models as well), but more to highlight the differences in case you buying one or planning, so that you don’t have to go through the same.

This is a thought I had to a post I read this morning. Doug, who’s running a company that does software development, has published a post about Developer Computers. It is interesting to observe developers position vs. business people position. Yes, developers want the latest and the greatest, and if possible, something that will be still up-to-date tomorrow. Business people often do the opposite; especially highlighting the fact that developer’s appetite for new hardware is not justifiable. Being developer myself, I’d like to show a few things, material for a thought.

We are utilizing NCover to perform code coverage as a part of CI process on the build server. On development machines, at least for now, we don’t have it (which is a bummer). PartCover (a free alternative to NCover) is not there yet, so we waited till the right time would come to buy workstation licenses. It looks like the time is almost right. JetBrains has announced they will release dotCover tool starting with the traditional EAP program (which is well known from R#).

A true asynchronous service operation is not the one that returns void, but the one that is marked as IsOneWay=true using BeginX/EndX asynchronous operations (thanks Krzysztof).

To support this sort of fire-and-forget invocation, Windows Communication Foundation offers one-way operations. After the client issues the call, Windows Communication Foundation generates a request message, but no correlated reply message will ever return to the client. As a result, one-way operations can’t return values, and any exception thrown on the service side will not make its way to the client. One-way calls do not equate to asynchronous calls. When one-way calls reach the service, they may not be dispatched all at once and may be queued up on the service side to be dispatched one at a time, all according to the service configured concurrency mode behavior and session mode. How many messages (whether one-way or request-reply) the service is willing to queue up is a product of the configured channel and the reliability mode. If the number of queued messages has exceeded the queue’s capacity, then the client will block, even when issuing a one-way call. However, once the call is queued, the client is unblocked and can continue executing while the service processes the operation in the background. This usually gives the appearance of asynchronous calls.

Can’t figure out how to run this combination. Anyone has it going?

Every new BizTalk project has the next line in AssemblyInfo.cs file:

The only way I could solve it was to instruct R# to ignore this error.

Has anyone dealt with it differently?

Specification based testing is kind of testing I prefer. Once in a while I like to see what’s available. This time, it was SpecFlow framework. Based on Gherkin style specification, it creates your specs, nicely integrating with Visual Studio .NET (I used 2008). This is what an output of a test written with SpecFlow looks like in VS2008 (used R# 5 Beta 2 for as a test runner).