A few people have asked me what "hard core" WF questions to ask a job candidate.

For advanced topics, I like open-ended questions. Not all these questions have a right or wrong answer- but they should give you an idea of the candidates WF experience, and how they'd design and implement software with WF.

1. Are there advantages to building workflows using only XAML? Are there disadvantages?
2. What are the pros and cons of using an ExternalDataExchange service versus going directly to the WorkflowQueuingService?
3. When are attached dependency properties useful in WF programming?
4. What behavior does the default scheduling service provide?
5. How can my code participate in a database transaction with a workflow instance?
6. Why would I use a tracking service?
7. Describe a scenario where the WF runtime will cancel an executing activity.
8. Describe a scenario where I'd need to spawn an ActivityExecutionContext.
9. Tell me why I'd use a compensation handler.
10. Tell me about the following activities: Replicator, Parallel, and Policy.

A candidate who can run the table on these 10 questions knows their WF stuff.

My desktop computer continued to deteriorate this weekend. Not only could I not maintain an RDP connection into the desktop, I also started having problems synching my phone, copying files across the network, and general performance problems.

On a hunch, I disabled Windows Firewall and all these problems disappeared. Since I am behind a hardware firewall, I'm not concerned about the security implications.

Not sure why this happened – but the firewall rules on this machine numbered over 400 in the private profile (Start -> Search for firewall advanced). Other machines I've checked have ~200 rules.

Perhaps the software firewall was overloaded...

The New ASP.NET Framework

ScottGu gave a demo of the new MVC framework for ASP.NET at the ALT.NET Conference. Here are some notes and thoughts I had after watching ScottHanselman's recording.

The framework should go live in the spring of 2008. The framework is not a replacement for ASP.NET WebForms, but provides an alternative paradigm for building web applications. The new framework still works inside of the ASP.NET runtime - meaning all of the wonderful infrastructure pieces like the configuration system, provider model, SQL cache invalidation, health monitoring, and master pages continue to exist. Like the ASP.NET AJAX extensions – it sounds like we'll only need a new assembly to start the party.

