The problem with beta software libraries

I'll admit it - I'm a serial early-adopter. I was man/mad enough to actually try using Windows Vista Beta 1 for over a whole month as my main workstation OS both at home and at work, and wasn't put off enough not to be considering doing again with Beta 2.

But the problem is compounded when you want to get ahead with new technologies like Windows Communications Foundation (formerly Indigo) - as the library is refined, there are inevitably times when "things change".

For WinFX this seems to have been the norm rather than the exception case - the Windows Workflow Foundation book I bought to help me get going is already out of date in a number of key areas (tho' it does a great job of introducing the concepts). Worknig with WCF, my problem was that the config schema changed between the Jan CTP and the Feb CTP, making the majority the WCF samples on the net incorrect.

To make matters worse, Feb CTP installation does not update the configuration schema, therefore the intellisence will not match the changes that were made in that version - so you don't get any help from VS.

Fortunately, in this post, "WCF configuration schema", Guy Burstein provides not only a reminder about the problem with breaking changes, but also a fix for the problem with a revised schema file to load into Visual Studio.

"forums.microsoft.com to the rescue once again!" shouted Little Cook.

Sahil Malik - blah.winsmarts.com

I've just found the blog of Sahil Malik of Winsmarts.com and in particular a set of postings in which "intend to bring C# 3.0 down to earth".

I'm impressed - by focusing on the smallest language feature possible and covering it in a practical sense, he does a great job of explaining some of the new language features of C# 3.0.

The first 3 postings are:
Part 1: Implicitly Typed Local Variables

Part 2: Anonymous Types

Part 3: Extension Methods

More good stuff to read, and it's well worth subscribing to his blog feed too.

Karl Seguin [MVP] : Have I inherited a disaster?

In his blog on CodeBetter.com, Kark Seguin provides a very useful list of simple searches to run against anyone else's code you have foisted upon you.

To quote from his posting:

"Have I inherited a disaster? I hate taking over someone's bad code. The projects always go on forever and you are forced to follow bad practices to try and string together fixes and features without it all crumbling down. There are some quick, not always 100% accurate, ways to know whether you've inherited a disaster"

It's an excellent read, and a good aide-memoire because it brings such a quick way to check for best (or worst) practice.

You can find the posting here.

.Net code generation strikes again...

In his blog, Stephen Kaufman shows a nicely worked example of using CodeDom to Programmatically Create Windows Workflow Rules.

What makes this interesting is not only does it provide a solution to a real-world problem, but it also re-enforces the underlying nature of .Net - i.e. that .Net code gets compiled into MSIL which the runtime executes.

Definitely worth a read.

Migrating .Net 1.1 to 2.0

Peter Laudati has just posted a great "Four FAQ overview of some of the issues involved with doing a .NET 1.1 to .NET 2.0 migration. The ASP.Net migration guidelines in particular present include a wealth of MSDN and other technical references - including our old favorite the Web Application Project Template.

Excellent stuff.

ATLAS Toolkit Update

Well, my fix didn't make it into the ATLAS Toolkit directly, but the latest refresh does provide a fix for the problem I blogged about before.

The refresh is worth getting not ony for the fixes, but also for the new controls it gives. Probably the most interesting is the Modal Dialog Extender. This little beauty lets you use any panel on a page as a modal dialog, rendered as a floating panel with the rest of the page grayed out and inaccessible. Very nice!

VS2005 Web Application Project v1.0 released

I've blogged about this before here and here, but it's definitely good news that Scott Guthrie has announced that
VS 2005 Web Application Project V1.0 has been released.

Having now worked extensively with the "Whidbey" web project model, I'm glad that this alternative is available and supported. I have a feeling that the Web Application Project model is actually going to be the more used - at least amongst the professional development community - as it provides much more control over the structure of your project.

As always, this is my 2p and your mileage may vary.

Closing the circle... Finding that missing Linq

I've been looking at Linq recently in the context of using it in anger to provide in-memory filtering of List<thing> instances.

My problem was that I had an existing class library project that I needed to "Linq enable", and just adding the references to System.Query et al just doesn't work.

It turns out that you need to modify the project file itself.

You can do this in any text editor easily enough, but I found this trick for doing so in VS2005.

1. Right click on the project in the solution and select "Unload Project"
2. Then right-click again and select "Edit project file" from the context menu to open the project file up in the editor. This gives you all the benefits of syntax highlighting, intellisense, etc. Good stuff.
3. Make your changes to the .csproj file and save 'em
   
4. Right click on the project in the Solution Explorer and select "Reload project"
   

Now, to Linq enable a project, you need to find the line in the project file that reads

<import project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />

and replace it with the following lines

<import project="$(ProgramFiles)\LINQ Preview\Misc\Linq.targets" />
<!-- Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" / -->

Of course, your path to the Linq.targets file may be different if you've installed Linq anywhere other than the default.

Recompile your project and you'll find that all the Linq goodness is available and working within your existing project.