GetType on a Dynamically Loaded Assembly

The application on which I'm working has the opportunity to dynamically load and assembly. Later in the application, one of the types from the loaded assembly need be retrieved using GetType. More specifically, the GetType was performed using a fully qualified type name (including the name of the assembly). But the GetType failed. Naturally, this begged the question of why GetType didn't find the type in the dynamically loaded assembly.

Ultimately, it comes down to how GetType operations. If you provide a string of the form "A,C" (for assembly,class), then GetType operates as if it were performing Assembly.Load(A).GetType(C).

Notice the Load method that is in there. If A exists in the default probing path, then there is not problem. But A doesn't include a fully qualified path. And if the assembly was originally loaded from a location other then the executable's directory, GetType will fail.

There are a couple of solutions to the problem.

1 - Put the assembly in the GAC. Then Load will find the assembly and GetType will work

2 - Add a codebase element to the config file. This element can be used to control the probing path, but you cannot probe outside of the executable's directories and subdirectories. The codebase element (which has to be created for each DLL) allows you to specify the full path to the assembly.

An Old Problem is New Again

I ran into a problem yesterday that brought back memories. And not the good kind of memories either.

I'm doing some work using TypeConverters. In particular, I'm creating a Windows Forms control that functions in a manner similar to a PropertyGrid, but with a user interface that looks more like a typical Windows form. You know, with labels, and text boxes. Because this is a generic control (that is, the fields which get displayed depends on the object associated with the control), I'm doing a lot of reflection to retrieve the properties that are required. And I'm using reflection (the GetValue/SetValue) to interact with the object. This last part (the SetValue method in particular) means that I'm using type converters to move the string values that are in the text boxes into the actual properties themselves.

Now type converters are quite useful. They expose a ConvertFromString method that (not surprisingly) takes a string value and converts it to a value of the associated type. If the string is not valid for the destination type, an exception is thrown.

Problem 1: the raised exception is System.Exception. I have no idea why the exception surfaced from ConvertFromString is an Exception. The InnerException is a FormatException, which is the type of exception that I would have expected. But no, ConvertFromString throws Exception. This forces me to use a pattern that I loathe - try {...} catch (Exception) { }

Whenever I teach, I always harp on this. You should (almost) never catch the general Exception object. You should only catch specific Exceptions. But because of ConvertFromString, I have to add to my list of cases where catch (Exception) is required.

But why should this matter, you ask. TypeConverters exposes an IsValid method. You should be able to check for the validity of the string value prior to calling ConvertFromString. This would completely eliminate the need to catch any exceptions at all. And it's the best practice/recommended/ideal way to go.

Problem 2: Int32Converter.IsValid("bad") returns true.

Think about that last one for a second.

According to the type converter for Int32, the string 'bad' is a valid integer value. In my world, not so much. If you spelunk the various classes in .NET Framework, you find out that IsValid is supposed to be overridden in the various converter classes. But the numeric classes don't bother to do so. As a result, the IsValid that actually services my request just returns a true regardless of whether the string is valid or not.

What's worse, this is a known bug that will never be resolved. Apparently to make IsValid work for Int32Converter is considered a breaking change.

So my suggestion (courtesy of Dave Lloyd) is to add a new method to the TypeConverters. Call it IsReallyValid. IsReallyValid could then be implemented properly without the breaking change. It could take the CultureInfo object necessary to truly determine whether a string is valid. For the base type converter, it could simply return a true.

Heck, let's go a step further and mark IsValid as being Obsolete. That would force people to move to IsReallyValid and correct any problems in their applications. And maybe, in a couple of versions, Microsoft could reintroduce a working version of IsValid and mark IsReallyValid as being obsolete. In this way, four versions from now (that's about 10 developer years), IsValid will work the way it's supposed to (and everyone would expect it to).

Looking for Mr (or Ms) GoodDeveloper

Business has been booming of late at ObjectSharp. Don't know whether it's the weather or the business cycle, but our recent company barbeque had more new faces that I've seen in many years. And we haven't lost any of the old faces either.

And yet it doesn't seem to end. At the moment, we're looking to add some consultants to our team. Specifically, we have the need for someone with Windows Forms experience, either in creating commercial-grade user interfaces on their own or with the CAB application block.

