Developing with C# 2008 Express Part 1
So not everyone can afford to shell out the money for the professional version of Visual Studio. That should not stop anyone from pursuing their passion or even satisfying their curiosity of developing in the dot net world.
Recently a friend requested that I coach him on learning C# and OOP for a program that he wants to write. He has been programming, but his experience is mostly with a procedural language of some sort, classic VB and VBA I believe. He does not have Visual Studio Professional so he decided to go with C# 2008 Express Edition. Just so that I could coach him appropriately, I figured that we both needed to develop in the same environment. That way we could both work on the same project. This is mostly because C# Express projects cannot be opened by professional editions of Visual Studio and vise versa. You normally have to port over your projects manually from one to the other. You do this enough times and it becomes somewhat of a pain. Therefore we decided to stick with one environment - C# Express 2008.
His request was not only to learn C#, but object-oriented programming (OOP) as well. So I thought I might as well get him started with a Test Driven Development (TDD) approach. Since TDD almost forces you to implement good OOP designs and principles I figured I could simply use NUnit. Well... NUnit does work with C# Express, but only as an add-on tool. You can't use any of the other cool tools that help you run NUnit like Resharper or TestDriven.net. C# Express does not allow add-ons period. For this reason the only way to run C# Express is to run it via the Tools menu with command line arguments. This poses a problem because you cannot step into your code.
Therefore running NUnit via the tools menu only gets you partially there since you cannot use the debugger capabilities of Visual Studio - remember no Add Ons. To further cripple your debugging attempts C# Express cannot attach the debugger to an external process. This means that you cannot run the NUnit Test Runner and simply attach to it.
A quick google search allowed me to find ExpressUnit. ExpressUnit is an open source project found on google code. You can find more information here on ExpressUnit. This open source project allowed me to walk the code in a debug session. There were a couple of problems with ExpressUnit. On one hand it was written using WPF and as cool as I like to think WPF is, the color them was butt ugly. You can modify the color theme since you have the full source code so this is probably a minor issue. On the other hand the tool used it's own unit test framework. This means that it not only ran the testable code but now you are using a framework other than NUnit to create your tests. Well I like to stick with things that universally accepted unless there is a compelling reason not to. NUnit has tons of suporting extensions like BDD frameworks and is compatible with more conintous integration tools than any other unit testing framework. For this reason I determined that ExpressUnit was not the most viable solution.
ExpressUnit did allowed me to run my tests and find some obscure bugs that I could simply not find by using NUnit via the Tools menu in C# Express. Because it was not most viable solution I decided to research the topic a little more.
This led me to find that you can also call the NUnit's console runner as well as the GUI runner from within your code. From this I deducted that you can also call NUnit's GUI runner. That way I could use the Unit Test framework of choice in the dot net world. I am still experimenting with it, but at least you know you have choices if you are planning to program in C# as a hobby. I will post the example soon, so stay tuned for more.
Here is how you have to call NUnits Gui Runner. You also have to add the debug parameters from the link above.
Recently a friend requested that I coach him on learning C# and OOP for a program that he wants to write. He has been programming, but his experience is mostly with a procedural language of some sort, classic VB and VBA I believe. He does not have Visual Studio Professional so he decided to go with C# 2008 Express Edition. Just so that I could coach him appropriately, I figured that we both needed to develop in the same environment. That way we could both work on the same project. This is mostly because C# Express projects cannot be opened by professional editions of Visual Studio and vise versa. You normally have to port over your projects manually from one to the other. You do this enough times and it becomes somewhat of a pain. Therefore we decided to stick with one environment - C# Express 2008.
His request was not only to learn C#, but object-oriented programming (OOP) as well. So I thought I might as well get him started with a Test Driven Development (TDD) approach. Since TDD almost forces you to implement good OOP designs and principles I figured I could simply use NUnit. Well... NUnit does work with C# Express, but only as an add-on tool. You can't use any of the other cool tools that help you run NUnit like Resharper or TestDriven.net. C# Express does not allow add-ons period. For this reason the only way to run C# Express is to run it via the Tools menu with command line arguments. This poses a problem because you cannot step into your code.
Therefore running NUnit via the tools menu only gets you partially there since you cannot use the debugger capabilities of Visual Studio - remember no Add Ons. To further cripple your debugging attempts C# Express cannot attach the debugger to an external process. This means that you cannot run the NUnit Test Runner and simply attach to it.
A quick google search allowed me to find ExpressUnit. ExpressUnit is an open source project found on google code. You can find more information here on ExpressUnit. This open source project allowed me to walk the code in a debug session. There were a couple of problems with ExpressUnit. On one hand it was written using WPF and as cool as I like to think WPF is, the color them was butt ugly. You can modify the color theme since you have the full source code so this is probably a minor issue. On the other hand the tool used it's own unit test framework. This means that it not only ran the testable code but now you are using a framework other than NUnit to create your tests. Well I like to stick with things that universally accepted unless there is a compelling reason not to. NUnit has tons of suporting extensions like BDD frameworks and is compatible with more conintous integration tools than any other unit testing framework. For this reason I determined that ExpressUnit was not the most viable solution.
ExpressUnit did allowed me to run my tests and find some obscure bugs that I could simply not find by using NUnit via the Tools menu in C# Express. Because it was not most viable solution I decided to research the topic a little more.
This led me to find that you can also call the NUnit's console runner as well as the GUI runner from within your code. From this I deducted that you can also call NUnit's GUI runner. That way I could use the Unit Test framework of choice in the dot net world. I am still experimenting with it, but at least you know you have choices if you are planning to program in C# as a hobby. I will post the example soon, so stay tuned for more.
Here is how you have to call NUnits Gui Runner. You also have to add the debug parameters from the link above.
class Program
{
[STAThread]
static void Main(string[] args)
{
//NUnit.Gui.Runner.Main(args);
NUnit.Gui.AppEntry.Main(args);
}
}
Comments