Beta 2 of Visual Studio .NET 2005 has introduced a problem that prevents CodeRush from showing its menu entries. A workaround for the Options dialog has been published, which involves binding the command to call the dialog to a keyboard shortcut. One thing that’s not that easy to do is showing the CodeRush tool windows, like the CodeRush Guide, the Messages window, or the tool windows of 3rd party plugins like the CodeRush Documentor. To work around this, I have created a plugin called CR_OpenToolWindow. Here’s the download link for version 1.0: CR_OpenToolWindow-1.0.zip.
To install, just unzip and drop the file into the DXCore Plugin directory, which by default is at
C:\Program Files\Developer Express Inc\DXCore for Visual Studio .NET\1.1\Bin\Plugins. To use the plugin, you can bind one or more keyboard shortcuts to the two commands it exposes. The first command is called ShowToolWindows (I have bound this to Ctrl + Shift + Alt + T) and shows the following dialog:
You can find their original announcement here and this link at Microsoft tells you much more about Refactor! itself. With the availability of new C# refactoring functionality in VS.NET 2005, Microsoft seem to have noticed the lack of similar functionality for Visual Basic developers. That’s why a cooperation was struck up with Developer Express for them to offer their fantastic DXCore-based refactoring product in a free version to VB.NET 2005 developers.
There’s lots of additional information on Refactor! available at the Developer Express website, also about the Professional version (which also works with C#, very recommended!) and the companion (parent?) product CodeRush for VS.NET. A white paper has been made available about Refactoring in Visual Basic .NET 2005 that’s really worth a read.
In a previous article, I showed how nullable types, as implemented in version 2 of the .NET framework, can be persisted using XPO. But what if .NET 2.0 is not yet an option? .NET 1.1 doesn’t have support for nullable types and there’s no such feature in XPO, either. If somebody comes from the database world, it’s certainly understandable that types that can also be null are something he’s accustomed to. On the other hand, XPO is about persisting objects, and in that world, no ordinary value types have ever been able to have the value null. Anyhow, I do think it’s a nice feature to be able to set ints to null, certainly so when persistence to databases is considered.
So, I’ve created a nullable type together with, once again, a value converter, that allows to use nullable value types in .NET 1.1. Here’s the code for a base class and the
The current version of Developer Express XPO has a Session object that handles one connection to the database together with an object cache for that session. Technically, the Session is a pivotal point in the XPO architecture, all object handling requests go through a Session object. Recently it came to my attention that some people regard it as a great problem that the Session object is tightly bound to a database connection. By default, this is a direct association: you can create more than one session object in an application, which will result in more than one database connection. If there are many clients, implemented with XPO, accessing a central database, there’ll be as many database connections as there are clients. Not necessarily a completely unusual situation, and in the domain of client/server and multi tier applications, respectively, there are numerous ways to implement things differently, if needed.
Personally, I tend to prefer application server designs these days, where things obviously scale differently in this regard. The real problem is most clearly visible when thinking about ASP.NET applications. To make XPO data available to an ASP.NET application, there are three general approaches, as detailed nicely in this article from the XPO online help:
I’ve been using Developer Express components with VS.NET 2005 (beta 1) for a while, but nearly always in forms that I had previously created with VS.NET 2003. Now, suddenly some problems showed up when these old forms were edited, specifically with XtraGrids and XtraEditors on them. These problems were quite severe, as the VS designer would simply refrain from persisting all properties that are stored in “inner objects” of the main component.
This concept is used all over the DX libraries, for example for the Properties property in the XtraEditors library and the Styles and Views properties of the GridControl. A single modification in the designer would trigger recreation of the InitializeComponent method, thereby effectively destroying the form. The funny (and good) thing about this is that I found the necessary modifications in the source code files already. As far as I know, DX distribute compiled versions for VS.NET 2005 to the customers that need them, and I guess these versions are actually compiled with the modifications enabled. Using the standard distribution, on the other hand, these modifications are not active by default!