Blog Moved

10 05 2013

Hey there. Just a quick heads up, I’ve moved my blog to http://www.bencode.net





WordPress Blog and ASP.NET MVC Integration

5 12 2010

This was too easy/cool to keep tucked away. I wanted the most cheap and cheerful way of listing the top 10 blog posts, into a larger, containing website I am building for a client. I started out by Googling (googeloper) “wordpress integration c#”. Unexpectedly, nothing obvious I was looking for surfaced. Most solution seemed to rely on having WordPress installed physically beneath the website, or proposed options such as FTP based integration. Yuck! No. I just wanted the 10 latest posts in real time (i.e. as of now). Hold on I thought, that’s exactly what feeds have been designed to do. Blog engines (such as WordPress) have excellent feed support, including a REST based API, support for RSS and Atom. Wowzers.

There is plenty of good information about those topics elsewhere. I really just wanted to demonstrate how simple it is to query such a feed taking a server side approach (assuming your web server has Internet HTTP GET access to the feed). To do this, I used System.Net.WebClient, LINQ to XML and ASP.NET MVC 3. The feed I am consuming is for a WordPress blog, but there is absolutely no dependency/coupling that the blog must be WordPress based. It could for example, be a Blogger feed.

Another factor that should be given consideration is whether taking a server side (e.g. ASP.NET) approach versus a client side (e.g. jQuery) approach is a better fit for you. If for example search engine visibility (SEO) of the integrated blog content is important to you, a server side approach may be a better fit.

1. Using a browser review the feed you’re targeting. For example, if the (WordPress) blog is http://example.com then have a look at http://example.com/feed/ or http://example.com/feed/atom. Below is a sample of the first chunk of Atom feed for this WordPress blog.

<?xml version="1.0" encoding="UTF-8"?><feed
  xmlns="http://www.w3.org/2005/Atom"
  xmlns:thr="http://purl.org/syndication/thread/1.0"
  xml:lang="en"
  xml:base="http://bencode.net/wp-atom.php"
  xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"  >
	<title type="text">benCode</title>
	<subtitle type="text">Ben Simmonds: BizTalk Server Guy in Sydney</subtitle>

	<updated>2010-11-24T02:03:03Z</updated>

	<link rel="alternate" type="text/html" href="http://bencode.net" />
	<id>http://bencode.net/feed/atom/</id>
	<link rel="self" type="application/atom+xml" href="http://bencode.net/feed/atom/" />

	<generator uri="http://wordpress.com/">WordPress.com</generator>
