The reason for bringing up the linked file feature in conjunction with assembly signing is that to me the feature seems particularly well-suited for linking one and only key file into multiple Visual Studio projects. Yet people seem to be unaware of the feature and so common approaches to signing is to either create a new key file for each assembly — most likely because Visual Studio makes it so easy to create a new key file from the Project Settings dialog — or signing assemblies by creating one key file and then copy/paste it to other projects in the solution.

Below is an example from the GAC showcasing how assemblies related to Pex naturally go together and are therefore signed using the same key (they share 76a274db078248c8, their public key token). The same goes for assemblies relating to other Microsoft products, such as the ones comprising a particular version of the .Net framework (because of the side-by-side execution, different versions of .Net framework assemblies are signed using different keys). So why not apply the same principle to what you deploy to the GAC?

While using the same key (copy or not) makes it possible to differentiate your assemblies from everyone else and for your four-part assembly name in web.config and spread around the code to be uniform — SharePoint developers often need to provide the four-part name for their assemblies to other parts of the solution — copying the key around is still a violation of the DRY principle and as such is indicative of a code smell. More importantly, using the link feature of Visual Studio, there’s no reason to keep the bad smell around.

Assuming you’ve already created a solution (in Visual Studio 2008) and added a project to it, the way to share a key file is to first create one by right clicking a project in Solution Explorer and selecting Properties. Now click the Signing tab and check the Sign the assembly check box. The dropdown lets you create a new key file by selecting New and filling out the information in the Create Name Key window. Alternatively, a key file is created using sn.exe, the strong name utility that comes with the Microsoft Windows SDK. On my machine, sn.exe is located in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin and is invoked like so:

    > sn -k MySharedKeyPair.snk

How the key file is created isn’t particularly relevant to the rest of this post. Just make sure to place the key file in a common location, e.g., the top-level directory holding the Visual Studio solution file. Now go to Solution Explorer, right click on your project, and select Add existing Item. Then locate the key file within the solution directory and make sure to click the arrow on the Add button and select Add as Link. Note how the file is added to the project and marked by an arrow indicating it’s a link:

Returning to the Signing tab and selecting the dropdown, it now includes the linked key file. Don’t mind the absolute path; once you select MySharedKeyPair.snk, Visual Studio converts the path to a relative one (close and reopen the Signing tab and see for yourself). Also note that if you select Browse, the key file you select is copied to the project folder and added to the project as a regular file.

Another way to associate a key file with an assembly is through the AssemblyKeyFile attribute. The attribute instructs the compiler of where to look for the key file and, although not used by the runtime, the attribute is included in the assembly along with any other attribute for everyone to see.

Using AssemblyKeyFile is probably the simplest approach to sharing a key file between projects, but now compiling the assembly results in a compiler warning as displayed above. The use of the AssemblyKeyFile attribute has been deprecated by Microsoft because it may lead to you inadvertently disclosing sensitive information through the embedded path and because working with a relative path may confuse users and the build system (the relative path is retained in the assembly, though). However, it appears AssemblyKeyFile is still the preferred way for MS to sign their assemblies. Inspecting a couple of .Net 3.5 assemblies with Reflector, here’s what their AssemblyKeyFile looks like:

    [assembly: AssemblyKeyFile(@"f:\\dd\\tools\\devdiv\\EcmaPublicKey.snk")]
    [assembly: AssemblyKeyFile(@"f:\\dd\\tools\\devdiv\\35MSSharedLib1024.snk")]
    [assembly: AssemblyKeyFile(@"f:\\dd\\tools\\devdiv\\FinalPublicKey.snk")]
    …

To come full circle, the question of how Visual Studio, or rather MSBuild, actually signs an assembly using the information provided in the Properties dialog (real file or link) remains to be answered. Since a Visual Studio project file acts as input to MSBuild, we can see what’s going on under the hood of MSBuild by invoking a compile from the command line. On my machine msbuild.exe is located in C:\Windows\Microsoft.NET\Framework\v3.5 and assuming you have a console window open with its current directory set to the directory of your project file, msbuild is invoked like so:

    > msbuild /verbosity:diagnostic > log.txt

Bring up log.txt in your favorite editor and eventually you’ll come across where csc.exe, the C# compiler, is invoked:

As you might have guessed, MSBuild carries over the location of the key file by passing the /keyfile argument to csc.exe.

The steps you have to go through are:

1. Locate vmware-vdiskmanager.exe which, on my machine, is in C:\Program Files\VMware\VMware Workstation.
2. Using the examples here together with the /? switch, the program can be invokes like:

   vmware-vdiskmanager.exe -x 15GB "path to image.vmdk"
   

   to make the new image 15 GB of size. During the enlargement process the tool creates a temporary copy the image, so you must have sufficient space on your host environment for this. Also note that this example doesn’t preallocate disk space. What this means is that although the size is logically increased to 15 GB, the image doesn’t initially grow larger on disk.