If you (or someone you know) has that experience and is looking to join a fun team of top-notch developers, drop me your (or your friend's) resume. You'll get a chance to work on projects that use cutting edge technology. You'll learn about (and sometimes use) technologies that aren't yet available. And, if you have the interest, we have six MVPs on staff to help you get your own designation.

If you don't fit into this skill set, fret not. There will be others coming along in the very near future. Just keep your eye tuned to this blog. 

Relieving File in Use Problems

It's quite possible this is old news to people, but it took me more than a couple of minutes to find the solution. I was using the FromFile method on the Image class to create a new Image object. When I was done with the Image, I needed to move the file. But it turns out that the file was still 'being used by another process'.

The solution is simple, but it didn't come immediately to mind because I'm so used to basically ignoring the scope of variables. The trick is to call Dispose immediately rather than waiting for garbage collection to do its thing. Once Dispose has been invoked, you can manipulate the underlying image file as you need to.

Code-Name Jasper

Named after a venerable Canadian national park (due to the overwhelming influence of Canadians on the Microsoft Data team, who are taking over the U.S. one developer at a time), Jasper is one of the incubation projects from the System.Data team introduced at MIX '07.

Built on top of the Entity Framework, Jasper provides a set of classes that can easily be used to perform CRUD operations on data. While this doesn't sound particularly exciting when phrased like that, the reality is that the classes are generated under the covers at run time.

So if I had a database that contained a Customers table, then Jasper allows me to create a DynamicContext object that has the connection string to the database. Then I can say "DynamicContext.Customers" and a Query object containing the customers in the database will be returned. Each customer object within this query has a set of properties that match to the columns in the table. The magic here is that database schema is being queried at runtime to determine which classes should be included in the application. And once retrieved, the query can easily be used to bind to elements on an ASP.NET Web page.

There are a number of interesting aspects as the talk gets closer to a real-world scenario. For example, it seems to be taking the Ruby approach of 'by convention' rather than 'by declaration'. If the Customers table had a property called address, you can create a class named Customers and add a GetAddress method. When the data classes are generated at runtime, a call to the GetAddress method will be used in the property getter for Address. This is how override certain functionality can be achieved.

All in all, there are some interesting possibilities that could arise from this. If you want to play with what is there right now, check out

WPF Found a Home!

The more I see about Silverlight, both 1.0 and 1.1, the more I realize that WPF has found a client to service. From the moment I heard about XAML and WPF, I questioned where it was going to fit in the real world. A large part of the 'coolness' of XAML revolved about transitions and transformations. But business applications don't really need that. Business applications are, generally speaking, not flashy, demo-candy-ful systems. So this disconnect between the needs of business and the strengths of XAML left me wondering.

While I don't believe that WPF is going to replace Windows Forms anytime in the near future, I think that it's pretty obvious that the raison d'etre of XAML is to support Silverlight.

But it's important for developers to realize that XAML/WPF/Silverlight is sill new technology. The one thing I haven't seen here at MIX is an integrated development environment. Orcas doesn't have a XAML has a link to edit the XAML in Expression Blend. The data binding story in XAML is a step back from what ASP.NET developers gained in .NET 2.0. Jasper and Astoria are interesting technologies, but the security and error management stories are still being developed. In other words, temper the excitement of some very, very slick technology with the realization that we still have a little time before it becomes 'real'

Drilling Down on the Silverlight Hype

First off, I do think that Silverlight is a very cool piece of technology. Want to see just how astounding? Check out the Top Banana demo application that was part of yesterday's MIX keynote. You can also find it here.

What I found most astounding is that Top Banana is a browser-based application with cross-browser support.

Silverlight is also touting that it allows .NET to run on the various browsers. Which it will do at version 1.1. Keep that in mind. The Silverlight that was released as a beta version yesterday (albeit with a "Go Live" license) does not have .NET support. Programming against the object model is done using JavaScript. The version that contains .NET support was released as an alpha version without the Go Live license. In other words, the cross-platform .NET support is only available as a preview.

Not that it won't be cool when it becomes 'real', but keep that in mind when you're looking at the various demos. Remember to ask which version was used to put the demo together.

Expression Web

I just sat through a session on Expression Web. They were showing some of the functionality that was currently being used, along with some of the plans for the next version. There are a couple of points that I'd like to make clear that came out of the session.

  • Expression Web fills the same space as Visual Studio. They are targeted to different audiences, naturally (Expression Web is aiming at designer-type people), but they are both development environments. They even work on the same project structure, although Expression Web is incapable of modifying the code behind files.
  • Expression Web does not currently have any support for Team Foundation Server. My first thought was 'ewwww'. But (and this is a killer but) you can only modify the Web pieces of the application. No code behind can be touched. While I'm not thrilled with not having integration, I'm more willing to relax it for the Web content.
  • They are currently thinking about whether to include TFS support in xWeb (the cutesy name for Expression Web) in the next version. If you want to influence their decision, send them a message through

I'm looking forward to playing with the elements of Expression Web to see what kind of trouble I can get into. :) If you want the same opportunity, you can download a trial version from

Computer Canada Feature Article on Employees as Assets

The April 20th edition of Computer Canada had a feature article on (generally) the asset value that employees bring to a company. I mention this because, as it turns out, I'm quoted in the article. I believe that documentation is not the solution to the knowledge leakage problem discussed in the article. Developers don't like documentation, so the trick is to keep code clean and easy to read. Standards are important. Unit tests are important (they document the assumptions made by the developer). Enforcing both standards and appropriate levels of unit testing would, quite naturally, be even more important.

This combination is a significant benefit (albeit a soft one) that a company can accrue by using tools such as Team Foundation Server. Imposing process on software development efforts can be challenging, however. The metaphor that a development team is like a herd of cats is frequently quite accurate. Getting them to buy into the process is very important to it's success. But a well planned implementation that takes into consideration appropriate levels of training along with a process that mirrors the current situation can greatly help a company achieve it's goal with respect to securing application knowledge.

Getting your hands on Expression Studio

If you're an MSDN subscriber, you might be wondering what parts you can get hold of without purchase the product. Expression Studio is made up of: Expression Web, Expression Blend, Expression Design and Expression Media. From a developer's perspective, it is really Expression Web and Expression Blend that are of greatest interest. You might be able to make the case for including Design in this list, but personally (since I was born without the graphics gene), I wouldn't

Microsoft has thankfully included the two pieces (Web and Blend) into the MSDN Premium subscription. Expression Web can already be downloaded. Expression Blend will be available in the very near future. See Soma's announcement (from earlier this month) here.