July 2005 Entries

API Design

posted @ Sunday, July 31, 2005 7:40 PM | Feedback (0)

 

Just wanted to note something that caught my eye the other day. According to Improving .NET Application Performance and Scalability, part of the Patterns and Practices series, exceptions should not be used to control regular application flow. I noticed that the comments as part of the PrincipalPermission.Demand method, the method itself returns void, however the mechanism you use to determine success or failure is whether or not it threw a SecurityException. Hmmm, why not just return a bool instead? I wonder if this will change in the future? Does this bother anyone else?

Assembly Probing

posted @ Friday, July 29, 2005 11:44 AM | Feedback (0)

 

As some of you are aware, I have been working on a UITypeEditor for a custom designer in Enterprise Library. This designer will support Inversion of Control (IoC) Containers for Enterprise Library. Part of the UITypeEditor allows selecting of an assembly and class, be it installed in the GAC or a private assembly. I was running into an issue when I would load a private assembly and attempt to get it collection of types. I was using the static Assembly.LoadFrom method which worked well, except when I called GetTypes(), a ReflectionTypeLoadException exception was thrown. ReflectionTypeLoadException contains a property called LoaderExceptions, which contains a collection of exceptions thrown by the class loader. Each one of these exceptions pointed to another assembly that my main assembly referenced as a dependency.

The problem was these assemblies were all within the same directory as the loaded assembly. According to the probing rules defined within MSDN, based on the directory path provided by the loaded assembly, this is provided as a hint to the location of the referenced assemblies. Unfortunately, this was not working. The solution I found was a method called AppendPrivatePath, which is a method of an AppDomain to tell the assembly resolver where to probe for private assemblies.

2005 MVP Global Summit

posted @ Friday, July 15, 2005 8:23 PM | Feedback (0)

 

The 2005 MVP Global Summit will be here before we know it, I just registered today. The event is scheduled to take place in Seattle, WA from September 28 through October 1st. It should be a great chance to meet the product teams as well as fellow MVP's. I will be staying at the W Seattle while I am there. Drop me a line if you are going as well.

Language Shops

posted @ Wednesday, July 13, 2005 1:44 AM | Feedback (0)

 

Language shops, we've all heard of them, this company only writes applications in language X, Y or Z, maybe you even work for one. Typically the language of choice has a large following, be it VB, C++ or Java. The reasoning behind this is purely financial, usually. With a large following it is much easier to locate developers, typically at lower rates, especially if the market is saturated with developers of language X, Y, or Z. I completely agree with Matt in that, if you hire people that are smart enough to learn a new technology, you don't necessarily have to worry as much about hiring people that already know a specific technology. That said, I still don't think I will be seeing an insurance application written on Ruby anytime soon. Not that I am against it, but it would be rather presumptuous to assume you can convince a company to make a language change purely based on the “fact” that it's a “better” language, without the company considering the learning curve required for all of their existing employees and the price of hiring development staff in the future to support that language. While actions like this continue to occur, sites like Orbitz and Yahoo! Store are written in Lisp - interesting. What do you think?

Composite UI Application Block

posted @ Friday, July 01, 2005 12:39 AM | Feedback (0)

 

The group behind the Composite UI Application Block (CAB) just released a community technical preview. CAB is based on .NET 2.0 and its purpose is to allow abstract complex UI design for smart clients. If you would rather spend time working on the business specific components of your application rather than getting caught up with threading and asynchronous requests you should check this out.