Tonight I will be joining the Sarasota SQL Server User group and the Sarasota .NET User group at their combined May 2008 meeting. I will be presenting the Entity Framework and LINQ using the new bits that came out 2 days ago on Monday including the new features that it brings. I always have a good time at user groups and especially so when its a hot topic like the Entity Framework and LINQ.

I'll be showing several demonstrations using the Entity Framework that demonstrate how to use it in different scenarios and its future direction. I'm looking forward it!

Here is the logistical information for tonight's event and Here is link to a google map for directions.

5/14/2008 @ 6:00 PM - 7:30 PM

Welcome Time:
5/14/2008 5:45 PM Eastern Time

Location:

The Community Foundation of Sarasota County

2635 Fruitville Road

Sarasota, FL 34237

Cross posted from johnpapa.net

It's a litlte easy to get carried away with mocking when you first start doing it in conjuction with unit tests. Mocks are unbelivably flexible/powerful. However, to get the most out of them, you really need to be able to inject your mock into the class you're testing. Conincidentaly trying to leverage mocks in your code will lead you to the first tangible benefit of unit testing - you'll notice how tightly coupled your code is (i.e., impossible to test) and learn a wonderful aresenal of strategies to help you write better code.

There comes a point though where injection just doesn't make a whole lot of sense for anything _but_ testing and even then the value might not be that evident. Let's see how we can use RhinoMock's Partials to solve the problem. Take for example an LoginHttpHandler that looks something like:

public void ProcessRequest(NameValueCollection parameters)
{
   string userName = parameters["username"];   
   string password = parameters["password"];
   User user = User.CreateFromCredentials(userName, password);
   //do something with our user
}

This code is impossible to unit test because the call to User.CreateFromCredentials can't be mocked/faked/anything. The best we can do is mock whatever dependencies User.CreateFromCredentials has - but that's just a nightmare not worth exposing ourselves to.

What we can do is use a partial instead of a mock. A mock is a dumb object that only records expectations and actuals. A partial on the other hand exposes all of the behavior of the class we've created a partial for - except those we've explicitly set expecations on. For example, if we rewrite the above code as:

public void ProcessRequest(NameValueCollection parameters){
   string userName = parameters["username"];
   string password = parameters["password"];
   User user = GetUser(userName, password);
  //do something with our user
}
public virtual User GetUser(string userName, string password)
{
   return User.CreateFromCredentials(userName, password);
}

