Monday, 18 October 2010

Visual Studio 2008 fails to create BizTalk 2009 project

I got bitten by this (again) on my new machine, putting this note here for my own reference as much as anything.

When attempting to create a BizTalk 2009 project in Visual Studio 2008…

  • File –> New Project… –> [Any BizTalk Project Template]

or

  • (From Solution) Add –> New Project… –> [Any BizTalk Project Template]

…you might get presented with the following error message:

  • Creating project ‘[Project name]’… project creation failed.

When you install Service Pack 1 for VS2008 it seems to overwrite a Registry key used by the BizTalk 2009 SDK. Putting the Registry key back to its original value fixes the problem.

The safest way to achieve this is to repair the BizTalk 2009 installation after installing Service Pack 1 for VS2008. The repair only takes a few moment to run (or at least it did for me). Some on-line resources suggest fixing the Registry key manually but I have trust issues with that and so long as you have the BizTalk 2009 ISO on hand, the repair operation takes about the same amount of time as opening RegEdit.exe and finding the right key (making sure you get the correct 32/64-bit Registry key).


Friday, 15 October 2010

What is coupling?

Coupling is a measure of dependencies. Where Component A depends on Component B, coupling exists.

The direction of coupling matters, there are two kinds:

  • Afferent – who depends on you.
  • Efferent – who you depend on.

There are characteristics and rules of thumb for different coupling “signatures”. For example:

  • An “Observer” class might have lots of efferent coupling but no afferent coupling i.e. the Observer will depend on lots of classes but few (or perhaps no) classes will depend on the observer. This is okay, it is probably expected.
  • Conversely, a framework component might have lots of afferent coupling but no efferent coupling i.e. lots of components might depend on the framework but the framework will depend on few (or perhaps no) components itself. Again, this is okay and is probably expected.

You may find coupling patterns within your application, depending on the specifics of your business domain.

When measured in this way, coupling becomes a useful metric. It enables you to ask questions like “If I change Component A, how many components will this impact?”. This information allows you to assess risk when making changes, therefore you are able to determine if you can change a component safely.

You should minimise both forms of coupling but having no coupling is not possible.


Thursday, 14 October 2010

Silent, unattended installation of SQL Server 2008

This is something that’s not nearly as hard as it sounds. Silent, unattended installs for any Microsoft product hang on the .ini file, the usual problem is creating these. In the SQL Server 2008 world there is a neat trick to generating your .ini file. If you run through the install wizard, on the “Ready to Install” dialog near the end you will be shown a “Configuration file path” value at the bottom of the dialog box. This is the path to the .ini file representing the configuration you just selected (which components, accounts etc.).

image

In the above summary, I’ve selected most of the features aside from SQL Server Integration Services, Report Server (I just want the Database Engine for BizTalk Server 2009). I’ve also selected a named instance and a custom installation directory for the instance (because I want to run side-by-side with SQL Server 2008 R2).

Note the “Configuration file path” value and quit the installer.

Take a copy of the .ini file from the path shown and put it in a simple path. You need to make the following changes:

  • Change the “QUIET” value from “False” to “True” (to suppress dialogs)
  • Change the “INDICATEPROGRESS” value from “False” to “True” (to show output in the console)

Run the installer using the following command line:

  • C:\>[Path to SQL Server media]\setup.exe /CONFIGURATIONFILE="[some path]\ConfigurationFile.ini"

The console should present you with something like the following:

One or more affected files have operations pending.
You should restart your computer to complete this process.

Things to be aware of:

  • The accounts you chose for the Administrator roles are stored in the .ini file, so choose Domain Accounts/Groups or well known accounts/groups (like BUILTIN\Administrators). If you choose machine specific accounts you will have problems installing to other servers.
  • The path to the SQL Server 2008 installation media is also stored in the .ini file so store it in a common location like a network share (and run the install wizard from this location when generating the .ini file).

You can use this strategy to ensure consistency of SQL Server installations across a team of developers or for quicker building of virtual machines.

Note this technique also works with MS SQL Server 2008 R2 but you must do two things differently:

  • Comment out the “UIMODE” entry in the .ini file (put a “;” at the start of the line).
  • Add the “/IAcceptSQLServerLicenseTerms” switch when calling setup.exe (no need for a value with the switch).

Wednesday, 13 October 2010

Installing BizTalk 2009 on Windows Server 2008 R2

Be aware you will likely hit some errors when running the configuration wizard. Typically something like:

Failed to connect to the SQL database 'SSODB' on SQL Server 'SQLServerName'
0x80131700 (Win32)

