Experienced a rather interesting problem with the MQSC adapter in a multiple server BizTalk Group. It seems only the first server gets the COM+ application installed.


The other servers, 2 in this case didn't have it. The errors you'll see:

The adapter failed to transmit message going to send port "SENDPORTNAME" with URL "mqsc://SOMECHANNEL.SVRCONN/tcp/". It will be retransmitted after the retry interval specified for this Send Port. Details:"Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))".

The BYOT Gateway could not delegate the activation. The component being created may be incorrectly configured. Process Name: BTSNTSvc64.exe

Error Code = 0x80040154 : Class not registered


COM+ Services Internals Information:

File: d:\w7rtm\com\complus\src\comsvcs\byot\byotex.cpp, Line: 450

Comsvcs.dll file version: ENU 2001.12.8530.16385 shp

The solution is to either remove the MQSC adapter from BizTalk and repair HIS or you can export the MQSC COM+ application from a server that has it and import it.

The first server I tried to export the application from kept exporting the MQS application despite click on MQSC (tried multiple times). In the end I found another server that had it and was able to import successfully. Not sure what that was about but I'm moving on.

MVC4 View Performance Issue

Users of  MyBrewCo have been complaining of it being a little slow and it's been something I needed to address. Not only do I not always see the issue it doesn't make a lot of sense as everything is heavily cached.


Had time over the weekend so I decided to dig a little deeper. Using MVC MiniProfiler I was able to find a page that seemed the most affected.  

The screenshot shows what MiniProfiler captured. Apart from a few multiple calls that I need to investigate the glaringly obvious issue is the 12 seconds that got sucked up rendering the View.    

12 seconds, holy crap! After some research I remembered reading about Sam Saffron's issue with the Compilation debug flag in the web.config. Whilst it's set to true on my dev machine it seems the Azure packaging process is taking it out as I logged on to the production VM and it wasn't there which is good but would have been a nice easy fix.

I found a StackOverflow post with a similar issue and it turns out that version 1.0 of System.Web.Optimization is a little sketchy and it's messing up the View optimizations, I updated the package to 1.1 (which requires updating WebGrease to 1.3). Deployed and straight away I noticed the entire site responded a LOT quicker. That page above now returns within 200ms and pretty big change from 6-12 seconds. Crazy stuff.