We can use a  partial to write a useful unit test (well, there isn't much to test for, but you get the idea):

[Test]
public void LoginHandlerInteractsWithUser()
{
   MockRepository mocks = new MockRepository();
   LoginHttpHandler handler = mocks.PartialMock();
   User fakeUser = new User();
   NameValueCollection nvc = new NameValueCollection();
   nvc.Add("userName", "un");
   nvc.Add("password", "pass");
   using (mocks.Record())
   {
      Expect.Call(handler.GetUser(nvc["userName"], nvc["password"])).Return(fakeUser);
   }
   using (mocks.Playback())
   {
      handler.ProcessRequest(nvc);
   }
   mocks.VerifyAll();
}

We create a partial of our LoginHttpHandler which behaves exactly like a new instance of it - except for those methods (like GetUser) which we've set an expectation on. Just like with a mock, if ProcessRequest called GetUser twice, we'd have to record that call twice. Unlike a mock however, if we didn't, the 2nd call would call the real implementation of GetUser.

The only other thing to keep in mind is that the method you plan on mocking must be virtual - this allows  RhinoMocks to override the method and do it's own thing (implement the record/playback logic).

In my recent trip down Java land, I actually have a hell of a problem doing this seemingly simple thing. I tried a number of mocking frameworks, eventually settling on EasyMock but the amount of work needed to set up partials was insane. If I missed something, I'd love to know about it.

Mike Moore (aka blowmage) has started a new podcast dedicated to all issues ALT.NET. Mike's an interesting cat. If you haven't checked out his excellent Rubiverse Podcast, do so; fascinating stuff as he gets cool guests. I think people who are in this community will be well served by his efforts. 

In the inaugural episode Jeremy Miller, Chad Myers, and I (the most over-podcasted developer ever) have a free flowing discussion on how we tackle the need for continuous improvement in our own ways. A lot of the conversations in ALT.NET center on this topic. It was a super fun conversation for me; it's always fascinating to hear about how other people tackle the problem of learning and betterment.

So pull up a chair and listen in. Looking forward to hearing some great content targeted at our budding community in the near future!

I don't know the proper term for the new functionality in Visual Studio 2008 SP1 for C# that does code anaysis and finds compilation errors without an explicit compile ( what I would term "Background Compilation" ), but Scott Guthrie provides the following description:

"The C# code editor now identifies and displays red squiggle errors for many semantic code issues that previously required an explicit compilation to identify.  For example, if you try to declare and use an unknown type in the C# code-editor today you won't see a compile error until you do a build.  Now with SP1 you'll see live red squiggle errors immediately (no explicit compile required):"

Holy time savings Batman, this is much needed functionality for those developers who are not using ReSharper or another tool that provides similar code analysis in the background. I had to jump on my development machine that is not running the Visual Studio 2008 SP1 Beta just to make sure this background compilation wasn't already being done in Visual Studio 2008.

I didn't put the feature through a thorough testing, but I was just happy that it would identify unknown classes and other little things. The red squiggles are a huge time saver.

This is worth Visual Studio 2008 SP1 alone. And, no, I don't know what performance impact this has on large projects :)

Recent Visual Studio 2008 SP1 Beta Posts:

• EntityDataSource Companion to ADO.NET Entity Data Model in Visual Studio 2008 SP1
• Dynamic Data Entities Websites - EntityDataSource and ASP.NET Website Scaffolding - Rapid Application Development ( RAD )

Scott Hanselman just published a blog post where he used NDepend to see changes in the code of .NET 3.5 SP1 beta (that has just been released). Let’s expose the exhaustive list of differences:

Summary:

# IL instructions:    8 598 933 to 8 589 008      (-9 925   -0.1%)

# Assemblies:    112

# Namespaces:    919 to 929      (+10   +1.1%)

# Types:    39 988 to 40 402      (+414   +1%)

# Methods:    387 421 to 385 253      (-2 168   -0.6%)

# Fields:    241 567 to 246 320      (+4 753   +2%)

636 new public methods:  

SELECT METHODS WHERE IsPublic AND WasAdded

57 new public types:  

SELECT TYPES WHERE IsPublic AND WasAdded

3.137 public methods removed (this number is biased by the fact that a public methods can be declared in an internal types): 

SELECT METHODS WHERE IsPublic AND WasRemoved

8 public types removed: 

SELECT TYPES WHERE IsPublic AND WasRemoved

5.623 methods where code was changed: 

SELECT METHODS WHERE CodeWasChanged

2.024 types where code was changed: 

SELECT TYPES WHERE CodeWasChanged

The list of assemblies we consider is made of 112 assemblies. 

Here is a 9000x1200 poster where methods where code was changed are located in blue (we degraded the quality to have a 2MB image file instead of 13MB):

And here is a list of coupling update for assemblies:

1. A blue cell means: {the X Assembly} is using {the Y assembly}.
2. Weight of a blue cell means: W types of the {the X Assembly} are used by {the Y assembly}.
3. A green cell means: {the Y Assembly} is used by {the X assembly}.
4. Weight of a green cell means: W types of the {the Y Assembly} are using {the X assembly}.
5. A black cell means: {the X Assembly} and {the Y assembly} are using each others.
6. A red tick on a cell means: the coupling has been changed.
7. A red tick with a plus on a cell means: the dependency has been created.
8. A red tick with a minus on a cell means: the dependency has been removed.
9. An assembly name underlined means that its code has been changed.
   

I've had "searching" on my mind lately but in a very narrow focus. Specifically, I have a Brownfield application for a client I dig up every so often whenever new features need to be added to it. (Off topic: As soon as I can re-brand the sucker, it'll make a dandy little sample app for some Brownfield-related posts and webcasts. There, I said it on the Internet so the guilt will be that much greater if I don't follow through.)

One of the key components to this application is a document repository that you can search both with meta-criteria as well as a full text search of the documents (see screenshot).

The meta-criteria part is boring. Bunch of lookup tables in a SQL Server database and I'm building up a SQL query manually in the search process. (I *did* say this was a Brownfield application.)

The full text search is done through a kind of poor-man's search index. I'm using a custom catalog with Microsoft's Indexing Service, available on Windows Server 2000 and later.

To do this, and I'm going to skim partially because it's not really the focus of the post but mostly because I think it's outdated, I create a catalog that indexes the document folder. Then, I make the catalog accessible to SQL Server so I can combine queries to it with queries to the metadata. Here's the SQL to do so:

EXEC sp_addlinkedserver <linkedServerName>, 'Index Server', 'MSIDXS', '<name of catalog>'

Now I can write queries like the following:

SELECT DocumentID, Title, Date, Filename
FROM doc_list_view dl,
OpenQuery( <linkedServerName>, 
   'SELECT Filename FROM SCOPE( ) 
    WHERE CONTAINS( Contents, ''<queryTerm>'' ) '
) q
WHERE Date BETWEEN 'January 1, 1850' AND 'December 31, 2008'
AND q.Filename = dl.Filename
ORDER BY Date DESC, Title

Easy as raccoon pie, yesno? The nice thing about this is that it will automatically index all Microsoft Office docs and PDFs are handled by installing Adobe Reader 8.0 (though it's a separate download for 64-bit).

Fast-forward to 2008 and the Indexing Service is no longer turned on by default on either Vista or Windows Server 2008. Posed a problem for the client who runs it locally on his laptop but it was easily remedied simply by turning the service on. For my own newly-minted Server 2008 machine, Indexing Service and the new Windows Search can't run together. And I'm loathe to enable the older technology so it's time to update if I can.

That led me to this page which confuses me to no end. Starting with the terminology: Windows Search, Windows Desktop Service, Instant Search, Windows Indexing Service, Indexed Search, MSN Desktop Search are the terms used to discuss various incarnations of the technology. And that's not including codenames or different versions of the same technology. Adding to my addlement is when Microsoft changes terminology from one page to the next. One example is this page which, in the section on the History of Windows Search, leads you to the download page for Windows Search for Windows Server 2003. That one is titled: Description of Windows Desktop Search 3.01.

So now I'm facing the unenviable, but oddly ironic, task of having to search through the myriad of search options for a solution that will run on Windows Vista, Windows Server 2008, and Windows Server 2003 (where the main site is hosted). At first glance, it seems Windows Desktop Search is the way to go for Server 2003 as it appears the new Windows Search is API-compatible with it.

In any case, this'll make one heckuva a sample for the Brownfield series on managing integration with external systems. Because as you've probably guessed by now, there are no automated (or even manual) tests for this whole process.

Kyle the Researched

• Optimize Managed Code For Multi-Core Machines
• Running Queries On Multi-Core Processors