There is a known fix for this, details on Microsoft’s Knowledge Base here.

In short, you need to download Hotfix KB2252691 and run regasm.exe against “ssosql.dll”.

Remember to run the 64-bit version of regasm.exe on 64-bit systems.


Tuesday, 12 October 2010

Package management in .NET

Looks like Microsoft are solving the horrendous situation around package management in the .NET world. The solution is called NuPack.

NuPack solves the annoying situation that when working with open source libraries you have to hunt around for the various versions, find which ones are compatible and manually add then to your solution. Manually adding open source frameworks to your solution can involve all sorts of things such as putting binaries in a “library” folder, modifying configuration files and jumping through various other hoops. Mileage varies according to framework.

NuPack address most, if not all of these problems. Taking inspiration from Ruby Gems, it manifests itself through a Visual Studio Add-In. It automates the entire process of adding an open source framework to your solution. Binaries will be downloaded from a centralised feed, your configuration files will be updated and what ever else needs to be done will be done. There’s also the neat trick that should you wish to use FrameworkX and it depends on FrameworkY, then NuPack will automatically retrieve (and configure) FrameworkY when you request FrameworkX (it will resolve a whole dependency tree for you).

It has the added benefit that it does not install anything or put items in the GAC. You can add a dependency to your solution with NuPack and commit your solution to source control as normal. Should another developer then get the solution from source control everything will be there that they need, they don’t need to run NuPack themselves or even have NuPack installed. NuPack also has a PowerShell interface.

It can be found on CodePlex and the usual suspects have introductory posts here (ScottGu), here (Hanselman) and here (Haack).

NuPack is not the only candidate solution to this problem though, OpenWrap is an alternative.


Friday, 8 October 2010

Aiming for High Availability

I like this…

"My suspicion is the number-one cause of outages is human error and after that is badly tested apps, and everything else is way down. What we ought to be focus on in terms of high availability is probably not what we are focused on at all."

- Michael Stonebraker, http://www.theregister.co.uk/2010/09/13/michael_stonebraker_interview/


Thursday, 4 February 2010

Only because everyone else is...

The funniest Stack Overflow question ever...

http://stackoverflow.com/questions/2193953/flash-cs4-refuse-to-let-go

Thursday, 9 July 2009

Data driven tests with MSTest

You can use CSV or Excel documents as data sources to drive parameterised unit tests with MSTest. For the following class:

    3     public static class MyWidget

    4     {

    5         public static int MyBusinessLogic(int valueA, int valueB)

    6         {

    7             return valueA * valueB;

    8         }

    9     }

You can write the following unit tests:

    3     using System;

    4 

    5     using Microsoft.VisualStudio.TestTools.UnitTesting;

    6 

    7     [TestClass]

    8     public class MyWidgetTests

    9     {

   10         [TestMethod]

   11         [DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "MyWidgetTests.csv", "MyWidgetTests#csv", DataAccessMethod.Sequential)]

   12         public void TestMyBusinessLogicWithCsv()

   13         {

   14             int valueA = Convert.ToInt32(TestContext.DataRow["valueA"]);

   15             int valueB = Convert.ToInt32(TestContext.DataRow["valueB"]);

   16             int expectedResult = Convert.ToInt32(TestContext.DataRow["expectedResult"]);

   17             int actualResult = MyWidget.MyBusinessLogic(valueA, valueB);

   18             Assert.AreEqual(expectedResult, actualResult, "The result returned from the widget was not as expected.");

   19         }

   20 

   21         [TestMethod]

   22         [DataSource("System.Data.Odbc", "Dsn=Excel Files;dbq=|DataDirectory|\\MyWidgetTests.xlsx", "MyWidgetTests$", DataAccessMethod.Sequential)]

   23         public void TestMyBusinessLogicWithExcel()

   24         {

   25             int valueA = Convert.ToInt32(TestContext.DataRow["valueA"]);

   26             int valueB = Convert.ToInt32(TestContext.DataRow["valueB"]);

   27             int expectedResult = Convert.ToInt32(TestContext.DataRow["expectedResult"]);

   28             int actualResult = MyWidget.MyBusinessLogic(valueA, valueB);

   29             Assert.AreEqual(expectedResult, actualResult, "The result returned from the widget was not as expected.");

   30         }

   31 

   32         public TestContext TestContext{ get; set; }

   33     }

Notice the two unit tests are identical save for the test name and the “DataSource” attribute. The code is pretty self explanatory, the two tests are driven by data from different sources. The only things to note are the presence of the “TestContext” and the contents of the Data Source.

