Thursday 29 September 2011

Error messages

This is a new one.

500

If you see the monkeys, let me know.


Wednesday 28 September 2011

Assembly versioning (for .NET)

Like most people, I version my assemblies during the continuous integration build. This is achieved by generating a class file (I call it “AssemblyInfoCommon.cs”) during the build. It looks like this:

using System;
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

[assembly: AssemblyCompany("Acme")]
[assembly: AssemblyConfiguration("Branch.Release.1.0.xxx.xxx Debug")]
[assembly: AssemblyCopyright("Copyright © Acme 2011")]
[assembly: AssemblyFileVersion("1.0.xxx.xxx")]
[assembly: AssemblyInformationalVersion("1.0.xxx.xxx")]
[assembly: AssemblyProduct("PetShop")]
[assembly: AssemblyTrademark("Acme")]
[assembly: AssemblyVersion("1.0.xxx.xxx")]


Where…




  • “1.0.xxx.xxx” is the version number (we’ll come to the “xxx” value later")


  • The “AssemblyConfiguration” attribute breaks down as follows:

    • “Branch” is constant.


    • “Release” will vary depending on what you call your branches


    • “Debug” is the Visual Studio Solution configuration so will typically be “Debug” as shown or “Release”.




  • The company name, copyright notice and year all all passed in from the build script as variables.


  • The product name is whatever the project is called.



This is all pretty straight forward so far. However, down the years I’ve had problems with a strategy for the version number.



In the .NET world, the version number breaks down as follows:




[major].[minor].[revision].[build]




See MSDN.



Originally, the my version numbers broke down as follows:




1.0.yMMdd.x




Where “major” and “minor” are configured manually (these never automatically increment).



The “revision” number breaks down as follows:




  • “y” is the last digit of the current year. For 2011, this is “1”.


  • “MM” is obviously the month.


  • “yy” like wise for the day.



The “build” number represents the number of builds today, so the first build of the day takes “1”, the second “2” etc.



The would give you the following build numbers (I’m choosing old dates for a reason…):




  • 1.0.10926.1 – the first build on 26th September 2001


  • 1.0.11231.3 – the third build on 31st December 2001


  • 1.0.20101.4 – the fourth build on 1st January 2002



This worked pretty well for a number of years. Unfortunately, there is a constraint on the components of the version number that did not become apparent until 1st January 2006.



The first build number for 1st January 2007 was (in theory) “x.y.70101.0”. Unfortunately each component of the version number is an “Int32”. The largest value for an Int32 is “65534”, “70101” is bigger than this. Queue me getting build failure notification e-mails while on a beach in Thailand on New Year’s day, which was nice.



Since then, I’ve wrestled with a couple of different strategies but none ever really worked. The one I got most mileage out of was the same as before for Major, Minor and Build but had a different strategy for the Revision. I used the day of the year in combination with the year. So the Revision for…




  • 31st January 2011 would be “1031” (the 31st day of the year)


  • 2nd February 2011 would be “1032” (the 32nd day of the year)


  • 31st December 2011 would be “1365” (the 365th day of the year)


  • 1st January 2012 would be “2001” (the 1st day of the year)



This is problematic for two reasons:




  • You have to do maths to work out when a version was built.


  • Years ending in 0 (2010, 2020) cause problems because of leading zeros get dropped by the compiler. So 1.0.0001.0 (1st Jan 2010) would become 1.0.1.0 which is confusing.



Recently I’ve found a new strategy which works pretty well. The problem with the first strategy is fitting revision numbers for “high” years into an Int32, the problem with the second one is leading zeros. This third strategy overcomes this and breaks down as follows:




1.0.yyMM.ddxx




Where “major” and “minor” are as before.



The “revision” number breaks down as follows:




  • “yy” is the current year. For 2011, this is “11”.


  • “MM” is again the month.



The “build” number is as follows:




  • “dd” is the day.


  • “xx” is the build number of the day.



Examples:




  • 1.0.1109.2601 = 26/09/2011, 1st build of the day


  • 1.0.9912.3199 = 31/12/2099, 99th build of the day


  • 1.0.1201.0101 = 01/01/2012, 1st build of the day


  • 1.0.1112.3199 = 31/12/2011, 99th build of the day



There’s one caveat – best to not have more than 99 builds in one day but that is a highly unlikely scenario.


Tuesday 27 September 2011

BizTalk Message Box Viewer

The “BizTalk Message Box Viewer” is a nifty little tool that complements the BizTalk Best Practices Analyser very well:

http://blogs.technet.com/b/jpierauc/archive/2007/12/18/msgboxviewer.aspx


Monday 26 September 2011

BizTalk Best Practices Analyser (1)

Two issues that are easy to fix.

Details for both here: http://msdn.microsoft.com/en-us/library/aa561380.aspx

 

Thread Pool Setting of Host Instance MyHostInstance of Host MyHost

You need to change the registry settings. A example registry file (.reg) is as follows:

START FILE

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BTSSvc$MyHost\CLR Hosting]
"MaxIOThreads"=dword:00000064
"MaxWorkerThreads"=dword:00000064
"MinIOThreads"=dword:00000019
"MinWorkerThreads"=dword:00000019