<link rel="search" type="application/opensearchdescription+xml" href="http://bencode.net/osd.xml" title="benCode" />
<link rel="search" type="application/opensearchdescription+xml" href="http://wordpress.com/opensearch.xml" title="WordPress.com" />
	<link rel='hub' href='http://bencode.net/?pushpress=hub' />
		<entry>
		<author>
			<name>beness</name>
						<uri>http://www.bencode.net/</uri>
					</author>
		<title type="html"><![CDATA[SSO Configuration Road Block]]></title>
		<link rel="alternate" type="text/html" href="http://bencode.net/2010/11/24/sso-configuration-road-block/" />
		<id>https://bencode.wordpress.com/2010/11/24/sso-configuration-road-block/</id>
		<updated>2010-11-24T02:03:03Z</updated>
		<published>2010-11-24T01:58:25Z</published>
		<category scheme="http://bencode.net" term="BizTalk" /><category scheme="http://bencode.net" term="SSO" /><category scheme="http://bencode.net" term="Error" />		<summary type="html"><![CDATA[Recently I’ve had the need to setup a BizTalk Server 2006 R2 virtual machine. Quietly confident about my experience with this version of BizTalk, I jumped in head first to *quickly* get a simple single server based installation configured on a 32-bit VMWare based VM. Lesson learned today…never, ever underestimate the obscure errors that BizTalk [...]<img alt="" border="0" src="http://stats.wordpress.com/b.gif?host=bencode.net&amp;blog=2452880&amp;post=109&amp;subd=bencode&amp;ref=&amp;feed=1" width="1" height="1" />]]></summary>
		<content type="html" xml:base="http://bencode.net/2010/11/24/sso-configuration-road-block/"><![CDATA[<p>Recently I’ve had the need to setup a BizTalk Server 2006 R2 virtual machine. Quietly confident about my experience with this version of BizTalk, I jumped in head first to *quickly* get a simple single server based installation configured on a 32-bit VMWare based VM.</p>

2. Below is a snippet of simple C# that leverages LINQ to XML to parse an Atom feed. This code is in a controllers action method, because of ASP.NET MVC, but again this code has no requirement for you to be using MVC. Side note: LINQ to XML makes working with XML much more fluid for the C#/VB developer. Very very nice to use!

public ActionResult Index()
{
  XNamespace xsd = "http://www.w3.org/2005/Atom";
  var client = new WebClient();
  var feed = client.DownloadString("http://www.bencode.net/feed/atom");
  var document = XDocument.Parse(feed);
  var blogs = 
    from e in document.Descendants(xsd + "entry")
    select new BlogModel()
    {
      Title = (string)e.Element(xsd + "title"),
      Content = new HtmlString((string)e.Element(xsd + "content"))
    };
  return View(blogs);
}

3. A simple MVC 3 Razor view:

@model IEnumerable<MvcApplication.Model.BlogModel>

@{
    View.Title = "Blogs";
    Layout = "~/Views/Shared/_Layout.cshtml";
}

<h1>Blogs</h1>

@foreach (var blog in Model) {
<div class="blogpost">
  <h2>@blog.Title</h2>
  <p>@blog.Content</p>
</div>
}

4. Downloading, streaming, parsing and rendering this feed should be considered an expensive operation. Something that you probably don’t want to happen for each request that comes in for your page/site. To cache this entire “pipeline” of work, I went with some ASP.NET MVC output caching, by marking up the controller action with the following custom attribute:

[OutputCache(VaryByParam="none", Duration=60)]
public ActionResult Index()
{
  ...

The result:





SSO Configuration Road Block

24 11 2010

Recently I’ve had the need to setup a BizTalk Server 2006 R2 virtual machine. Quietly confident about my experience with this version of BizTalk, I jumped in head first to *quickly* get a simple single server based installation configured on a 32-bit VMWare based VM.

Lesson learned today…never, ever underestimate the obscure errors that BizTalk Server can produce. The install was smooth sailing. But when the time came to configure SSO, this:

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

I wracked my brain for a previous solution to this, but never have I seen this. There is speculation this may be a very rare bug that arises only in the context of doing single server VM based configurations. Regardless of the cause, it is not helpful.

Thank you to Mikael Sand, for detailing the solution to this. Un-configure and manually blast away any features and/or databases the configuration tool may have created. Create the two groups “SSO Administrators” and “SSO Affiliate Administrators” (alternatively name them whatever you like) manually. Add the account you are running the configuration tool under, and the BizTalk service account to these newly created groups. Log off. Re-run the configuration tool.

Sheesh!





BizTalk Server 2010 Prerequisite CAB Files

3 10 2010

Exciting times! BizTalk Server 2010 is out and as per every major release of the product there are a fresh set of redistributable CAB links to hunt down. These links available from the official installation guides.

 

Windows Server 2008 and 2008 R2

Language

Windows Server 2008 32-bit Edition

Windows Server 2008 64-bit Edition

Windows Server 2008 R2

EN

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x409

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x409

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x409

CN

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x804

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x804

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x804

DE

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x407

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x407

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x407

ES

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x40a

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x40a

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x40a

FR

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x40c

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x40c

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x40c

IT

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x410

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x410

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x410

JA

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x411

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x411

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x411

KO

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x412

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x412

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x412

TW

http://go.microsoft.com/fwlink/?LinkID=189407&clcid=0x404

http://go.microsoft.com/fwlink/?LinkID=189408&clcid=0x404

http://go.microsoft.com/fwlink/?LinkID=189409&clcid=0x404

 

Windows Vista and 7 64-bit Editions

Language

Windows 7

Windows Vista

EN

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x409

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x409

CN

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x804

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x804

DE

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x407

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x407

ES

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x40a

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x40a

FR

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x40c

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x40c

IT

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x410

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x410

JA

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x411

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x411

KO

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x412

http://go.microsoft.com/fwlink/?LinkID=189405clcid=0x412

TW

http://go.microsoft.com/fwlink/?LinkID=189404&clcid=0x404

http://go.microsoft.com/fwlink/?LinkID=189405&clcid=0x404

 

Windows Vista and 7 32-bit Editions

Language

Windows 7

Windows Vista

EN

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x409

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x409

CN

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x804

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x804

DE

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x407

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x407

ES

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x40a

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x40a

FR

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x40c

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x40c

IT

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x410

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x410

JA

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x411

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x411

KO

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x412

http://go.microsoft.com/fwlink/?LinkID=189406clcid=0x412

TW

http://go.microsoft.com/fwlink/?LinkID=189403&clcid=0x404

http://go.microsoft.com/fwlink/?LinkID=189406&clcid=0x404





BizTalk Servers Slow First Hit

2 08 2010

Lately I been thinking about BizTalk Server, and a particular behavior that it consistently demonstrates without fail. It takes a dreadful amount of time to service a “cold” request, however once “warmed”, it hums.

Its challenging at best to justify this behavior to a technology ignorant client.

Without getting too deep into BizTalk Servers internals (I would love to spend some time with windbg and the SOS extension digging around), I wanted a way to have partial control over how BizTalk Server manages the actual processes that invoke the code we make. All mainstream BizTalk artefacts (orchestrations, maps, pipelines) boil down to managed code (IL). BizTalk consumes our crafted “business” assemblies (dll’s) by loaded them into its address space through one or more AppDomain’s, at which time the messaging engine can call out to them when it sees fit.

This spawns a number of related questions; how many dll’s per appdomain? Under what conditions does an appdomain’s get “garbage collected” by the messaging engine? And so on. So I digged a little deeper.

Thanks to Tomas Restrepo for posting the excellent MSDN link to Orchestration Engine Configuration, which in essence sums up everything I wished for. Basically it involves hacking the BTSNTSvc.exe.config, which host instances take into account when started. While you can do cool things like control dehydration behaviour, and more, I was more interested in this:

Assemblies are assigned to named domains using assignment rules (see more below). If no rule is specified for some assembly, the assembly will be assigned to an ad hoc domain. The number of such assigned assemblies per ad hoc domain is determined by the value of AssembliesPerDomain.

Which translates to this in btsntsvc.exe.config:

<AppDomains AssembliesPerDomain="10">
   <AppDomainSpecs>
      <AppDomainSpec Name="FooDomain" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="-1" />
   </AppDomainSpecs>
   <ExactAssignmentRules>
      <ExactAssignmentRule AssemblyName="Foo.Orchestration, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f3a0f87e62e465c" AppDomainName="FooDomain" />
   </ExactAssignmentRules>
</AppDomains>

The interesting properties SecondsEmptyBeforeShutdown and SecondsIdleBeforeShutdown, are defined as follows:

SecondsEmptyBeforeShutdown is the number of seconds that an app domain is empty (that is, it does not contain any orchestrations) before being unloaded. Specify -1 to signal that an app domain should never unload, even when empty.

SecondsIdleBeforeShutdown is the number of seconds that an app domain is idle (that is, it contains only dehydratable orchestrations) before being unloaded. Specify -1 to signal that an app domain should never unload when idle but not empty. When an idle but non-empty domain is shut down, all of the contained instances are dehydrated first.

Thanks to Mick Badran, who has posted a handy BTSNTSvc.exe.config template, which includes the AppDomain configuration section discussed above.

UPDATE: Here’s a copy of my own *no frills* template:

<?xml version="1.0" ?>
<configuration>
  <configSections>
    <section name="xlangs" type="Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess" />
  </configSections>
  <system.net>
    <connectionManagement>
      <add address="*" maxconnection="48"/>
    </connectionManagement>
  </system.net>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking;Tracking\interop" />
    </assemblyBinding>
  </runtime>
  <system.runtime.remoting>
    <channelSinkProviders>
      <serverProviders>
        <provider id="sspi" type="Microsoft.BizTalk.XLANGs.BTXEngine.SecurityServerChannelSinkProvider,Microsoft.XLANGs.BizTalk.Engine" securityPackage="ntlm" authenticationLevel="packetPrivacy" />
      </serverProviders>
    </channelSinkProviders>
    <application>
      <channels>
        <channel ref="tcp" port="0" name="">
          <serverProviders>
            <provider ref="sspi" />
            <formatter ref="binary" typeFilterLevel="Full"/>
          </serverProviders>
        </channel>
      </channels>
    </application>
  </system.runtime.remoting>
  <xlangs>
    <Configuration>
      <AppDomains AssembliesPerDomain="10">
        <AppDomainSpecs>
          <AppDomainSpec Name="FooDomain" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="-1" />
          <AppDomainSpec Name="BarDomain" SecondsIdleBeforeShutdown="-1" SecondsEmptyBeforeShutdown="-1" />
        </AppDomainSpecs>
        <PatternAssignmentRules>
          <PatternAssignmentRule AssemblyNamePattern="Net.benCode.Foo.*, Version=\d.\d.\d.\d, Culture=neutral, PublicKeyToken=.{16}" AppDomainName="FooDomain" />
          <PatternAssignmentRule AssemblyNamePattern="Net.benCode.Bar.*, Version=\d.\d.\d.\d, Culture=neutral, PublicKeyToken=.{16}" AppDomainName="BarDomain" />
        </PatternAssignmentRules>
      </AppDomains>
    </Configuration>
  </xlangs>
</configuration>




BizTalk Server 2009 Unit Testing

13 06 2010

I feel like i’ve missed the boat with this, but the “first class” unit testing support that has been added to BizTalk Server 2009 is terrific. Unit testing with BizTalk Server up to this point, has always been very involved and custom.

How was this ground breaking feat made possible? A project level build switch has been added to all Visual Studio BizTalk project types. Check it out, bring project properties up for any BizTalk 2009 project in your solution, and there will be an “Enable Unit Testing” true/false flag sitting there.

Setting this to true, instructs the BizTalk MSBuild tasks that take our precious BizTalk artefacts like orchestrations, maps, pipelines and so on and parses and compiles them into MSIL, to add an extra layer of inheritance between for example, our pipeline and the real BizTalk pipeline base class. A whole family of these new “intermediate” testable classes live in the Microsoft.BizTalk.TestTools.dll assembly (available under c:\Program Files(x86)\Microsoft BizTalk Server 2009\Developer Tools\) such as Microsoft.BizTalk.TestTools.Pipeline.TestableReceivePipeline and Microsoft.BizTalk.TestTools.Map.TestableMap.

Now the level resistance to getting effective unit tests up an running is so low, there really is no excuse not to have good repeatable unit tests across all your BizTalk artefacts.

Here’s a small snippet (intended for use as an MSTest unit test) that invokes a BizTalk map, and verifies the resulting output using some LINQ to XML.

[TestClass]
public class MapTests
{
  public MapTests() { }

  public TestContext TestContext { get; set; }

  [TestMethod]
  public void Foo_To_Bar()
  {
    TestableMapBase map = new Foo_To_Bar();
    map.ValidateInput = false;
    map.ValidateOutput = false;
    map.TestMap(
      "input.xml",
      InputInstanceType.Xml,
      "output.xml",
      OutputInstanceType.XML);

    var document = XDocument.Load("output.xml");

    string interchangeId =
      (from header in document.Descendants("Header")
       select (string)header.Element("InterchangeId")).Single();

    Assert.IsTrue(interchangeId.Length > 0);
  }
}





Back To Basics: Sharing Libraries in a Team

13 06 2010

When developing in a team consisting of more members than yourself, you’ll quickly run into the scenario where shared libraries and/or other similar resources need to be shared in someway.

Its especially nice when you can cleanly compile code freshly pulled from source control. In my opinion, this is a must. Sloppiness here can cause heartache throughout the the entire development lifecycle of the project. This problem is aggravated with the introduction of new starters that come on board…they do a get latest, build and spend the next few days crawling through hundreds of build errors.

So what to do with all those third party assemblies that have made their way into the code base? If Alice added the references on her box, checks in, Bob is not going to be happy when he goes to do a “get latest”.

Its at this point most environments i’ve worked within take the laziest and simpliest option. “Hey everyone, we need to make that we all bind source control to the same local working folder (e.g. c:\projects\) mmmkay?”. If everyone has a local working folder of c:\projects, then absolute dll’s references should resolve just fine. While this is simple and can work, is rarely documented beyond the developers that came up with the plan.

What alternatives are there? Several, they all involve adding a layer of indirection, so the physical location of the assemblies is abstracted away from the project references. The simplest and effective strategy I have seen leverages subst (or the more modern symbolic linking support now available in Vista and higher using mklink). The idea is in source control, maintain a hive of pre-built assemblies that are common across the team, for example:

$/Foo.Common.Hive/NUnit.Framework/1.1.23.0/NUnit.Framework.dll
$/Foo.Common.Hive/bLogical.Shared.Functoids/1.0.0.0/bLogical.Shared.Functoids.dll

Bind them to a physical location *anywhere* on your development/build box. Run the following command:

subst q: c:\local\location\of\your\choice\

This will create a virtual drive (q:) on the machine that actually resolves to the contents of the “c:\local\location\of\your\choice\” directory. Visual Studio assembly reference’s should be added through the virtual (q:) drive – hence adding a layer of abstraction. The only catch is all developers need to ensure that the virtual drive is subst’ed prior to building—however on the plus side, I can put the source where I like, and the chances of getting a clean build have been improved significantly.