constructive nonconformist

Apple Mighty Mouse TLC

The Apple Mighty Mouse is maligned by many but I rather like it. I actually replaced one when the track ball stopped working correctly.

Recently the track ball of a Mighty Mouse for another machine stopped scrolling down. The track ball would turn but the window wouldn’t scroll.

Apple’s instructions for cleaning the track ball weren’t effective. But in the Apple Support Discussion Forums in the topic thread “Solution to Dirty Trackball on Mighty Mouse — NO DISASSEMBLY REQUIRED!” is the suggestion to turn the mouse upside down and run the track ball firmly against a clean sheet of white paper. I tried it. There were only a few miniscule flecks of crud that showed up on the paper. But it did the trick. The track ball was restored to full operation.

So with one success, I retrieved the older replaced mouse from the bottom of the wastebasket. This being my home ‘office’ most of the trash is paper and ends up in the recycle bin (sometimes by way of the shredder) and not in the wastebasket. And the wastebasket being under-used and my ‘office’ space being less than spacious, the wastebasket is in an awkward place way under the desk. Which is why a dead mouse would still be in the wastebasket months after being replaced. (Well, that and I’m a bit of a pack-rat.)

I tried the paper technique. A long curlicue of dust-crud emerged from the track ball. The ‘dead’ mouse was resurrected. Thank you LukeAP88.

Hacking SLN Files to Improve Visual Studio/Visual Source Safe Integration

There are some who think Microsoft Visual Source Safe (VSS) is great. There are some who think that it’s not great but it is pretty good. And there are some who think Source Safe is just good enough. I am not among any of those groups.

One pain point with Source Safe in a Microsoft tool chain is integration with Visual Studio. Historically Visual Studio has stored source control information directly in the solution and project files. This reveals itself to be a really terrible idea the first time a project or solution file is shared in Source Safe. Checkouts from within the IDE will use the the source control bindings in the solution or project. If the solution or project file has been shared and not changed the bindings will be pointing to the original location in Source Safe. Checking out through Visual Studio will checkout the wrong file.

Yes, the solution and project files can be branched and the bindings updated. That’s sub-optimal. It means branching just to fix a tool problem and not because of any actual divergence in the code base. Any non-divergent changes to the solution or project must then be manually propagated to all the branched versions. Ugh.

The problem has not gone unnoticed at Microsoft. Over time and new releases of VStudio and VSS, improvements have been made.

My current position of employment is not using the latest and greatest. We’re on Visual Studio 2005 and Visual Source Safe 2005. The code base is in C#. I worked out a way to have shared solution and project files for non-web projects. Web projects in 2005 are different beasts and don’t follow the same rules. If you are using different versions of Visual Studio or Visual Source Safe your mileage will vary.

