Event Leapfrogging

(Thanks to Sam Bent from the WPF team for identifying and giving a name to the problem)

Event Leapfrogging is an issue that arises from a combination of two inherent aspects of .NET events: multicasting and synchronous handler execution. A common place that it shows up is in property change handlers in WPF controls and INotifyPropertyChanged objects.

Here’s some code demonstrating the problem: Continue reading

No more IIS7 WCF REST 404 Error!

Recently I’ve been trying to host a WCF REST .NET 4.0 service in IIS7. I downloaded the template for VS2010 used for creating REST services as explained here. Running the sample application found on that website worked fine from VS2010. I then switched to hosting the service in IIS7. The result however was a 404 error, not exactly what I was hoping for. My coworker Dan Hanan tried the same thing on his machine with complete success. We looked at the service configuration, IIS7 settings, among other obscure settings without success. Google wasn’t especially helpful since most of the results kept saying things like “add an *.svc file” (which is not required/used in .NET 4.0 REST services), others mentioned changing an IIS7 handler mapping so that the *.svc file would not be required, but none of these solutions helped. Tracing didn’t help me get any closer either.

Still the problem felt like a server issue, so I tried to narrow the search. I eventually came across this blog. There was a link to a question on the MSDN forums that mentions a handler mapping named “svc-Integrated-4.0”. When I looked at my handler mappings in IIS7 it did not contain that mapping. The last post on that question contained a link to the MSDN post One-Time Setup Procedure for the Windows Communication Foundation Samples explaining some steps that need to be taken in order to use the .NET 4.0 WCF services in IIS7. When I tried to run the aspnet_regiss and ServiceModelReg.exe commands explained in the post I only ran into more errors.

Frustrated I talked to my coworker Travis Schilling to see if he had any ideas and to see if his IIS7 contained the mapping. His IIS7 did contain the mapping and he was pretty sure it was installed by VS2010. After a little discussion we decided it would be best to do a repair install of VS2010. After the repair installation the mapping showed up in IIS7 and the REST service ran as expected. I’m not sure why the handler mapping wasn’t installed before, I can only assume it’s because I installed VS2010 before I installed IIS7.

Code-First Entity Framework

Update (12/08/10): This week the Entity Framework team released CTP5 of the code-first library.  I was hopeful that this new version would fix my issues below with creating a SQL Express database in an arbitrary directory or the ASP.NET App_Data directory.  Updated my code to use this latest CTP5 binary – no difference.

Just a short post this time about the cool new “Code-First development” option that the MS data team made available a few months ago.  There are already some great walkthroughs (ScottGu, Scott Hanselman) about this topic, so I’m not going to repeat it all here.  Below are just some thoughts on where I find it useful, and a couple issues I’ve run into.

I really like the concept:  instead of building the database first, just write the code (more precisely, write the model object classes) and at runtime, the code-first library will interpret properties on the classes, and use some conventions to come up with how those objects should be stored in the database.  You don’t have to add attributes to your classes or properties – the framework inspects everything at runtime. When the code runs the first time and the database doesn’t exist, the code-first library creates the database for you (from then on it tracks a “hash” of the structure of your objects and reacts when there has been a change since the database was created).  There are configuration options (set via attributes or a code-based API) for what to do if the database already exists, ways to fine-tune relationships between objects, etc.

Of course when we’re writing a production quality, large scale application, we will still create the database schema first, probably have a bunch of stored procs to go along with them, and then use Entity Framework to hit that database.  But…there are a class of applications that this code-first mentality is great for: quick and dirty demo apps and local structured data storage to name a couple.  In the past couple years, I’ve gotten into a pattern of writing “xml data providers” for various applications, that just read & write to a local XML file (usually for mock/demo data, offline capabilities, etc).  We always try to start with built-in serialization of our model objects, but inevitably the format isn’t good, or we need some customized format, so we end up writing our own XML parsing code.  This code-first addition to Entity Framework seems perfect for these situations – no data access code to write!

Since code-first supports SQL CE which does not require any SQL install, it ends up being just a .SDF data file local to your application – just like my old XML files that I used to parse!

