Heading to TechEd
I’ll be heading to TechEd North America this weekend. This year it is in Los Angeles.
It has been quite a while since I’ve been there so I’m really looking forward to it. Hopefully the flu scare and the economy (and associated budget cuts) won’t cut down attendance too drastically.
Houston ALT.NET Coding Dojo on TDD – May 7, 2009
J.P. Hamilton has organized a Coding Dojo that will cover TDD. It will be held at the Microsoft offices in Houston at 6pm on May 7th. Space is limited to 40 participants so sign up early if you want to attend.
Announcing Reference Assistant 1.0
The product I have been working on, Reference Assistant, was released a few weeks ago. Reference Assistant is an extension for Visual Studio 2005 and 2008 (and soon 2010). In short, the goal of the product is cut down the time spent debugging runtime errors due to missing dependencies or errors in configuration.
Here are a few highlights of the capabilities in version 1.0:
- Configuration files for Spring.net, Windsor, and Unity can be parsed and displayed visually in a tool window. Missing or incorrectly spelled types are pointed out (project reference paths are searched for required dependencies).
- Navigation to object definitions in supported IoC/DI configuration files
- Any dependencies detected in configuration files can be automatically copied to the project output directory upon successful build.
- Reference Paths can be setup automatically using rules setup in preferences.
- Version conflicts between dependencies are displayed visually and in a tool window.
- Generate a report of all required assemblies for a project’s deployment, including dependencies defined in IoC framework configuration files.
- Extensions can be written to support custom file formats or configuration types.
For more detail in addition to the product pages, we have written a blog post walking through the functionality available in Reference Assistant for Spring.net XML configuration.
If you think you or your team could benefit from a tool like this, download a 30-day trial here.
Watch out for those WaitOne() overloads (when you need backwards compatibility)
Recently I was writing some new functionality that ran work on background threads. The functionality isn’t that important but one of the classes I was using to get the correct behavior was AutoResetEvent. Specifically the AutoResetEvent.WaitOne() method.
Since I really don’t use this class very often, I relied on intellisense to give the list of method overloads and I selected the WaitOne(Int32) overload which allows the thread to wait a given number of milliseconds unless signaled first. My compile worked and the functionality ran properly in Visual Studio 2008 SP1. Since I share the of the same code base when my product is installed in VS2005, I jumped over and the product compiled and ran perfectly there as well.
I forgot all about this until I was doing the final testing in preparation for a new release. The first few VPC images took the installation and ran fine. However, when I ran the installation in a VPC image that had a clean installation of VS2005 SP1 and nothing else, the product did not work properly. I was puzzled until I enabled logging and found that I was getting a MissingMethodException on the WaitOne(Int32) method.
I’ll spare you the details of the agony but I thought about this for a while and decided to try installing the .NET 3.5 SP1 framework in this VM and, low and behold, the problem vanished.
It turns out this method overload was introduced in .NET 3.5 SP1 but because System.Threading resides in mscorlib and there is only a 2.0 version of that assembly, any .NET 2.0 application (which in my case was the VS2005 package) is able to compile against it and run as long as the SP1 version of .NET 3.5 is present on the machine.
The solution was to use the WaitOne(Int32, bool) passing false to the second parameter which gives the same functionality.
I’ll be watching for this type of thing a little closer from now on.
D2Sig in Houston
This past Thursday, I attended the first meeting of the D2Sig in Houston. The D2 stands for "Developer 2 Designer" and the group will be focused on the XAML technologies of WPF and Silverlight as well as any area where developers and designers might need to work more closely than they have in the past.
Markus Egger from EPS was the presenter and, as always, he gave a great presentation which included a general overview of WPF, Silverlight, and some demo video of a Surface table in action.
I would recommend this new group to designers or developers in the Houston area that are interested in the these new up and coming technologies.
I’m guessing around 30 or so people showed up to the first meeting so I think that is a pretty good start.
J Sawyer has an official announcement here for the first meeting with a little more detail. The upcoming meetings will be the first Tuesday of each month at the Microsoft offices in Houston.
ToolStripComboBox Drop Down Sizing
This last night I worked on a bug where I had a ToolStripComboBox in a Visual Studio custom tool window that holds a list of files but would cut off the filenames in the dropdown list if the paths became too long.
Easy enough to fix, or so I thought. After trying out about all of the property setting combinations I could think of, I never could get the control to automatically size the dropdown list width to accommodate the widest item currently in the list. This is sort of ridiculous, in my opinion, but I could not find a way to do this without writing some code to do it.
Here is the code that I wrote so hopefully someone will save some time by seeing this and not spend their Friday night on search engines and MSDN attempting to find a way to accomplish the goal:
int i = cboFile.Items.Add(file);
//make sure dropdownlist width is sized correctly
Graphics g = cboFile.ComboBox.CreateGraphics();
SizeF size = g.MeasureString(file, new Font(cboFile.Font.FontFamily.Name, cboFile.Font.Size));
// Set the DropDownWidth if the item has a greater width
int itemWidth = (int)size.Width + 10; //add a little empty space
if (itemWidth > cboFile.DropDownWidth)
{
cboFile.DropDownWidth = itemWidth;
}
You can ignore the definition of "i", I was using that later in the code to do some processing specific to my extension. It is possible that there is an easier way to do this, but I couldn’t find one.
Tags: toolstripcombobox, dotnet
Updated ASP.NET Dynamic Data Preview Released
Scott Guthrie announced the availability of a new preview of the ASP.NET Dynamic Data functionality.
The idea behind this functionality is that you can generate a fully functional application based upon a LINQ to SQL or LINQ to Entities model. This reminds me a lot of the Naked Objects Framework from a few years back in the java world. Naked Objects generated a rich client Swing application but the concept is identical. It does appear, however, that ASP.NET Dynamic Data allows a little more customization of the UI than I remember from Naked Objects.
I bet if most users of smallish data entry applications knew in advance how much the development of their small application was going to cost them, they would gladly accept an application with limited UI goodness for something quickly available and just works.
I know that I will consider this tool in the future when I need to create small data administration type applications. Saving time and money on those small applications can make more budget available for the applications that can really impact business capability.
Tags: aspnetdynamicdata, aspnet, dotnet
Unity Application Block 1.0 has been released
The Unity Application Block version 1.0 has been released and is available on CodePlex here.
A good overview of the configuration of Unity was written by Matthew Podwysocki.
The xml configuration is a little unique compared to other DI containers. I plan on adding support for the xml configuration to Reference Assistant before the first public beta is out.
Tags: unity, ioc, dependencyinjection, dotnet
Mono 2.0 (.Net 2.0 compatible) is coming soon
According to Redmond Developer News, the beta of Mono 2.0 will be available for download Friday March 14. Mono is an open source implementation of the .Net CLR and libraries and runs on many platforms, including OSX, Windows, and Linux.
I am a little mystified as to why a developer would target Mono if they need to run on Windows, but then I have always been a little puzzled with certain aspects of the Open Source movement. If the CLR is free for me to use in terms of costs to me or my customers, and available on pretty much every windows installation out there, then that is free enough for me.
Now targeting other operating systems with Mono is a different matter all together and is where I see Mono as a useful and quite interesting tool.
I will be honest. I have not following the progress of Mono very closely at all. When I saw the announcement of the pending beta availability I went to the Mono site and read through their blog. I was shocked at how much they have working on other operating systems. I have listened to podcasts with Miguel de Icaza when he talked about the relatively small size of the core Mono dev team so this makes their accomplishments nothing short of astonishing in my view. Here is a short list of stuff they have working for mac developers:
- They already have Mono running on the iPhone.
- ObjC# bindings to provide access to Objective-C APIs from Mono
- Cocoa# has been developed to provide cocoa bindings.
I would imagine that Silverlight will help out some with Mono adoption since the team is also making that available on Linux via the Moonlight project.
Reasons to like NHibernate and ORM
Ayende Rahien, a contributor to NHibernate along with many other open source projects, has written up a post listing the features he likes about the ORM tool.
I am a fan of ORM and have used NHibernate extensively on a large project over the last few years. Prior to that, I had used TopLink and Hibernate on java projects.
Ayende’s listing pretty much summarizes why I like NHibernate and also has points that apply to many other ORM products as well:
- Caching. NHibernate is specifically flexible in this area but many ORM products excel in this area over sql based DAL implementations.
- Multi-database support. Using an ORM insulates your code from the differences in database dialects. This might sound insignificant, but if you have ever had to migrate any application from Oracle to SQLServer, for instance, you will know what a chore it can be.
- A dramatic reduction in plumbing code for your application. Although he does not directly say this in his list, he does mention writing applications with no sql in them. What I’ve noticed is that there is a ton of code that gets written in your application just to put data in your domain model and pull it back out. Using an ORM removes this code from your application and puts in the domain of the ORM, which is code someone else writes and tests.
Using an ORM seems to encounter a great deal of resistance from some enterprise developers. Below are a few of the reasons that are usually given against using an ORM product on a project:
- Even though you are not writing sql, you still have to perform the mapping.
- The sql generated by the ORM cannot be optimized for specific cases and will be slower.
- Using reflection is slow.
- Using an ORM makes the data access problems more difficult to debug.
- Everyone knows sql and nobody knows <ORM product>.
Even though are not writing sql, you still have to perform the mapping
This is a good point. It is true that the work of mapping data to columns in a database is moved from sql to the mapping layer of the ORM. In the case of NHibernate, this would be XML files. So in that instance, no work or time is saved. Where the time savings comes in to the picture is when the actual mappings are used. NHibernate takes those mapping files and performs the domain object instantiation and population for you.
Detractors of the ORM approach might counter with the argument that the usage of the ADO.net data constructs, for instance the typed dataset, also removes the need to write object population code. Although this might be true, I believe that passing ADO.net data types around your application leads to poor application architecture, not to mention performance problems. Typed datasets are notoriously slow when it comes to serialization.
The sql generated by the ORM cannot be optimized for specific cases and will be slower
This might be true for certain ORM products, but has not been my experience with NHibernate. The generated sql is quite good. However, I have encountered situations where the sql has been unacceptably slow and in those cases I can almost always place the blame on a poorly designed database model.
NHibernate has the ability to pass sql to the database, if needed. SQL optimizations can also be placed in the mapping files to help in situations where NHibernate could not generate the optimal queries. Named Query support, added to NHibernate 1.2, has helped as well for specific query situations that might not be the normal path for searching for a given object type.
Using reflection is slow
This is always an interesting discussion to have with a stubborn developer. Yes, it is true that a method invocation via reflection would be slower than a method invocation compiled into the IL directly. The tradeoff you are making is flexibility for a little speed. The reality of the situation is that the slowdown for reflection will be dwarfed by the IO wait for the database and you will not notice it.
NHibernate also has functionality called the reflection optimizer which will dynamically generate classes for populating your domain objects at startup time. This a tradeoff in startup time to remove the cost of reflection for each domain object population. Early versions of the reflection optimizer were noticeably slower at startup for larger numbers of mapped classes, but this has been corrected in the newer versions of NHibernate.
Performance problems in enterprise applications are caused by poor database design or poor approaches to data retrieval in 99% of cases. I should also lump screens that have too much data on them in with this category as well. The other 1% of the time the performance problems are caused by poorly written threaded code, poor algorithms, and poor integration choices with 3rd party applications. I have never encountered an enterprise application that was too slow because of reflection usage.
Using an ORM makes the data access problems more difficult to debug
I hear this complaint a lot at the beginning of projects specifically from developers that have never used ORM before. I would say that the real statement that should be made about the subject is:
Using an ORM makes the data access problems different to debug.
Most of time, a developer simply needs to familiarize themselves with the debugging facilities available in the ORM tool they are using. There is cost to learning what is available, just as there is a cost up front for learning any new tool or concept, but the productivity that ORM gives a project overall will make up for the learning curve.
Everyone knows sql and nobody knows <ORM product>
I also hear this complaint a lot at the beginning of project where I propose using ORM. It is difficult to convince someone that ORM will payoff after the learning curve is overcome when they have never used an ORM product. There are many blog posts on the web complaining that ORM does not pay off in the long run but this simply has not been my experience.
The response I usually give is to try the product for a pilot or proof of concept to test the pluses and minuses. Most clients are won over when they see the benefits of caching in the ORM and the ability to migrate databases with just minor mapping file changes (or maybe none). Also, when they actually try using NHibernate or another ORM product, they find that the product is not quite as unapproachable from a technical standpoint as they thought when they first heard of the concept.
Tags: nhibernate, orm, dotnet