A new version is ready, for the download please see the plugin’s own page. These are the more important news, apart from smaller fixes:

• The whitespace hint lines are now drawn with a delay, which greatly improves the performance overhead when navigating around with the caret quickly. The delay can be configured in the options.
• New Emacs style scrolling is available. This means that scrolling starts not only when your caret is actually in the top or bottom lines of the text editor, but a few lines before that. This makes it much easier to follow the scrolling text with the eye. By default, scrolling happens in chunks instead of single lines, which also speeds up redrawing quite a bit, especially when also using Structural Highlighting. The line offset where scrolling starts as well as the size of the scroll “chunk” is configurable in the options. It’s also possible to scroll by single lines by setting the scroll percentage to 1, but still keeping the offset scrolling at the same time.
• The options have been split up to use several pages instead of only one. That concept wasn’t very extensible For restructuring reasons, you’ll have to reconfigure any settings you might have made before, sorry about that.
• I tested for compatibility with the newest versions of CodeRush (1.1.19) and Refactor! (1.0.6). I didn’t find any problems, though

I just thought I’d pass this on from Wesner Moise’s .NET Undocumented blog: Open Generic Types seem to be an undocumented feature in C# 2.0 that might be quite useful for Reflection-related work. Basically, it allows the handling of Generic types that haven’t been “closed”, i.e. it’s still unknown which other type(s) the Generic type is supposed to work with. Read it, it’s interesting!

In a previous post, I had complained about the fact that my year-old Windows system took enormously long to get up and running, and I received a few comments on that.

The past few days, triggered by a hardware issue with my old “main” hd, I took the time to reinstall the system completely. I have just finished doing that, at least to the point where I have all the must-have software up and running again, and I have had success in one area at least: the complete system boot process, including login and loading of the usual desktop accessories, takes only 2 minutes now, as opposed to 10 to 19, as was previously the case. Now I really wonder how fast that will be in a year’s time…

I’m not going to invalidate any of the arguments that were really the topic of that older post, though. I still think a programmer shouldn’t just assume that the user’s computer is used in a specific way… nor that is being rebooted regularly. And although I might be tempted to run a defragmenter a bit more often that I used to (one of the files on the old hd was allegedly composed of around 43000 fragments), I’m not planning on changing my habit of letting the system run all the time.

I just stumbled upon a funny problem related to the new .NET 2.0 attribute InternalsVisibleTo in conjunction with a strong-named assembly.

The situation is this: I have that assembly that exposes its internals to another assembly (for unit testing) using InternalsVisibleTo. Now I decided to sign that assembly with a strong name. Suddenly, I got the following error message at compile time:

Friend assembly reference ‘UnitTests’ is invalid. Strong-name signed assemblies must specify a public key token in their InternalsVisibleTo declarations.

So what to do about this? Well, first the UnitTests assembly needs to be signed with a strong name, too. Then the tricky part is using the correct string to pass to the InternalsVisibleTo attribute. Problem is, you won’t be able to compile either of the two assemblies before you get that syntax right: the UnitTests assembly doesn’t compile because it references the other assembly, which can’t be compiled because the attribute is not correctly configured.

The trick is to find out the public key token of the strong name key pair you are using to sign the UnitTests assembly. There are several ways to do that:

1. Find any other assembly in the GAC that has been signed with the same strong name and copy the public key token from the properties dialog.
2. From the command line, use the sn.exe tool to show the public key token for an assembly that’s already signed: sn.exe -T assembly.dll (note the capital T)
3. From the command line, use the sn.exe tool to show the token for a public key that you have saved in a file: sn.exe -t mykey.pub If you have your key pair together in one file, you’ll need to extract the public key into a separate file first: sn.exe -p mykey.snk mykey.pub

There are other ways, especially if you’re using a key pair stored in a container. Use the sn.exe command without parameters to get some helpful information on parameter syntax. In either case, you should end up with your public key token, which is a string representing an eight byte hexadecimal number.

The final step to get the assembly combination to compile correctly is to include the public key token in the parameter to the InternalsVisibleTo attribute in the correct syntax (use your own public key token, obviously):

	
[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("UnitTests, PublicKeyToken=123456789abcdef0")]
	

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:

The other command is called ToggleToolWindow and you need to configure it to receive a parameter. For example, to use the command to toggle the Documentor tool window and bind it to the shortcut Ctrl+Shift+Alt+D, the configuration in the CodeRush Options dialog would have to look like this:

Note the text that’s marked red: that’s the title of the tool window as shown in the window above. You can bind multiple “instances” of the command to multiple shortcuts to toggle different tool windows.

That’s it, have fun!