Update (12/08/10): one of my co-workers pointed out that you must be using .NET 4 to use SQL CE without any SQL installation.  On a recent project, we used SQL CE, but in .NET 3.5 and still needed to install it before we could use it.

I’ve done the walkthroughs above and have it (mostly) working, at least with the SqlCe and Sql clients.


The main problem I’m having is creating the database on first run with SQL Express.  It works fine with SQL CE and Full SQL.  With SQL Express I have varying outcomes – very rarely, it WILL successfully create the database the first time, and then most of the time it will fail.  IF the database is already created, the code-first libraries work great.  When failing to create the database, I get an exception:

The underlying provider failed on Open.
Cannot open database "FootballDB" requested by the login. The login failed.
Login failed for user ‘{myAdminUsernameHere}’.

I’ve searched around, even posted questions to the forums, and emailed some MS guys.  No answer yet…

I’ll keep plugging away at it, or maybe one of you can point me in the right direction!  I haven’t tracked down exactly when they plan to release these bits – for now it’s just a CTP.  Hopefully this fires you up to go check it out!

Connection Strings

For reference, here are the connection strings I’m using for various connectivity methods:

SQL CE provider

<add name="FootballDB"        
    connectionString="Data Source=FootballDB.sdf"        

SQL Express Provider (default SQL data directory)

<add name="FootballDB"        
        Data Source=.\SQLEXPRESS;Initial Catalog=FootballDB;        
        Integrated Security=True;MultipleActiveResultSets=True;        
        User Instance=True;"        
    providerName="System.Data.SqlClient"    />

SQL Express Provider

(in the “App_Data” directory of an ASP.NET application)

<add name="FootballDB"        
  connectionString="Data Source=.\SQLEXPRESS;
      Initial Catalog=FootballDB;Integrated Security=True;        
      MultipleActiveResultSets=True;User Instance=True;"            

Full SQL Server

<add name="FootballDB"        
  connectionString="Data Source=(local);Initial Catalog=FootballDB;        
    Integrated Security=True;"        

What is RECESS ?

Here at InterKnowlogy, as a Microsoft Gold Partner, we pride ourselves on being able to keep up with the latest and greatest technologies, and to bring that breadth of knowledge and experience to the table for our customers.  As an example, the latest projects we’re working on are based on WPF, Silverlight, Surface, Windows Phone 7, and even iPad development.  As we all know, the pace at which new technologies come out of Microsoft and other industry leaders these days is crazy, so it becomes difficult to keep up. 

At IK, we have a perk we call RECESS

Research (and)
Coding (to)

The company gives us some time each week to work on whatever we want – learn a new technology, write an app for a different platform, investigate the feasibility of some new pattern, catch up on new language features, etc.  It’s a great investment that IK makes in us to spend a few hours away from our current project, doing something completely different, and then share that knowledge amongst the rest of the company.  We got the idea from one of our devs working at Microsoft a couple years ago – that team had a similar program.

We don’t always end up with a finished “product”, maybe we just cut some sample code, read some articles, etc. but once in a while, we end up with some very cool stuff.  As an example, some of the actual software we’ve created during RECESS:

  • Surface Craps
  • Surface JukeBox
  • Wish 43
  • Surface Curling
  • Firebrick
  • Atlas (Virtual Earth on Surface)
  • 3D Boxes (Surface physics engine display)
  • Surface PixMatch (child picture matching game)
  • Surface YouTube viewer
  • Blackjack
  • . . .

Anyway, thought the RECESS concept is worth mentioning – I think it’s a very cool “feature” of working here. 

Well, … this afternoon is RECESS, so I have to get busy learning something new…

Visual Studio Installer Projects and “Previous Versions”

I’ve never really taken the time to learn the exact logic the VS installer projects go through when installing a “newer version” of software.  We just had the question come up here again, so I decided to investigate.  There is a ton of information about this online, Google proves that, so here is just my take on boiling it all down to my “cheat sheet”.


Setup Project – Properties

