Christiaan Nieuwlaat .nl

IT Whizzkid behind the wheels of steel

May 14, 2012
by chris
0 comments

Site moved… caused delay

As you might have noticed, the second post about ASP.NET MVC 4 Displaymodes, has been delayed quite a bit. Main reason therefore was the move of my blog to another service provider. There were a lot of issues with the virtualisation platform which negatively influenced my virtual server and my site(s). This made me decide to relocate my blog to another provider.

As the relocation is finished I’ll post the aforementioned post in  a short while… sorry for the delay..

May 3, 2012
by chris
0 comments

Using MVC 4 DisplayModes to achieve per domain overridable views

One of the new features of the Microsoft ASP.NET MVC 4 framework is the concept of display modes. By default the framework uses the display mode functionality to “dynamically” select the mobile version of a view ( when present ), when you’re site is viewed on a mobile device.

In short this means it will use the <viewname>.mobile.cshtml/.vbhtml file as the view when available, and if it’s not available it will fall back to the normal <viewname>.cshtml/.vbhtml file. (I’m assuming you are using Razor syntax for your views.).

There are tutorials (like in this video on channel 9) that show how to extend this functionality to create a view for a specific device, like an iPhone or iPad. But this is just one of the possibilities.

Just the other day at the office, I’ve had to rewrite a website to support mobile devices. It’s been written on top of ASP.NET MVC 2, so I thought it was only logical to rewrite it with ASP.NET MVC 4. Seems to me like the obvious path to choose, until I took a good look at the way the current site worked.

The site was written in a way that it could be loaded from multiple domains, and used a different set of views and resources based on the host header. To get that done in MVC2 I’ve created my own ViewEngine derivative at the time. As I didn’t want to do that again ( and potentionally lose Razor syntax goodness etc.. ) in this version, it was a challenge to get my head around it, but I’ve got it working like a charm. The key player in the solution is the MVC 4 DisplayModes functionality.

In short: If you can use the display modes to select a different view based on the user agent, you can do more-or-less the same based on the host header. Now I know there are multiple ways to get this done, but as I had to support an arbitrary configurable amount of “themes”, I chose to do it on a more-or-less centralised approach. Summarized I’ve created 2 DefaultDisplayMode derivative classes and overrode the
GetDisplayInfo method to incorporate the ‘load the theme based file’ logic. I’ve created 2 classes, because I wanted to separate the mobile and the non-mobile logic, but you could do it in one if you’d like. All I’ve had to do after this is to insert them in the DisplayModes collection so they will be used by the MVC framework.

I’ll be posting a more elaborate version (including some source code) of the solution shortly. But for now, I hope you’ve got the idea how I’ve tackled it.

April 22, 2012
by chris
0 comments

Passed the 70-595 ( a.k.a. MS BizTalk 2010 ) exam

As you might have noticed, It’s been a while since my previous post.
This is caused foremost by the busy schedule I’m having the last couple of months, and when I get home from work, I usually just want to relax a bit. ( and forget to post here ;) )

But… in the meantime I’ve been busy updating my skills, and due to a conversation I’ve had with fellow BizTalk developers I’ve decided to try to get certified as a MCTS for MS BizTalk 2010.
It took quite a bit of preparation and effort, but as a result of this, I’ve passed the Microsoft 70-595: TS: Developing Business Process and Integration Solutions by Using Microsoft BizTalk Server 2010 exam with flying colours…

November 3, 2011
by chris
0 comments

BizTalk WCF Send/Receive port connection problem

The last few days I’ve been hunting down a problem which is quite common under users of WCF. It seems WCF will only honor a specified amount of concurrent connections ( at default this will be 10 concurrent connections ) before ‘freezing’.

The most common causes of this ‘freeze’ are :

  • forgetting to Close() the client proxy (and connection) when you’re done processing
  • forgetting to call Abort() on the client proxy  whenever an exception has been thrown
  • using the ‘using (…) { }’ construction on the wcf client proxy.

When you forget one of these the connection will not be closed. ( or it will be closed later on by the framework itself, but that’s most likely not the way you want it. )

Sounds pretty easy right? Just enclose the proxy calls in a try – catch and make sure the connection gets closed properly.

It’s not that easy when you are using BizTalk Server as an endpoint. There are a few caveats when you’re having a complex ( multi application ) BizTalk solution which is using WCF adapters for its logical ports.

  1. Make sure when you use request/response ports to always return a response message, even when things fail in your orchestration(s). When you terminate the orchestration without returning a response, the connection will not be closed.
  2. When you have a multi application solution it gets even more important to do it right.Lets say you have an already existing (almost legacy) application which has a logical request/response port ( which is bound to a WCF receive location ) and this port has a fault operation, which works fine with the receive location itself. You have created an application which internally uses you’re existing application using the same logical port, and it has it’s own entryport, which is also a send/receive port using WCF as its receive location.

    You now need to be very sure that the new application uses  the send and receive actions and handles possible fault messages from the legacy application. Say the new application will send the old application a message and will wait indefinitely for an answer on the response operation, but the legacy application fails and sends a message on the fault operation, which isn’t picked up by the new application. This new application will never close the opened connection on the WCF receive-location.

If this happens about 10 times, it’s the end of the story for the new application receive location and it won’t respond anymore ( it hangs so-to-speak… ) The only thing you can do then is to forcibly stop and start the application pool ( when the receive location runs in the isolated host ) or the biztalk server process.