When getting files from VSS into a working directory, Visual Source Safe 2005 will create or update a mssccprj.scc file if any of the files present include a solution (.sln) or project file (for C#, .csproj). The mssccprj.scc file is a text file and it will contain the VSS bindings for the solution and project files that are in the same directory as the mssccprj.scc file.

In Visual Studio 2005, project files by default use the special ‘SAK’ string in the project file settings for VSS bindings. SAK indicates to Visual Studio that the bindings in the mssccprj.scc file should be used. The mssccprj.scc bindings are based on the directory retrieved from Source Safe. This means that shared project files just work. Yay.

In 2005 the problem is with solution files.

More specifically the problem is with solution files that include project files that are not in the same directory as the solution file. Creating a MyHelloWorld project will create a MyHelloWorld.sln and a MyHelloWorld.csproj in a MyHelloWorld directory. The .sln will reference the .csproj by name only and both files will have bindings in the mssccprj.scc file in the same directory and that all works without issue. But create a blank solution and add multiple existing projects to it and Visual Studio 2005 reverts to storing specific VSS bindings for the projects in the solution file.

There’s a work-around but it doesn’t work for parenting paths. Any time a solution references a project where the path to the project file starts with ‘..’, Visual Studio will revert to storing a VSS binding in the solution file. Because of this limitation it becomes convenient to have a convention that solution files generally go in the root of the code base tree.

The goal is to get the VSS bindings out of the solution file and have Visual Studio rely on the mssccprj.scc file. I haven’t found a reliable way to do this from within the IDE with existing projects but the solution (.sln) files are just text files, so I hack them.

Here’s a snippet from a .sln file. In Source Safe, the solution file is in “$/CodeBase v1”. There are two projects: a class library and a windows application. The SccProjectName<N> values are bindings to specific locations in the source safe repository. These are the bindings that need to be removed.

Global
	GlobalSection(SourceCodeControl) = preSolution
		SccNumberOfProjects = 3
		SccLocalPath0 = .
		SccProjectUniqueName1 = ClassLibrary1\\ClassLibrary1.csproj
		SccProjectName1 = \u0022$/CodeBase\u0020v1/ClassLibrary1\u0022,\u0020TAAAAAAA
		SccLocalPath1 = ClassLibrary1
		SccProjectUniqueName2 = WindowsApplication1\\WindowsApplication1.csproj
		SccProjectName2 = \u0022$/CodeBase\u0020v1/WindowsApplication1\u0022,\u0020WAAAAAAA
		SccLocalPath2 = WindowsApplication1
	EndGlobalSection

The .sln file can be edited to remove the SccProjectName<N> values but the SccLocalPath<N> must be updated to ‘.’ and a new property, SccProjectFilePathRelativizedFromConnection<N>, must be added with the old local path value and an appended directory separator.

Global
	GlobalSection(SourceCodeControl) = preSolution
		SccNumberOfProjects = 3
		SccLocalPath0 = .
		SccProjectUniqueName1 = ClassLibrary1\\ClassLibrary1.csproj
		SccLocalPath1 = .
		SccProjectFilePathRelativizedFromConnection1 = ClassLibrary1\\
		SccProjectUniqueName2 = WindowsApplication1\\WindowsApplication1.csproj
		SccLocalPath2 = .
		SccProjectFilePathRelativizedFromConnection2 = WindowsApplication1\\
	EndGlobalSection

Reference: Alin Constantin’s blog: The SAK source control strings in Visual Studio’s project files

Installing Git

This is a ‘note to self’ about Git and how to build and install on Mac OS X and how to install on Windows.

Building and Installing Git on Mac OS X (specifically 10.5 Leopard)

I haven’t been won over by Fink or MacPorts. There is the git-osx-installer project on Google Code which provides a DMG. But I’m comfortable with Makefiles and I have the Developer tools installed, so I build and install from the source.

Here are the steps I follow:

1. Get the ‘latest stable GIT release’ from http://git-scm.com/. As of this post the latest stable Git release was v1.6.1. Get the tar.bz2¹ file, for example: git-1.6.1.tar.bz2.
2. Unpack the tar file. I have a ~/Projects directory. In the Finder I typically move the tar file to ~/Projects and then double-click the tar. The Mac OS X 10.5 Archive Utility will handle the file. git-1.6.1.tar.bz2 will be unpacked into a directory named git-1.6.1.
   
   From the command line the tar command would be something like:
   tar xjf git-1.6.1.tar.bz2
3. I want to install Git to /usr/local. I also want to be able to easily mange new Git installs and Git has lots of parts so I create a subdirectory for Git in /usr/local.
   1. Create a directory in /usr/local for the Git release, for example:
      sudo mkdir /usr/local/git-1.6.1
   2. Create a subdirectory for the Git release man pages, for example:
      sudo mkdir /usr/local/git-1.6.1/man
   3. If this is the first install of Git on the machine, create a symbolic link to the release directory:
      sudo ln -s /usr/local/git-1.6.1 /usr/local/git
      
      Going forward, /usr/local/git should always link to the release you currently want to use.
   4. Add /usr/local/git/bin to your PATH.
   5. Add /usr/local/git/man to your MANPATH.
   
   
4. Change directory into the unpacked source code, for example:
   cd ~/Project/git-1.6.1
5. Configure the build. Set the prefix to the directory the release should be installed into. For example:
   make configure
./configure --prefix=/usr/local/git-1.6.1
6. Build Git.
   make
7. Install Git.
   sudo make install
8. Don’t bother building the man pages. Get the matching man pages tar from http://kernel.org/pub/software/scm/git/.
   

   For example: git-manpages-1.6.1.tar.bz2.
   

   From the command line, unpack the tar into the install location, for example:
   sudo tar xjf git-manpages-1.6.1.tar.bz2 -C /usr/local/git-1.6.1/man

9. If needed, update the /usr/local/git symbolic link.

Resources for Git on Mac OS X:

Hivelogic - Installing Git on Snow Leopard
Compiling and installing git on Mac OS X - Guides - GitHub
Compiling Git for Mac OS X Leopard (10.5)
A Funkaoshi Production :: Building Git on Mac OS X

Windows

I don’t build from scratch on Windows. I’m currently trying out the msysgit package from Google Code.

¹The bzip2 compression is more efficient than the older gzip compression.

Note To Self

I added a new category to the blog: Note To Self. It’s for ‘outboard brain’ type postings.

Mac OS X: Setting Environment Variables for User Processes

Link: Technical Q&A QA1067: Setting environment variables for user processes.

Open a Command Shell from the Windows Explorer

It’s hugely convenient to be able to pop open a command shell (aka “Command Prompt”) in a given directory from the Windows Explorer. The Registry can be manually edited to add context menu commands and there is a Microsoft Knowledge Base article that describes one such approach but the PowerToys collection includes an “Open Command Window Here” item that’s a little more complete. The PowerToy adds shell commands for directories and drives.

Link: How to start a command prompt in a folder in Windows Server 2003, Windows XP, and Windows 2000.

Link: Microsoft PowerToys for Windows XP.

Apparently Vista includes an “Open Command Window Here” command but only on a Shift-Right-Click in the Explorer’s right hand pane.

Incidentally I always need to change the factory defaults for the Command Prompt. I have no great sentiment for monochrome displays and can’t see any sense to using white characters on a black background. I also change the font from ‘Raster’ to ‘Lucida Console’, enable ‘Quick Edit Mode’, increase the command history, increase the height of the screen buffer, and increase the height of the window.

Quickly Generating a Microsoft Connection String

From the backup brain department:

When I need a connection string or a DSN, a UDL file is a handy way to quickly and accurately generate it. But I can never remember the UDL file extension when I need it.

Link: Creating and Configuring Universal Data Link (.udl) Files.

JAVA_HOME on Mac OS X

JAVA_HOME is an environment variable used to locate the root of the Java installation.

Java is integrated into Mac OS X and Mac OS X releases starting with Panther (10.3) have supported multiple major versions of Java. Tiger (10.4), the current release, supports Java 1.3, 1.4, and 1.5.

Mac OS X has its own unique variation on a standard UNIX directory structure and there are sym-links galore to support the multiple versions of Java. This has created some confusion.

I have seen articles suggesting setting JAVA_HOME to /usr. $JAVA_HOME/bin then points to /usr/bin and /usr/bin contains sym-links for jar, java, javac, and others. But this suggestion fails for anything else that can be expected to reside in JAVA_HOME — like lib, include, docs, and even some tools that might be expected in bin.

The correct value for JAVA_HOME on Mac OS X Tiger is /Library/Java/Home.

For sh/bash/ksh add the following line to ~/.profile or /etc/profile:

export JAVA_HOME=/Library/Java/Home


For csh/tcsh add the following line to ~/.cshrc or /etc/csh.cshrc:

setenv JAVA_HOME /Library/Java/Home


For Aqua applications add JAVA_HOME to ~/.MacOSX/environment.plist.

Update Feb 22 2006:

The correct value for ANT_HOME on Mac OS X Tiger is /Developer/Java/Ant.