Version – you should change this to match the version of the new software you’re building the installer for.  When you change it, you get the prompt that you should change the ProductCode.

  • If answer YES, then the ProductCode is changed (UpgradeCode remains the same – this is how it tracks different versions of the SAME software).  Now you have to worry about the RemovePreviousVersions and the file versions of each assembly you’re installing.
  • If answer NO, then the ProductCode is left the same, and users will get the “you must uninstall the existing version” prompt at install time.

The “cheap” way out here is answering NO.  This forces the user to uninstall any previous version and then they run your newest installer.  You are guaranteed (mostly) that all the new files will be laid down since the previous versions have already been removed.

RemovePreviousVersions – If this is True, the installer will first run the “uninstall function” on any previous versions (different ProductCode) of the same software (same UpgradeCode).

  • Uninstall function is pretty nebulous.  It sounds like it’s going to physically uninstall all the files, but it’s really not.   At least since VS2008, it does a “smart file compare”…
  • First let’s assume you’re installing to a new physical location (maybe a “versioned” directory structure).  In this case, the entire directories for old versions will be removed and the newest version will be copied to its specific directory.  That’s kind of a bummer to have versioned directories though (especially if you have data files laying around in that dir)
  • If you’re installing to the same directory as the previous version, then it get’s a bit more hairy.  When the new installer has files of the same name as the previous versions, it COMPARES FILE VERSIONS of those files to decide whether to overwrite or not.  So … you have to be super detailed about updating AssemblyInfo.cs AssemblyFileInfo atttributes on ALL assemblies in your software.  This can get painful if you’ve got many projects/assemblies involved.  If you’re in this boat, you definitely need some kind of build process to auto-increment the versions of all assemblies.

For now, my cop-out answer is to upgrade the installer project Version and answer NO to the prompt (keeps the same ProductCode).  Shift the pain to the user, right?!  🙂

Up next: I’m working on an automated way to update all the AssemblyFileInfo attributes in a whole tree of projects, using the Community MS Build Task called “FileUpdateTask”.  Stay tuned…

Visual Studio Unit Tests – DeploymentItem

I’ve run into this before, and I ran into it again this week, so now I’m writing it down so that *we all* won’t forget about it next time.  🙂

I have an XML data provider class library that relies on the presence of an XML file to parse at runtime.  I am writing tests for that data provider using Visual Studio test framework.

The issue is that the tests are run in the funny “TestResults” sub directories, by default named based on the date/time of the test run.  When the test runs from this foreign directory, the test and data provider assemblies are copied there, but not the XML data file.

The Visual Studio test framework provides an attribute called DeploymentItem that you can use for just this issue.  It allows you to mark a test with the attribute to describe that you need other items besides the assemblies for the test to run.  In the example below, I’m specifying that from the unit test directory, go up and over (relative pathing) to the data provider directory and find the Data.xml file.

[DeploymentItem( @"..\UnitTestDeploymentItems\Data.xml" )]
public void TestMethod1()
    var c = new SomeClass();    
    Assert.IsTrue( c.CanYouSeeTheFile() );


What they DON’T tell you, or at least I can’t find documented, are the other 2 things you have to do to get this to work.

#1 – the required file must be marked as Content & Copy (if newer/always).  This is usually the case already, since I almost always need that file with the data provider assembly up to the consuming app directory. 

#2 (and not obvious at all) – you must go into the .testsettings properties for the unit test and select “Enable Deployment”.   Double click the .testsettings project (in the Solution Items folder) and select the Deployment item in the left side list. 


There you have it – the test should now succeed, since the dependent file(s) are there are test runtime.

.NET Rocks Podcast

My co-worker Kevin Kennedy (surface/graphics/3D expert) and I recorded a podcast for .NET Rocks, which hit the streets a couple days ago.  We talk about developing for the surface, loosely coupled WPF apps, everyday WPF life with VS 2008 and Blend, RECESS, and a few other topics.

There’s even an announcement about how/where you can get the Surface SDK bits, without buying a Surface table!

Check it out here!