END FILE

You will need to change “MyHost” to match your host name. If you create a .reg file with this content, you can easily merge it to your registry.

The “dword” values are as follows:

  • Max IO threads = 100
  • Max worker threads = 100
  • Min IO threads = 25
  • Min worker threads = 25

These values are taken from the MSDN link above.

 

No maxconnection Setting is Found in machine.config or BTSNTSvc.exe.config or BTSNTSvc64.exe.config

You need to change the following files:

  • %systemdrive%\Program Files (x86)\Microsoft BizTalk Server 2009\BTSNTSvc.exe.config
  • %systemdrive%\Program Files (x86)\Microsoft BizTalk Server 2009\BTSNTSvc64.exe.config

Add a “system.net” section as follows (by default, BTSNTSvc.exe.config and BTSNTSvc64.exe.config do not have such a section).

<system.net>
  <connectionManagement>
    <add address="*" maxconnection="12" />
  </connectionManagement>
</system.net>

Where the “maxconnection” value should be 12 multiplied by the number of processors on the server. The above is an example only, in my scenario each BizTalk server had two processors, so my “maxconnection” value was “24”.


Friday 23 September 2011

Cloud outages

A letter in The Economist earlier in the year puts an interesting perspective on cloud outages.

SIR – I was disappointed that your article added to the hysteria that surrounds cloud computing (“Break-ins and breakdowns”, April 30th). In my view cloud computing is like commercial aviation. Which is safer per-mile of travel: aircraft or automobile? Car crashes are responsible for more deaths, yet a plane crash is certain to make the news. For the same reason, cloud computing outages are considered newsworthy. Although the frequent down times of companies’ internal IT systems are less publicised, these down times almost certainly cause more harm and lost productivity in aggregate (like car accidents).

Air travel makes people uncomfortable, in part because of a loss of control, no matter how well trained and experienced the pilot may be. Similarly organisations fear cloud computing, preferring to be “behind the wheel”. Yet transportation statistics show that desire can be misguided.

Aviation had its share of hype and detractors, but no one would argue that it has not transformed travel. I predict that once the dust settles, cloud computing will be no less transformative.

Milo M.K. Martin
Associate professor of computer science
University of Pennsylvania
Philadelphia

http://www.economist.com/node/18712181


Tuesday 20 September 2011

How we see each other

I don’t know where this came from so I can’t credit it but many props to the original author, who ever you are.

Untitled


Monday 19 September 2011

Connecting to TFS Preview from Visual Studio 2010

Took me a few minutes to figure out why I was getting an error connecting to TFS Preview.

First (and most obviously) you need Visual Studio 2010 with SP1 applied. You should have SP1 by now anyway.

Secondly (and less obviously) you need to install KB2581206.

There is a link to “download software” on your TFS Preview Admin page which lists all this but it’s easy to miss the link to KB2581206.

When you have the hotfix installed, connecting is just the same as normal. From the “Add Team Foundation Server” dialogue in VS2010:

  • Name or URL of Team Foundation Server = [your account name].tfspreview.com
  • Connection Details:
    • Path = tfs
    • Port = 443
    • Protocol = HTTPS

You authenticate with a web identity provider e.g. Windows Live ID.

While its in preview, this hosted TFS solution is in Microsoft’s Chicago data centre. Even though it’s a hosted solution, you can still have your own TFS Build Agents.


Tuesday 13 September 2011

Windows 8

This poses a tricky question, though. You see, not only does IE10 power Windows 8′s primary interface, but Internet Explorer 10 — the browser — is also available as a Metro-style app, and as a full-interface browser in the Explorer Desktop. All three versions are fundamentally identical. Now… what if Windows 8 is as successful as Windows 7 and all of its previous forebears? What if Windows 8 is actually a success on the tablet? If Windows 8 becomes ubiquitous, so does Internet Explorer 10 — and if IE10 can be found on hundreds of millions of devices, what platform do you think developers will choose?

It’s the great Web App Dream: write once, run anywhere. Do you write an app for tens of millions of iPhones and iPads, or do you write a single piece of HTML, CSS, and JavaScript that can run perfectly on every Windows 8, IE10-powered tablet, laptop, and desktop? Those same web apps, with a little tweaking, will probably even work with Chrome and Firefox and Safari — but here’s an uncomfortable truth: if Windows 8 reaches 90% penetration of the computing market, why bother targeting a web browser at all? Just write a native, Metro-style web app instead.

Finally, add in the fact that IE10 will almost certainly come to Windows Phone 8 next year, and you will have a single app container — AppX — that runs across every damn computer form factor.

Microsoft, threatened by the idea of OS-agnostic web apps and browser-based operating systems from Google and Mozilla, has just taken the game to a whole new level — and, rather shockingly, given that Windows 8 started its development in mid-2009, it would seem that the lumbering behemoth might have actually out-maneuvered Google.”

http://www.extremetech.com/computing/95837-windows-8-the-first-browser-based-os

Interesting...


About Me