3. Now the image can contain 15 GB of data, but the guest operation system doesn’t automatically pick up the change in disk size. If you boot Windows, it’ll tell you the disk size is 10 GB, the size the disk had when Windows was installed on it. Therefore, we need to use PartitionMagic or simular tool to make Windows adjust as discribed here.

All in all the process took roughly 80 minutes on my laptop. Unfortunately, it didn’t make Visual Studio 2005 run any faster than on the W2k3 server running out of disk space. I guess the dramatic slowdown is just a necessary evil of running Visual Studio 2005 in a virtualized environment on a laptop as the development environment is not the fastest running on native hardware either.

runat.exe turned out to be quite useful when I had to do some work with MS SQL 2005 Server, Analysis Service. The thing with Analysis Service is that it’s Windows authentication only, whereas MS SQL 2005 Server supports mixed mode authentication.

My only option for getting in touch with Analysis Service was using SQL Server Management Studio by impersonating an existing Windows user, who is allowed access to Analysis Service (I didn’t have the option of creating a new account on the machine running Analysis Service and the machine wasn’t allowed to trust the domain my desktop computer was on (it’s a tough world out there)).

So, using runat.exe, I ran the command below (on one line, from a shortcut), in effect causing the display of a prompt asking for the password for my_impersonated_user. Upon entering the password sqlwb.exe starts up as if it was run from the local my_impersonated_user account.

C:\\Windows\\System32\\runas.exe /user:my_impersonated_user
"c:\\Program Files\\Microsoft SQL Server\\90\\Tools\\
Binn\\VSShell\\Common7\\IDE\\sqlwb.exe"

For the command to succeed my_impersonated_user have to be a user on the local machine with a username and password identical to the user that is allowed access to MS SQL 2005 Server/Analysis service.

Now Windows lets you logon to Analysis Service even if your local machine is on a different domain than the MS SQL 2005 Server.

What to do about those people? Force them to read up on Adam Cogan’s rules to better email, of course.

My favorite one is probably rule #2, the one about moving email from your inbox to a special folder when you’ve replied to or otherwise handled it. This way, items in your inbox can be considered a task list.

Also, #43 about not sending email immediately because you’ll often think of something you missed is a good one. Unfortunately, delayed sending isn’t supported by most public web mail providers.

Update: July 26: Inspired by David Allen’s Getting Things Done, this Inbox Zero Google Tech Talk video details a slightly different approach for managing email. Also, the Todo.txt site, co-created by Lifehacker Gina Trapani, argues that using your inbox as a todo list is a bad habit and proposes a simpler solution.

Now, how often do you crank up your playback speed?

I’ve been conducting some un-scientific experiments with increasing the playback speed with Media Player (only supports 1.5x) and my mp3-player (supports variable speed).

My conclusion is that listening to or viewing a podcast at about 1.5x the original speed is really the optimal trade-off between time consumption, not stressing the brain, and still be able to comprehend the contents.

And I save 15 minutes of every hour consuming podcasts.

Just make sure you don’t start speaking 1.5x faster because you listen to too many podcasts.

Update, August 6, 2007: Steve Pavlina describes many of the same thoughts, although he’s an advocate of a much higher speed. Steve’s blog entry mentions that “… in the latest version of Windows Media Player, click the arrow below “Now Playing.” Then click Enhancements -> Show Play Speed Settings” as a way to bring up a speed slider.

At some point in the past HEAD branched into B1, which subsequently branched into B1.1. Then development on B1 completed and it was merged back into HEAD so a release branch B2 could be created. B1.1, however, kept living its separate life for a while, because the features added aren’t to be released until with release branch B5. This also goes for the changes made to B3, so it makes sense for B1.1 to be merged into B3.

As a result, I just spend a few hours on tracking down a merge issue resulting from this merge, because a change made in B1 wasn’t present in B3 after B1.1 was merged into this branch. I finally figured out why: suppose a line is removed in B1 before the spin-off of B1.1. After that the very same line is added back in. Now when B1.1 is merged into B3, the line is removed again. There is no merge conflict at this point, because from CVS’ point of view it’s a clean merge.

It seems obvious what happened when looking at the diagram, but when you’re working with a large repository with lots of modified files and you’re merging code not written by yourself, this sort of indirect change propagation may inevitably bite you as well.

• PageDefrag
  

  PageDefrag uses advanced techniques to provide you what commercial defragmenters cannot: the ability for you to see how fragmented your page file and Registry hives are, and to defragment them. In addition, it defragments event log files and Windows 2000/XP hibernation files [...].

  Has the ability to run at the next or every boot (that’s how it gets exclusive access to the system files). Running it every time I boot typically adds 10-20 seconds to my boot time, but I guess it depends on how often you boot, the amount of physical memory, and what kind of applications you run.

