Andrew L. Van Slaars

I am taking a semi-TDD approach to my most recent project. As I started writing my initial tests, it occurred to me that all of the ServiceLayer/Manager classes in my business layer inherit from a standard base class and that at least a few of the tests will be identical (except of course for the datatypes used). Each test class will also have essentially the same setup and breakdown.

So of course, I immediately fire up a new class and create a generic base class. I added a type parameter for the entity type that will be transported/manipulated through my Bll, one for the class being tested and another for the data access interface that I would be mocking through Rhino Mocks.

I added the internal and private members that would be used for setup and the test initialization method, commented it all out in my actual test class and added my inheritance. So far, so good. My tests ran, but they were still implemented in the original test class, so I commented them out, copied them into my base class and updated them to use my generic type arguments.

At this point, the “CreateInstance()” method that I was using to get a new instance of my target object caused a compiler error due to the fact that it called a constructor on my genric type argument that accepted a parameter. In order to pass in the mock for my data access interface, the parameter had to be there, but there is no way to specify constructor arguments in the constraints for generic type references.

I decided that making the “CreateInstance()” method abstract would give me access to it and then I would just have to add an implementation into my actual test classes… not a bad trade for the ability to “share” a group of core unit tests. So I marked the class as abstract, removed the method implementation, added the override into my actual test class and compiled.

At this point, my test project compiled with no problem, but my tests didn’t show up in test view. I compiled again, closed and re-opened my test class, closed and re-opened Visual Studio… still no tests in the test view window.

A quick Google search turned up this. I haven’t spent much time researching it at this point, but it seems that Visual Studio doesn’t recognize (or won’t run) Unit Tests that are defined in an abstract class. This problem is pretty specific to the unit testing framework that ships with Visual Studio. Sounds to me like this sort of thing would be possible if I were using NUnit (or some other xUnit framework) to do my unit testing.

The base class still seems to handle my setup and breakdown pretty well and I can use it for support methods that I share between tests so it isn’t a total loss, it just would have been nice to be able to inherit some tests as well.

If I find any new information, I will be sure to post it. If you know something I don’t (I’m sure you do but I mean something related…) feel free to share in the comments.

.NET, TDD, Tools, Unit Testing, Visual Studio TDD, Unit Testing, Visual Studio

This was originally posted at vanslaars.com in December of 2006. I have not tried this with Visual Studio 2008 (and probably won’t have a reason to anytime soon) but I am pretty confident that it would work with 2008 as well told that it does NOT work.

I don’t do much work with classic ASP pages, but part of my role in my current position involves maintaining legacy ASP websites until they are all converted to ASP.NET 2.0. The thing that really gets to me when working with classic ASP are the generic server errors that tell you practically nothing about what went wrong… this, coupled with the fact that none of the members of the current team were here when these applications were written, makes it very difficult to track down and fix bugs.

Well, there is a solution, yet it seems to be a difficult one to find instructions on. Since the first time I worked my way through this, some additional information has been publshed on various blogs… this is my attempt to help fill the gap for those searching desperately for the steps involved in debugging ASP pages through Visual Studio 2005.

The first thing you need to keep in mind is that this requires IIS (5 or 6) and WILL NOT work through VS 2005’s built-in Cassini web server.

Secondly, before you start working through the steps, you need to run your page without debugging (just browsing to it on localhost will do too) BEFORE trying to debug… this requires you to attach the debugger to a process, therefore, the process needs to be started before you attempt to debug (this one got me a couple of time when I first attempted it).

So, here are the steps:

1. Make sure your site is set to run through IIS (not Cassini)
2. Make sure you enable ASP debugging on your server
3. Open your target ASP file in Visual Studio 2005
4. Set a breakpoint somewhere in your ASP page
5. Run your page without debugging from Visual Studio (or browse to the page through localhost)
6. In the Visual Studio menu, go to Debug -> Attach to Process
7. Choose the process:
   In IIS 6 (Server 2003) choose w3wp.exe
   In IIS 5.1 (XP Pro) you want to choose dllhost.exe - Unfortunately, it isn’t this simple though… you will need to attach to the process based on the process id to ensure that you have the correct process. In order to do this: follow these steps:
   1. Download the ListDLLs utility from sysinternals.
   2. Assuming you have the ListDLLs executable available on your machine, in a command prompt, go to the directory which contains ListDLLs and run the following command:
      listdlls.exe -d asp.dll
   3. This will return the process id for the instance of dllhost that loaded asp
   4. Use this ID to select the process in the Attach to Process dialog
8. You may need to refresh your ASP page in the browser to hit your breakpoint.

I hope this helps out the next person having difficulty finding these steps.

Happy Debugging.

Tools, Visual Studio asp, debugging, Tools, visual studio 2005, visual studio 2008

This was originally posted at vanslaars.com in January of 2007. I haven’t encountered this error message with Visual Studio 2008 yet, but the instructions to update the options DO apply for Visual Studio 2008 as well.

When using a Web Deployment project in Visual Studio 2005, you may encounter an error similar to this: ?aspnet_merge.exe exited with code 1?. This reminds me of the classic ASP “Internal Server Error” message, which basically says ” Something is broken, figure it out and fix it!”.

Well, I have good news, you can get more detail with your error messages by setting a simple option in Visual Studio 2005.

To do this, simply browse to Tools -> Options -> Projects and Solutions -> Build and Run, and in the options to the right of the dialog, switch the “MSBuild project build output verbosity” drop-down value to “Diagnostic“. Now you will see detailed output during the build process, including detailed errors when something goes wrong.

.NET, Tools, Visual Studio visual studio 2005, visual studio 2008