November 2005 - Posts
Now that I have my first CAB application I want to figure out how to write a “Module” within CAB.
“Modules are distinct deployment units of a CAB Application. You can separate areas of your application into different modules to be able to deploy them to different users or applications.”
Step one is to create a separate project for a module, which I’ll call MySampleModule. Next we’ll want to add a class to initialize our module which we’ll name MySampleModuleInit. Our MySampleModuleInit class will inherit from the ModuleInit base class provided by CAB. To keep it simple we’ll show a message box with a fancy “Hello World” message. When you create a new Module you likely have some initialization logic that you want to run which is what the whole ModuleInit class is all about. You might also want to initialize some of the services used by your module within the initialization stage.
public class MySampleModuleInit : ModuleInit {
public override void Load() {
base.Load();
MessageBox.Show("Hello World");
}
}
After we’ve created out MySampleModuleInit class we want to make it so our primary shell application knows about our new module. To do this we define the module within a ProfileCatalog.xml file within our shell application. In addition to adding the module definition to the ProfileCatalog.xml files we also need to add a reference to our module project so that when the shell loads it can find your module.
<?xml version="1.0" encoding="utf-8" ?>
<SolutionProfile xmlns="http://schemas.microsoft.com/pag/cab-profile" >
<Modules>
<ModuleInfo AssemblyFile="MySampleModule.dll" />
</Modules>
</SolutionProfile>
Once the main application and module are compiled the application can be run. When the shell application starts it will pick up on the ProfileCatalog.xml file and use the information within the file to determine what modules it needs to load. Each module will be loaded and will have it’s initialization logic executed. While a module that displays a “Hello World” message is amazingly useful I think the next step is to move onto creating a Module that has a real UI. In addition we should start exploring what WorkItems, Controllers, and SmartParts are all about.
Over the last several months I’ve been keeping an eye on the progress of the Composite UI Application Block. Earlier this month Peter, Brad, and the rest of the PAG group released the November release of CAB.
Tonight I started looking over some of the sample applications and walkthroughs provided as part of the CAB release. To start learning about CAB I’ve decided to start writing a simple application using it. The first step in the learning process is to get up to speed on how creating the most basic application is different in CAB then in a “normal” WinForms application.
When we create a normal WinForms application we get a program.cs file that runs our main form. To get a simple form to show up in a CAB application we need to create three items. Just like in a typical WinForms app we need a default form, but unlike a normal WinForms app we also need a default work item, as well as a “shell” for our application.
public partial class ShellForm : Form {
public ShellForm() {
InitializeComponent();
}
}
public class ShellWorkItem : WorkItem {}
public c
lass ShellApplication : FormShellApplication<ShellWorkItem, ShellForm> {
[STAThread]
static void Main() {
new ShellApplication().Run();
}
}
Most of the wiring up of this sample CAB application happens in the definition of the ShellApplication. As you can see I’m inheriting from the FormShellApplication base class and providing it the type of the default work item (ShellWorkItem) as well as the form to use as the “Shell” for the application. Running the CAB application once the Form, WorkItem, and Shell are defined results in a beautiful blank form just like we get out of the box when we create a blank WinForms application.
Uncle Bob has a nice little rant on why he’s not very fond of
Microsoft’s re-definition of TDD. It’s interesting that they’ve made “red, green, refactor” into a 15 step process. What’s even more interesting is that they’re calling that 15 step process TDD.
Jay Fields has a series of posts going which he’s using to document how he’s been doing smart client development. He seems like the type of guy who might agree with me that the WinForms Designer is Evil.
Definitely well done. It’s refreshing to see a company throw out the short term financial impacts of a decision and instead focus on what the right thing is to do for the customer. Very well done.
Today as I was reviewing Enterprise Library for .NET 2.0 I noticed a nice little trick they were using to write their unit tests for both NUnit and VS UT (what’s the official name?):
#if
!NUNIT
using Microsoft.VisualStudio.TestTools.UnitTesting;
#else
using NUnit.Framework;
using TestClass = NUnit.Framework.
TestFixtureAttribute;
using TestInitialize = NUnit.Framework.
SetUpAttribute;
using TestCleanup = NUnit.Framework.
TearDownAttribute;
using TestMethod = NUnit.Framework.
TestAttribute;
#endif
Cool! 
Anyone who uses Visual Studio knows that sometimes it doesn’t listen. You tell it to create a project in a location and it puts it somewhere else. The same goes for creating solutions, often times you want to create a solution at a given location without it being placed into a sub-folder with the same name.
Peter Provost came up with a nice hack that adds a New -> “Visual Studio Solution” option to the right click context menu within Windows.
One of the main reasons I took my new gig was that it seemed like
the type of job that would involve thinking. There is a business to
learn, new technologies to pick up, and lots of existing skills to be
further developed.
At my old job I had some of that but I often times felt like I could
have gone to work and put in a full day without really having to think.
I've written enough C# and ASP.NET that a lot of what I had to do just
happened. It didn't need to be thought about.
One of the concerns I have with my career is that I'll let myself get
into a spot where I don't have to think or learn. I don't want to
wonder if I could pass 8th grade math, so to speak. So while I
don't usually post things like the below I had this little story to go
along with it so I thought I'd let myself slide.
|
You Passed 8th Grade Math
|
Congratulations, you got 10/10 correct!
|
Over the past several months I’ve been getting up to speed on WinForms. For the previous 5+ years I’ve been doing web based software development. During those wonderful years I created many little utilities using WinForms (or VB6!?!?). Even the most complicated of my WinForms experiments was peanuts in comparison to what any “real” WinForms developer has developed.
During my time in the web world I learned one very important lessen: NEVER use the Web Forms designer! Not only does it create horrendous HTML, but it also deletes code, removes event handlers, and causes overall havoc on your project. Luckily VS 2005 fixes most, if not all, of those problems.
Now that I’ve gotten off topic a bit lets get back to the question at hand….is the WinForms designer evil?
The WinForms designer makes developing complex forms feel quick and painless. The drag-and-drop’ability allows you to throw together new forms in no time flat. It allows you to hook up event handlers and plug in the code that should be executed when those events fire using a couple mouse clicks. What this all leads to is a great environment for building prototype applications. What it doesn’t lead to is well architected WinForm applications. Just using the WinForms designer doesn’t do anything to help with the testability of your application. If your application can’t be tested it’s not well architected.
The hardest thing to unit test in an automated way is a Gui. Do yourself a favor and DON’T use the WinForms designer. Think of ways you can make your application testable. Evaluate what you should do in the designer and what you shouldn’t. If the things that you deem as “should do in the designer” outweigh the things that you deem “should not be done in the designer” then start your list over. Repeat until very few things are in your do in the designer list. While I don’t think the WinForms design is outright evil I do think it should only be used in moderation. Use MVP, don’t use that designer.
I’ve been hand crafting a lot of Mock objects recently to help ensure the tests that I’m writing are only testing a single object. Mock objects along with constructor dependency injection make it possible to test one and only one class which is a very important attribute of good unit tests.
To help reduce the number of hand crafted mocks I need to create I’ve been looking at some mock frameworks to help. Over the last week I’ve looked at Rhino Mocks and NMock but wasn’t able to get some simple examples working. This was mostly due to not having sufficient time to look into the API’s and read the supporting documentation. This afternoon I did a quick search for “.net mock framework” and came upon the NUnit release notes which reminded me that a simple Mock framework was included with NUnit 2.2. I added a reference to NUnit.Mocks and started experimenting. Within a couple minutes I had the basics I needed to start using the mock framework within NUnit. Although it isn’t meant to be a full fledged mock framework it provides the basic features necessary for most mocks.
using System;
using NUnit.Framework;
using NUnit.Mocks;
namespace NUnitMocks.Samples {
[TestFixture]
public class MockTests {
public interface IMyInterface {
string SayHello();
}
DynamicMock mock;
IMyInterface m;
[SetUp]
public void Setup() {
mock = new DynamicMock(typeof(IMyInterface));
m = (IMyInterface)mock.MockInstance;
}
[Test]
public void CanSetReturnValue() {
mock.SetReturnValue("SayHello", "Steve");
Assert.AreEqual("Steve", m.SayHello());
}
[Test]
public void CanSayWeExpectOrDoNotExpectSomethingToBeCalled() {
mock.ExpectNoCall("SayHello");
mock.Verify();
mock.Expect("SayHello");
m.SayHello();
mock.Verify();
}
[Test]
[ExpectedException(typeof(Exception))]
public void CanGetExceptionThrown() {
mock.ExpectAndThrow("SayHello", new Exception("We got issues"));
m.SayHello();
}
}
}
One of the things that I’m looking forward to digging into within Indigo is their support for Federated Security. This evening I came across an article on one of the key enabling technologies for providing federeated security, namely SAML. (more from Oasis)
Hopefully as we get closer to a release of Indigo (WCF) we’ll start seeing more articles and books that help provide guidance for building “real” service oriented (SO) applications using WCF. Perhaps Sam Gentile will have some goodies for us in his Service Oriented Indigo book?
Micah Martin and
David Chelimsky of ObjectMentor fame are having a Mock
Off.
Micah likes hand crafted mocks and
David likes using mock
frameworks.
Their Mock Off involves each of them using the others
technique for 3 full days. During their mock off Micah will be
forced to use a mock framework and David will be forced to write hand
crafted mocks.
I'm interested in the result of their mock off. I've been using
hand crafted mocks but have been investigating several mock frameworks
(NMock, NUnit.Mocks, & Rhino Mocks). I think both mock
frameworks and hand crafted mocks have their advantages. Hand
crafted mocks provide you with the ultimate flexibility, while mock
frameworks make it quick and easy to create mocks for testing
objects.
I suppose a more appropriate title for my post would have been "to Mock
framework or not, that is the question", since I think any well
designed application will need mock objects for testing in some
fashion.
Do you use a mock framework? If so, why? If not, why not?
Rob Howard has an interesting post entitled Is “Smart Client” a “Dumb Idea?” where he talks about why he thinks smart clients are in fact a dumb idea in most scenarios.
Do you agree?