• Contig
  

  Contig is a single-file defragmenter that attempts to make files contiguous on disk. It’s perfect for quickly optimizing files that are continuously becoming fragmented, or that you want to ensure are in as few fragments as possible.

  Also has a recursive switch, so you can specify C:\ as the starting point and it’ll defragment its way through your entire drive.

• ShareEnum
  

  When you run ShareEnum it uses NetBIOS enumeration to scan all the computers within the domains accessible to it, showing file and print shares and their security settings.

  A worthy replacement for Network Neighborhood, although it sometimes is not able to find any shares, although I know there’s quite a few out there.

• Autoruns
  

  This utility, which has the most comprehensive knowledge of auto-starting locations of any startup monitor, shows you what programs are configured to run during system boot or login, and shows you the entries in the order Windows processes them. These programs include ones in your startup folder, Run, RunOnce, and other Registry keys.

  On my computer, it takes longer for Windows to become responsive after log on than it takes Windows to boot and display the log on screen, because Windows loads a ton of software, fills up the systray, and starts various services I really don’t need.

  Services such as Remote Registry for accessing the registry across the network, Windows Image Acquisition for popping up a dialog box when I scan an image on the scanner I don’t have, or Windows Zero Configuration for managing the WLAN access I never use.

  Those services are all on by default and can be disabled using AutoRuns (or using Control panel => Administrative tools => Services).

• Process Explorer
  

  The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you’ll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you’ll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.

  The quote speaks for itself.

There’s a lot more tools where these came from. Among the ones I use less frequently are FileMon and Regmon for real-time monitoring of file system and registry access, respectively. Also, I use TCPView as a more user friendly replacement for the netstat command.

Finally, take a look at dnrTV, where Scott Hanselman recently showed off some of these tools.

Typically, you’d target your frustration at the debugger and insert a breakpoint around the problematic part of your code to extract the SQL and copy it into the Query Analyzer for investigation.

Unfortunately, pasting the SQL into Query Analyzer causes the statement to appear on one line entirely. You then find yourself inserting new line characters for readability and for making the error message more precise.

Transforming SQL this way is tedious, boring, and crying for automation. Fortunately, Enterprise Manager responds well to these cries. Just drill down to a table view of your database, right click on a table, and select “Open table” followed by “Query”.

Now paste your extracted SQL into the text portion of the Query by Example window and hit “Run”. Although the query might not actually execute, it’s transformed into a more readable one.

Obviously, you could start and stay in the QBE window. Personally, though, I dislike QBE as a working environtment beyond for layout beautification, so I usually copy the transformed query into Query Analyzer.

By the way, the transform also comes in handy if you want to make sure your query doesn’t contain any camouflaged expensive joins, e.g., for a query with inner joins done using where clauses, QBE transforms it into explicit inner joins.

It stalls at “Windows is loading files …”. Apparently the subsequent switch into graphics mode causes Vista to hang, because Vista all the sudden doesn’t properly support the emulated video hardware of VMWare.

That’s odd, because I previously installed Beta 2 on VMWare without any sign of trouble (could it be that MS wants people to try out RC1 on their free Virtual PC? By the way, VMWare Server is free too).

Luckily, Joel on Software provides a solution to the VMWare issue, by adding

    svga.maxWidth = "640"
    svga.maxHeight = "480"

to the configuration file for your virtual machine prior to booting the Vista DVD. It’ll force the installer to run in SVGA mode. Then when the installation is complete and you’ve installed the VMWare tools, remove the above lines and Vista shines.

My intention was to run Vista in VMWare on a secondary computer and connect to it via Remote Desktop. For some yet to be uncovered reason, however, I wasn’t able to connect from my WinXP machine. Perhaps the host OS blocked the incoming request or perhaps Vista just wasn’t properly configured.

Anyway, I decided to run Vista on the bare hardware instead, so I fired up PartitionMagic. Unfortunately some guy accidentally cut power while PartitionMagic was doing its shrink-existing-partition-to-create-space-for-an-additional-one magic. After that the existing OS chickened out and bluescreened on me, so out everything went and in Vista came.

Thus, now I utilize a two-monitor setup, running Vista on a native 2.6GHz processor with 2GB of memory on one monitor and WinXP on the other. Unfortunately, the Vista machine has a crappy video card, so no fancy, transparent UI for me (unless I find a workaround).

As a final note, I’m using Synergy to seamlessly share one mouse and keyboard between the physical machines as if it was one machine with dual head video output.

Way cool!

• Open Notepad
• Type in “this app can break” (without the quotes)
• Save file
• Close Notepad
• Re-open saved file in Notepad

Now Notepad displays funny looking foreign characters.

This is caused by a “bug” in the Win32 function IsTextUnicode, which Notepad calls to heuristically determine if a file is Unicode encoded.

For more in-depth info click here.