I talked with one of my buddies who is a budding WPF expert who told me I was crazy and needed to get a psychologist.  He is probably right.  But something was telling me that this was a system problem, not a WPF problem.  But for the life of me I wasn’t seeing it.

Every programmer needs a toolbox.  Turns out there are several performance analyzing tools for WPF that ship with the Windows SDK.  One of them is the WPF Performance Suite.  While the tool is really cool…it didn’t help at all.  If you want to check the performance of your WPF application while it is RUNNING, this tool will be great.

My problem was start up.  Here was the breakdown: 60 seconds before I saw a WPF window, 30 seconds before anything displayed.  After that, everything ran fine.  Time for a different tool.  Namely: Process Explorer from SysInternal (via Microsoft.com).

I was able to find my Hello World WPF application in Process Explorer (on my system, all .Net processes are colored yellow), then displayed the lower pane to display the DLLs used by the process.  (BTW: I just confirmed that Windows Live Writer is a .Net application).

I found one interesting dll that was referenced: NCover.  A while back I had installed a trial version of the commercial product (this was not the open source version). I have no idea what it was doing there, but it was there.  In fact, it was referenced in every WPF application that I loaded — including WPF applications that I did not write, like the Subscription Center.

Long story made only slightly longer, I uninstalled NCover and now everything loads in about 10 seconds (a nine fold improvement), but I still don’t know what NCover was doing.  If you know, please let me know. 

What am I looking forward to:

* Visual Studio Speed improvements.  Nuff said.  Please keep making it faster.

* SQL Server 2008 features in LINQ 2 SQL. I just did a big demo of SQL Server 2008 T-SQL changes for BSDG, and the one thing I was not able to do was really show off the new features.  How do you use the HierarchyID in LINQ2SQL right now?  With stored procedures.  I’m hoping this release will fix that.

Also, this pretty well determines when SP1 will release: at the same time as SQL Server 2008.  If you listen to .Net Rock show 340, they say that a SQL Server 2008 release is imminent.  Which could mean anything.

* Routing for ASP.Net. We aren’t talking about Routing for ASP.Net MVC Framework, but regular old WebForms.  I love this.

* Cold start performance improvements.  One part of working with .net that kind of sucks is the cold start.   Someone boots up their computer and starts your application, which take forever to load.  Then the next time you load, it boots right up.   According to Scott Guthrie the are seeing up to a 40% performance increase.

What I’m interested in:

Here are some new features I’m interested in, but I don’t expect to jump on right away.

* Dynamic Data. Much has been said about this already.  I will be looking into it.  There is scaffolding support in there, as well as a lot more.  Plus it can be used with multiple ORM solutions.  I believe LLBLGen will have support, and Scott Hanselman said NHibernate support was also being worked on.  I suspect SubSonic in there somewhere as well.

* Entities Framework.  I’m always looking for better ways of getting data from a database.  While this doesn’t seem better than some of my current tools (NHibernate, SubSonic, LINQ2SQL), I’m keeping an eye on this one.  If you read down Scott Guthrie’s blog comments, you will also see that Oracle will be supported with Entities Framework.

* Microsoft AJAX Stuff. I’m using JQuery for more of this right now, but there are some enhancements to the ScriptManager coming.  And JQuery or no JQuery, I still use the ScriptManager.

* Improved Client Distribution. While I mainly blog about Asp.Net, I also work with WinForms.  And in WinForms, .Net Framework distribution is always a hot topic.  Better bootstrappers, improved ClickOnce.  Give me everything you got.  One key feature: they made it smaller.

* More WinForms Controls.  These are actually some of the Visual Basic.Net PowerPack controls.  Thank you.

* WPF Stuff.  I having had the opportunity to really get into WPF yet, but the time will come.

OK, that is all that I’m going to list.  There really is a lot out there for a Service Pack.  But one quick note: this is beta.  And this is one beta I’m not installing yet — but I will as soon as it is released. 

If you are looking for more information, check out these articles:

Scott Guthrie: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx

Brad Abrams: http://blogs.msdn.com/brada/archive/2008/05/05/visual-studio-2008-and-net-framework-3-5-sp1-beta.aspx

Scott Hanselman: http://www.hanselman.com/blog/VS2008AndNet35SP1BetaShouldYouFearThisRelease.aspx

Tim Sneath: http://blogs.msdn.com/tims/archive/2008/05/12/introducing-the-third-major-release-of-windows-presentation-foundation.aspx

This is a fairly light presentation intended to introduce some new C# language features, VSTO integration features, SharePoint 2007 work flows, Office extension projects for Visual Studio, and generally using MS Office System as a development platform.

Thanks to Chris for recording and putting this out for me. I am hosting the video on MSN’s SoapBox.

