August 2003 - Posts

Visual Studio Favorites

I didn't know you could do this...

Just right click on the command bar. Make sure 'Web' is checked and click on the favorites icon. You can then drag shortcuts of your projects into the favorites tool window.

Posted by Jamie Cansdale | with no comments
Filed under:

Microsoft blogs

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!

Posted by Jamie Cansdale | with no comments

TestFixture SetUp and TearDown

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;
  }
 }
}
Posted by Jamie Cansdale | 3 comment(s)
Filed under:

Re: Enforcing a Build and Test Policy

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!

There are a couple of unsatisfactory features of the technique you've proposed here. First, it leaves cruft in the registry - it will register your TestBeforeRegistering class as a COM class under the ProgID SampleTests. (And it will make up a CLSID. I think if you ever change your TestBeforeRegistering class it may make up a different CLSID, causing an ever-increasing amount of registry cruft to accumulate.) [Ian Griffiths]

I don’t think it will leave cruft in the registry because before the next registration it will be unregistered. Certainly if you abandoned the project it would leave cruft behind. But I don’t think one more orphaned CLSID would be too much of an issue.

Second, the way that errors are handled is distinctly unsatisfactory. [Ian Griffiths]

Unfortunately there isn’t an easy way to output a more appropriate build failure message. There is a way, but I won’t go into that now. ;o) For the moment I just run Chris Szurgot's Trace Monitor in the background and pick up the exception that way. BTW if you’re not using Trace Monitor, you should be!

I've been tring to find usage descriptions for the NUnit.Core routine. TestSuiteBuilder, TestSuite, etc. Where did (do) you find them? [K. Carter]

Intellisense and Reflector I’m afraid.. ;o)

Posted by Jamie Cansdale | with no comments
Filed under:

Reflector 3.3.1.0 + Managed Add-Ins

I'm afraid the download location and public key of Reflector has changed in this latest version, meaning the automatic download and update feature of Reflector Add-In won’t work. I'll write a note here as soon as there’s an updated version available.

In the mean time you can still host Reflector inside Visual Studio, just without the usual bells and whistles. All you need to do is drag Reflector.exe and drop it in the ‘Add-In Toolbox’. Because Reflector now uses single split screen window, it probably makes sense to use is as a non-dockable page (the same as the Object Browser). To do this just right click on the Reflector window and uncheck ‘Dockable’. You might have to resize it to make the right hand window visible.

There are some applications that cause Visual Studio to stall on exit if they’re running as an add-in (Reflector and many other applications work just fine). I’m working on a solution to this issue at the moment. As a workaround you can exit the application before closing Visual Studio. Whatever you do don’t experiment with new applications if you’ve got unsaved work (remember they are running in-process!).  Let me know how you get on and I’ll add some more recommendations to the gallery.

Posted by Jamie Cansdale | with no comments
Filed under:

Enforcing a Build and Test Policy

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’.

Here is an example that uses the NUnit test runner (although any test runner would do). As well as stopping the build when any tests fail, test results will be written to an XML file. Tests will only be enforced on a ‘Debug’ build. The whole thing could have been done in a few lines, but I decided to add exception handling and a few comments. ;o)

using System;
using System.IO;
using System.Runtime.InteropServices;

// By default make types invisible to COM
[assembly: ComVisible(false)]

#region Run tests after every DEBUG build
#if DEBUG
namespace Tests
{
 using NUnit.Core;
 using NUnit.Framework;
 using System.Diagnostics;

 // The test runner must be COM visible
 [ComVisible(true), ProgId("SampleTests")]
 public class TestBeforeRegistering
 {
  // NOTE: "Register for COM interop" must be enabled
  [ComRegisterFunction]
  public static void abortBuildOnTestFailure(Type t)
  {
   try
   {
    string path = new Uri(t.Assembly.CodeBase).LocalPath;
    TestSuiteBuilder builder = new TestSuiteBuilder();
    TestSuite suite = builder.Build(path);
    TestResult result = suite.Run(new NullListener());
    writeXml(path + "_tests.xml", result);
    if(result.IsFailure) { throw new Exception("Test Failure!"); }
   }
   catch(Exception e)
   {
    Debug.WriteLine(e);
    throw;
   }
  }

  // Write test results to an XML file
  private static void writeXml(string path, TestResult result)
  {
   XmlResultVisitor visitor = new XmlResultVisitor(path, result);
   visitor.visit((TestSuiteResult)result);
   visitor.Write();
  }
 }

 // An example failing test
 [TestFixture]
 public class SampleTests
 {
  [Test]
  public void FailTest()
  {
   Assertion.Fail();
  }
 }
}
#endif
#endregion

I have used the AylarSolutions.Highlight online demo for the code highlighting. If anything is broken blame Thomas. ;)

To start testing after every build all you need to do is enable 'Register for COM interop'.  This has the 'interesting' side effect of registering the test runner class as a COM object with a ProgID of 'SampleTests'.  It would be very strait forward for unit testing frameworks to support the running of named test suites!  Unfortunately there is no tidy error message when the build/test fails. All you get is " COM Interop registration failed. Exception has been thrown by the target of an invocation". Feel free to post any refinements of the idea/code you come up with.

Posted by Jamie Cansdale | 3 comment(s)
Filed under:

Being Promiscuous and Stopping Infection

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.

You will need to install WinPcap for Ethereal to work on Windows platforms...

Ethereal: Sniffing the glue that holds the Internet together
WinPcap: the Free Packet Capture Architecture for Windows

Posted by Jamie Cansdale | with no comments
Filed under:

Language Equivalents

Darren Neimke found this useful collection on MSDN...

These topics summarize common programming concepts with side-by-side code examples or tables. This information is designed for those who want to learn a new language or refresh their memory of how to work with a particular language.

The following programming languages are covered:

  • Visual Basic
  • C#
  • Visual J#
  • C, C++, and the Managed Extensions for C++
  • JScript
  • Visual FoxPro

In This Section

Programming Concepts Compared in Different Languages with Code Examples
Provides example code for basic tasks (such as declaring variables and passing parameters) that cannot be summarized with a keyword.
Keywords Compared in Different Languages
Provides a table of equivalent keywords, with links to reference topics.
Data Types Compared in Different Languages
Provides a table of data types for each of the languages, with links to reference topics.
Operators Compared in Different Languages
Provides a table of operators for each of the languages, with links to reference topics.
Controls and Programmable Objects Compared in Different Languages
Provides a table of controls and classes, with links to reference topics, for the following languages, technologies, and libraries:
  • Visual Basic 6.0
  • Windows Forms controls
  • ASP.NET server controls
  • HTML server controls
  • MFC (Microsoft Foundation Classes)
  • ATL (Active Template Library)
  • Visual FoxPro

[from ICompare langugages / ShowUsYour<Blog>]

Posted by Jamie Cansdale | with no comments
More Posts