Being an "MVC framework", the software features the Model View Controller pattern. MVC and its many permutations have been (and continue to be) principal patterns in many application frameworks and development environments. There were several mentions of Rails (both the Mono and Ruby types), and at least one reference to Django (the Django book is a good read to get into the framework's mindset).

The framework will provide:

1. Mechanisms to enforce a clean separation of concerns
2. An API designed for testability
3. A pluggable and extensible technology stack

Separation of Concerns

ASP.NET WebForms map an incoming URL to a single .aspx file. Although one can use an HttpModule or VirtualPathProvider to change this behavior, the majority of ASP.NET web applications use this default behavior. In practice, this approach tends to produce code-behind files with intermingled presentation, data access, and business logic. This approach also tightly couples URLs to the physical arrangement of .aspx files in the file system.

The new MVC framework offers a loose coupling between incoming URLs and the view that will ultimately render HTML. ScottGu describes a flexible and pluggable URL dispatching engine that can handle clean and procedural URLs like:

https://odetocode.com/articles/show/450

or

http://www.pluralsight.com/classes/register/appliedsilverlight

The URL dispatching engine examines incoming URLs, routes each request to an instance of a controller class, and invokes a method on the controller (the action).

Controllers

Controllers in the new framework support test first and controller first development styles. In other words, you can implement a controller sans any views, and fully test the controller's ability to utilize application logic and services to respond to a request.

The framework provides a low-level interface definition you can implement to claim absolute power over controller policy, but also provides a hierarchy of concrete controller classes to build upon.

When the controller is ready, it can call RenderView(string viewName, object viewData) to generate the appropriate user interface response. Thanks to generics, this boundary can also be strongly typed.

Views

Views render HTML, but views are not web forms - there is no page lifecycle, postbacks, or viewstate in this framework.

In general, views are simple templates. Templates are concerned only with presentation. To enforce a separation of concerns, many template engines do not allow a template to change the value of a variable or call into application logic, but the ASP.NET framework will allow code blocks and data-binding. The view never references a controller, and the controller never references a view - so testability and a separation of concerns prevail.

Designed For Testability

One of the current difficulties in writing unit tests for code running inside an ASP.NET environment is the pervasiveness of sealed classes like HttpContext.The MVC framework features an interface based API with IHttpContext, IResponse, IRequest, etc.

There is a mock view engine and, I believe, mock implementations of IHttpContext and the like to make testing easier.

At the beginning of the discussion Scott mentioned that the framework will include inversion of control containers, although I don't recall this feature appearing in the presentation.

A Pluggable Architecture

It sounds as if every major service in the MVC framework is pluggable – the view engine (throw in Brail), the dependency injection framework (throw in Structure Map), the URL dispatcher, the controllers, and more.

Look For the CTP Soon

The new framework appears to marry mature paradigms from outside the world of ASP.NET with the high performance and robust infrastructure of the ASP.NET runtime. Look for a CTP by the end of the year.

Before I start my tale of woe, I just want to point out that I've tried disabling the autotuning feature on Vista machines, but this doesn't fix the problem.

I have a relatively clean desktop machine. The desktop is a host for several virtual PCs, and runs Vista.

Remote desktop connections to the virtual PCs hosted on this desktop are solid, and the connections never drop. The virtual PCs run XP and 2003 Server.

But ... remote desktop connections to the desktop itself stall every 5 minutes. Sometimes the RDP connection drops entirely - other times it's just a matter of waiting 10-20 seconds for the connection to reconnect.

Each time this happens I lose a little more hair.

Even stranger - while a connection to the desktop is stalled, a connection to a virtual PC hosted on the desktop is still working great. I can even ping the host machine and see a 2ms response time.

This behavior leads me to believe that:

1. There is nothing wrong with the RDP client
2. There is nothing wrong in the networking stack or hardware of the desktop.
3. There is something wrong with the terminal services service on Vista.

I'm hoping SP1 will fix the issue, and do so before I go bald.

Anyone else see similar behavior?

WWWTC #18 highlights the fact that integer overflow detection is ON by default for Visual Basic projects. To change the behavior, you need to go to into the project properties -> Compile -> Advanced Compile Options and click the "Remove Integer Overflow Checks".

In C# projects, overflow detection is OFF by default. To change the behavior, you need to go into the project properties -> Build -> Advanced and select the "Check for arithmetic overflow/underflow" check box.

Changing the C# project settings is one solution to making the unit test in WWWTC #18 pass.

There is another option, too. Use the checked keyword in C#, as Johnathan, Jason, Ronin, and Dave pointed out.

Or …

There are a number of other subtleties to overflow detection – try some experiments with floating point and decimal data types to see what I mean, or jump to this article on the The Code Project: Arithmetic Overflow Checking using checked / unchecked.

Ayende kicked the month off with "Schema to wince by…", then "CRM Horror".

Great timing, Ayende! With Halloween right around the corner, let's make October scary schema month!

Here is one that recently made my hair stand on end:

This healthcare schema defines a composite primary key using 5 varchar fields and 2 datetime fields. If you think the index is scary, you should see the joins…

Do you have a scary schema to share?

Here is another golden oldie:

Numeric overflows are a type of software bug that occur when a calculation produces a result that doesn't fit in the intended storage location. One of the most famous cases of an overflow bug is the overflow bug that destroyed an Ariane 5 rocket in 1996*.

Fortunately, .NET has a dedicated exception to highlight overflow problems. Just run the following VB code and watch the OverflowException appear.

So, given this class:

Why does the following unit test fail?

What options are available to fix the problem?

* The article Design By Contract: The Lessons Of Ariane says the real error was a "reuse specification error". Quote: "To attempt to reuse software without Eiffel-like assertions is to invite failures of potentially disastrous consequences".