Windows Vista Beta 1 now available
Windows Vista (Longhorn) Beta 1 is now available at MSDN subscriber downloads. Go get it while it’s hot.
IDE Font
Via the Resharper newsgroups, I just found my new favorite IDE font. Bitstream Vera Sans Mono (available at http://www.gnome.org/fonts/).
The font reminds me slightly of Courier New, but has some of the nicer rounded lines of Lucida Console. It’s worth checking out… I really enjoy it. :)
A great way to get on people’s nerves
At our local Albertson’s, we now have the capability to do a self-checkout. This works *really* well, when you have a handful of items and dont want to wait in line behind the people that have completely full grocery carts.
How should these best be utilized? Fill your cart completely full. Preferably with items that dont have a barcode so you have to engage the clerk every 15 seconds or so to help you. Then let your kids run rampant through the checkout area. Surely the checkers cant get you rung up any faster, so you might as well do it yourself. Meanwhile, look back at the people waiting in line with 1 or 2 items and apologize to them that the system isnt working properly. Again, of course its the systems fault.
At this point, Im so fed up waiting in line behind these morons that I just went through the line with the checker. Interestingly enough, I was out the door quicker. :)
Some news over the last few days
Surely by now everyone has heard that Windows “Longhorn” is no more. The official name is Windows Vista. Seriously, could Microsoft have come up with a goofier name? Whatever… The official announcement is here.
Want to try out Team Systems, but dont have the hardware or time to spend getting it up and running and configured? How about the VS 2005 Team System Beta 2 Virtual PC image? We had heard hints about this at VSLive! and it is now a reality on MSDN downloads. :)
The image contains:
- Microsoft Windows Server 2003 Standard Edition (expires September 16, 2006)
- Microsoft Visual Studio 2005 Team Suite Beta 2 (expires May 1, 2006)
- Microsoft Visual Studio 2005 Team Foundation Server Beta 2
- Microsoft .NET Framework 2.0 Redistributable Package Beta 2
- Microsoft SQL Server 2005 Community Technology Preview
- Microsoft Office 2003 Standard Edition
- Microsoft Live Communication Server 2003
Lastly, looks like the Resharper 2.0 EAP went live. Among some of the cool new features are a built in unit test runner. I need to see how well this works… keep in mind that this is an EAP and as such, might really hose things up.
Building Service Layer Recommendations
I’m currently working on a project that’s goal will be to provide direction to our team as to what technology we want to use to create a service layer for our applications.
I’ve picked up Christian Nagel’s book (detailed in a previous post), and have become fairly familiar with Enterprise Services (I think).
The thing that Im having the toughest time with right now is that when I use .NET remoting or DCOM as the transport, I *have* to have the runtime on the client. Meaning, if I developed my service using .NET 1.1, I *have* to have .NET 1.1 on the client (even if Whidbey is there). The same goes for a service developed with Whidbey… I have to have Whidbey on the client. I feel that a service should be sitting out there that any client can use and this dependency on runtime seems to go against that.
Using web services seems to get me around this, but the problem I have with web services is that I dont get the rich object model that I do with remoting or DCOM.
Is it even a good idea to have a service layer that is pure ASMX (on an intranet), even if the services are inter-dependant? For example, lets say I have ServiceA, ServiceB and ServiceC and they are implemented as .NET web services. Is this still a good architecture if ServiceA needs to talk to ServiceC to retrieve some piece of data?
Am I just missing something obvious here? Any ideas, or even pointers to content that discusses service layer implementations would be appreciated.
Strange error when using COM+ applications
I was working on integrating a COM+ application (service) into my .NET application. The goal was to have this service layer on a different machine and the calling application would use the service over DCOM.
This seemed to be pretty straightforward, but I kept coming up against this very strange error that said, “The component or application containing the component has been disabled”.
I scoured the Windows 2003 Component Services Explorer looking for a way to enable my application and/or component, however there was no luck. Finally, I stumbled across the answer which is that the server had been misconfigured.
With Windows 2003, you have to manually enable Network COM+ Access. You can do this with Add/Remove Programs | Add/Remove Windows Components | Application Server | Details | Enable Network COM+ Access.
This was a pretty maddening error to get past and hopefully this helps someone else out.
On another note, I did recently pick up Christian Nagel’s book entitled Enterprise Services with the .NET Framework. What I’ve read so far is very educational, and this books seems to be a real winner. Great work, Christian.
A WTF moment
Stumbled across this chunk of code while tracking down a bug… Although this had nothing to do with the bug, it did leave my scratching my head saying WTF… Variable names have been changed to protect the guilty… :)
private int SOME_CONSTANT = System.Convert.ToInt32("1", 16); // ED: numerous similar lines snipped. private int SOME_OTHER_CONSTANT = System.Convert.ToInt32("200000", 16);
These are supposed to be constants that are being passed in as XOR’d options to an external program. The first thing that you can see going on is that they are not constants (note the lack of a const keyword).
You cant use the const keyword with an expression that is not a compile time constant (ie: the Convert.ToInt32 method). This leads me to my second point… Why arent we using hex codes to define these and save the initialization? Everytime the class gets instantiated all of these expressions need to be evaluated.
private const int SOME_CONSTANT = 0x80;
Once you do this, you can get the const keyword, because 0×80 is a compile time constant. Also, you save the reinitialization of these values everytime the class gets instantiated.
A flexible plugin loader
Ever added plugin capabilities to your application? Are you tired of writing the same discovery and loading code over and over? I am too, and came up with this fun little class:
class PluginLoader { public static ConstructorInfo[] FindPlugins(Type pluginType) { ArrayList list = new ArrayList(); foreach (string file in Directory.GetFiles(Environment.CurrentDirectory, "*.dll")) { try { FileInfo fileInfo = new FileInfo(file); string assemblyPath = fileInfo.Name.Replace(fileInfo.Extension, ""); Assembly asm = AppDomain.CurrentDomain.Load(assemblyPath); foreach (Type t in asm.GetExportedTypes()) { if (pluginType.IsAssignableFrom(t)) { ConstructorInfo ctor = t.GetConstructor(Type.EmptyTypes); if (ctor != null) { list.Add(ctor); } } } } catch (Exception e) { Trace.WriteLine("Exception encountered loading plugin: " + e.ToString()); // this is deliberately ignored, as any error in loading the assembly should just involve // continuing on } } return (ConstructorInfo[])list.ToArray(typeof(ConstructorInfo)); } }
Wherever you want to get a list of available plugins, use PluginLoader.FindPlugins(typeof(YourPluginType));. The method returns an array of ConstructorInfo objects so you will be responsible for instantiating the objects yourself. This is the heavy part of the reflection though, so its only done once and you can instantiate when you need the plugin.
One thing I would probably like to do is to get the discovery mechanism happening in a secondary appdomain. This will help by keeping assemblies unloaded until they are actually used by the application.


