Archives

Archives / 2003 / August

  • Microsoft blogs

    No Comments

    I've just stumbled on the GotDotNet blog list.  You'll find a whole screen full of interesting looking blogs there.  I must have been too engrosed in Chris Brumme's epic posts to ever think about clicking in the top right hand corner.  The very first blog is dedicated to the pretty much undocumented Fusion assembly loader.  It looks like I've got some catching up to do!

    Read more...

  • TestFixture SetUp and TearDown

    3 Comments

    I have finally got round to trying NUnit 2.1 with NUnit Add-In. I am relieved to report that it works out of the box with the current version of NUnit Add-In (the one you’re probably using). All you have to do is start using the ‘NUnit.Framework’ assembly from the 2.1 release. If you’re interested to see the code that binds to pretty much any version of NUnit, you can find it here. There’s obviously some reflection in there, but the more interesting bit is the RealProxy. I had to use that to deal with the evolving test listener interface. The reason I started using 2.1 was for the TestFixtureSetUp/TearDown attributes. I didn’t particularly want to be firing up new instance of Visual Studio for every little add-in unit test. With the new attributes I can do the set-up and the start of the test run and tear-down at the end. This goes for whether I’m running an individual test or all tests in an assembly. Here is an example of how to use the new attributes, plus some other stuff for fun.. ;o) 

    namespace Tests
{
 using System;
 using System.IO;
 using System.Diagnostics;
 using System.Runtime.InteropServices;
 using NUnit.Framework;
 using EnvDTE;

 [TestFixture]
 public class TestVisualStudio
 {
  [TestFixtureSetUp]
  public void TestFixtureSetUp()
  {
   _dte = new DTEClass();
   _dte.MainWindow.Top = 50;
   _dte.MainWindow.Left = 50;
   _dte.MainWindow.Height = 200;
   _dte.MainWindow.Width = 1024;
  }
  private DTE _dte;

  [TestFixtureTearDown]
  public void TestFixtureTearDown()
  {
   _dte.Quit();
   Marshal.ReleaseComObject(_dte);
  }

  [Test]
  public void TestNUnitAddInEscapes()
  {
   Debug.WriteLine(_dte, "_com");
   Debug.WriteLine("=====================");
   Debug.WriteLine(_dte, "_verbose");
  }

  [Test]
  public void TestShowMeTheCode()
  {
   _dte.MainWindow.Visible = true;
   System.Diagnostics.StackFrame frame = new System.Diagnostics.StackFrame(0, true);
   string fileName = frame.GetFileName();
   int lineNumber = frame.GetFileLineNumber() - 1;  // make it zero based
   string[] lines = new StreamReader(fileName).ReadToEnd().Split(new char[] {'\n'});
   string code = lines[lineNumber];
   Debug.WriteLine(code);
   _dte.StatusBar.Text = code;
   System.Threading.Thread.Sleep(5000);
   _dte.MainWindow.Visible = false;
  }
 }
}

    Read more...

  • Re: Enforcing a Build and Test Policy

    No Comments

    In a previous entry I posted some code that would run unit tests after every successful build. I used ‘Register for COM Interop’ and a ‘ComRegisterFunction’ attribute. Ian Griffiths asks, “What does this add that you don't get with VS.NET 2003's build events?” You can think of this as running lower level build events. Instead of executing a batch file and passing it an assembly location, you’re executing a method and passing it a Type object. It also means you can create logic that will run as part of installation. If these unit tests don’t pass, then fail early and don’t even install!

    Read more...

  • Enforcing a Build and Test Policy

    2 Comments

    I have just realised that VS.NET has everything in place to support a build and test policy without the use of any external add-ins! You can define and enforce your unit tests in code on a per project basis. This technique uses the little known ‘ComRegisterFunction’ attribute and ‘Register for COM interop’. If this method returns an exception then the build fails. A new app domain is created per build with a base directory of ‘bin\Debug’.

    Read more...

  • Being Promiscuous and Stopping Infection

    3 Comments

    I’ve just detected an infection of MSBlast quite by accident. It was on a machine that I thought had all the latest patches so I hadn’t bothered to check it. On a different machine I was using the free packet sniffer Ethereal snoop on an outgoing HTTP connection. Ethereal defaults to running in promiscuous mode so you can see all traffic on your local subnet. It was obvious there was a problem from the very first page of data (you can’t miss something scanning ranges of IP addresses!). Even if you're not worried about MSBlast it's interesting to see everything that is happening on your network.

    Read more...