This is a new one.
If you see the monkeys, let me know.
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…
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:
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…):
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…
This is problematic for two reasons:
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:
The “build” number is as follows:
Examples:
There’s one caveat – best to not have more than 99 builds in one day but that is a highly unlikely scenario.
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
Two issues that are easy to fix.
Details for both here: http://msdn.microsoft.com/en-us/library/aa561380.aspx
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:
These values are taken from the MSDN link above.
You need to change the following files:
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”.
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
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.
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:
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.
“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...