I have to admit that there is a high degree of clipping and the video quality is poor overall. That said, the audio is just fine and much of the presentation is slides or Visual Studio which isn’t too bad considering. You can tell what we are making when you watch the video in full screen.

Enjoy.

VSTO in Visual Studio 2008

If you have Visual Studio 2008 installed, you can find the samples in this directory: C:\Program Files\Microsoft Visual Studio 9.0\Samples\1033.  Then extract the file CSharpSamples.zip.  The sample will be found at CSharpSamples\LinqSamples\DynamicQuery.

From the sample you will see that you can do perform things like this:

var query =    db.Customers.Where(         "City == @0 and Orders.Count >= @1", "London", 10).
   OrderBy("CompanyName").
   Select("New(CompanyName as Name, Phone)");

All of the heavy lifting happens in the Dynamic.cs file that has 11 classes.  The interface happens through DynamicQuery static class, which extends the IQueriable interface with new Where, OrderBy, and Select methods.  To use these extensions you have to include this line in your code: using System.Linq.Dynamic; along with the Dynamic file in your project.

I don’t have a use for this quite yet, but I think its time will come.

So, a fellow coworker called me out on this: why am I returning collections other than IEnumerable<T> anyway? What conditions actually require the extensibility of Collection<T>, or the extra utility of List<T>? I didn’t have an answer for this off the top of my head, so over the weekend I created a new experimental branch of a project and started hacking interface signatures. What follows are some conclusions from the experiment.

Setting Up the Experiment

I replaced all the public signatures of IList, Collection, List, etc. with IEnumerable<T>. If it was a public API input or output, its now IEnumerable. Each signature change was followed by re-running all unit tests to make sure that nothing critical broke.

Conclusion: System.Linq makes IEnumerable<T> Useable

There were two major “breaking” changes found in this experiment. The first is that IEnumerable<T> doesn’t expose a Count property, but there are places where we need to know if the list is empty, has one item, has N items, etc.

Fortunately, this codebase was upgraded to Visual Studio 2008 and a .NET 3.5 target a while back. This gave me an opportunity to use the Count() extension method from the System.Linq namespace. First problem: Solved.

Next, there are cases where I’d need to access items in a collection by index. The native IEnumerable doesn’t provide this, but System.Linq does with extensions like First(), and ElementAt().

So, there’s two big reasons for not using IEnumerable<T> taken care of. These changes handled almost all of the collection issues I ran into.

Note: now I’m “stuck” with the .NET 3.5 target. Not a problem for me, YMMV.

[Test]
public void GetControls()
{
    // SetUp code omitted for brevity...
    var cat = new BrowsableUserControlCatalog();
    var controls = cat.GetRegisteredUserControls(); // IEnumerable
    Assert.AreEqual(1, controls.Count());
    Assert.AreEqual("virtualPath", controls.First().VirtualPath);
}

Conclusion: Sometimes you have to extend Collections

One of the reasons that the Framework Guidlines encourage Collection<T> vs. List<T> is that Collection is easily extended. I ran into one case where a class had been extended from Collection<T> in order to change the behavior of the InsertItem() and SetItem() methods. So we have a collection that requires the ability to add items to it. Even worse, we have methods added to this collection to provide additional required functionality: swap to items in the collection, reset the sorting index of the items, move an item up or down, that sort of thing.

So, that’s one collection that remained as-is. I can live with that. Perhaps on some other weekend, I could split the additional functionality out from that collection and into “something else,” which might have additional advantages. Something for next time..

Conclusion: Sometimes you have to Sort() [for now...]

One List<T> that I haven’t gotten rid of (yet) relies on a Collection<T> supplied by another component. We are getting a list of files, and putting them into a sort order based on what the user interface wants. The library has no idea what kinds of sorting options are available, the calling implementation can do pretty much whatever it wants. The element that varies is the sorting routine passed into List<T>.Sort().

System.Linq provides an .OrderBy() extension, but its signature doesn’t match up with List<T>.Sort()…which turned into more of a change than I wanted to deal with for this current experiment. Saved for next time…

So what have we learned?

Extension methods are fun. I look forward to abusing them heavily in all my new work. Because of them, its now possible to change 99% of this API to use the most general collection types possible.

But does it make sense to do so? I’m not totally convinced. It does simplify things. The semantics of what you can do with a given collection is much clearer. Most of the time, we only needed the abilities of IEnumerable<T>, and it makes sense to use the most generic interface you can get away with – especially for a platform where you can’t predict how these things are going to be used.

• Pull up object browser, set Browse to only show 3.5. (Will not work if you set to all components)
• Set the filter to ‘Show Extension Members’

• Select a type in the browser
• In the right pane you will see an ‘Extension Members’ folder
• Now you can browse the public type extensions