For CSV sources (the first in the example):

  • “Microsoft.VisualStudio.TestTools.DataSource.CSV” specifies the data source type.
  • “MyWidgetTests.csv” is the connection string and needs to be name of the file to read the values from.
  • The “MyWidgetTests#csv” value is the “table name”. When using files, it needs to match the filename, with a hash (“#”) instead of the period (“.”).

An example file is as follows:

image

For Excel sources (the second example):

  • “System.Data.Odbc” specifies the data source type.
  • “Dsn=Excel Files;dbq=|DataDirectory|\\MyWidgetTests.xlsx” is again the connection string, replace your filename accordingly. The “DataDirectory” value is replaced by the MSTest framework and points to the directory the tests are run from.
  • The “MyWidgetTests$” value is the “table name”. When using Excel files, it needs to to be the name of the of the Worksheet containing the data (see below).

An example file is as follows:

image

Note the you can have multiple Worksheets in a single Excel file, this means you can drive different tests from the same Excel file.

You will need to have the CSV and Excel files set as deployment items in the Test Run Config:

image


Wednesday, 13 May 2009

Tip for clearing disk space under Windows

After going through the usual suspects* for clearing disk space you can normally squeeze some more space by deleting the folder “%SystemDrive%\Windows\SoftwareDistribution” (you need to stop the “Automatic Updates” Service first).

* Usual suspects are:

  • Use “Disk Cleanup” (find under System Tools).
  • Delete any files you don’t need under “%SystemDrive%\Windows\System32\LogFiles”.
  • Delete any old user profiles (“Advanced” tab in Properties of My Computer), note the reported size of the profile used is usually an outright lie and the space taken up by each profile is normally much bigger.
  • If you are running SQL Server, truncate the Log files, move the Data and Log files to another drive.

Thursday, 30 April 2009

Load Testing with Visual Studio Team System

Visual Studio Team System offers a lot functionality for automated testing. While you can write unit tests with MSTest in “Visual Studio 2005/2008 Team Edition for Developers” you’ll need “Visual Studio 2005/2008 Team Edition for Testers” to author Web Tests and Load Tests.

Web Tests are essentially a script to execute against a web site, a Load Test can execute one or more Web Tests with a set of parameters. These parameters can be:

  • User count (this can ramp up and down)
  • Browser mix (IE 5.5/6.0/7.0/8.0, Firefox 2.0/3.0 and Netscape 6.0 plus Smart Phone and Pocket PC)
  • Network mix (LAN, Cable, dial-up)

Once you have authored your Web and Load Tests you can run the Load Tests from “Visual Studio 2005/2008 Team Edition for Testers”. In this scenario you are limited in that you can only simulate a limited number of users (exact number depends on your machine). To scale out and simulate the load of many thousands of users you can use the “Visual Studio Team System 2005/2008 Test Load Agent”. This is available as a separate product, download a 90 day trial here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=572e1e71-ae6b-4f92-960d-544cabe62162&displaylang=en

The “Visual Studio Team System 2005/2008 Test Load Agent” allows you to set up Test Agents and Test Controllers. Test Agents simulate requests from Users and Test Controllers orchestrate the Test Agents.

LoadTestingWithVSTS

According to the documentation, a Test Agent on a server with a 2.6 GHz processor and 2GB RAM can simulate approximately 1000 virtual users. A single Test Controller installed on a similar specification server can orchestrate approximately 30 Test Controllers. These numbers are approximate as the specifics will depend on your web application. If your web application is graphics heavy you will not be able to simulate as many users to due to increase memory demands of the requests for larger pages.

These are very rough numbers, but if your average web page size is 300KB and you have 1000 virtual users simulated per Test Agent, the server running the Test Agent needs to deal with up 300MB worth of requested data at once. The load on each Test Agent is mitigated in that the Test Agent simulates user thinking times (times are configurable in the scripts). So each machine won’t be making 1000 requests constantly, more like 1000 requests every 4 or 5 seconds. So a server with 2GB RAM supporting 1000 virtual users seems a reasonable basis for estimates.

If you want to simulate 10,000 users you would need:

1 Test Agent per 1000 virtual users = 10 x Test Agents = 10 x servers

1 Test Controller per 30 Test Agents = 1 x Test Controller = 1 x servers

This means a total of 11 servers, each with 2.6GHz processor and 2GB RAM.

You can find more information on the metrics here: http://msdn.microsoft.com/en-us/library/ms253092.aspx


About Me