I have a Lenovo/IBM ThinkPad T60 at work with a docking station. For the longest time, I’d get this error when trying to undock:

You cannot eject your computer because one of the devices in the docking station, “Printer Port (LPT1),” cannot be stopped because a program is still accessing it.

For the life of me, I couldn’t figure out what the problem was. I don’t have any printers hooked up, I hadn’t printed anything, I couldn’t find anything that was using the port.

There’s a KB article on it, and I found forum posts about it, but no real solutions. The way I solved it:

In the BIOS at boot time, there is an option for disallowing access to the printer port from the docking station. I set that. (There is an option to disable the printer port entirely, but I didn’t need to do that - I just needed to stop the docking station from accessing it.) A quick save and reboot, and I’m ready to eject from the docking station at any time - no more error.

Note that I don’t have any printers locally attached to my machine, so disabling the printer port connection to the docking station didn’t hurt me. If you have a local printer attached to your docking station, this may not be the best solution for you.

UPDATE: I am on ThinkPad T60 BIOS version 2.21 and the option is under Config -> Docking Station. Set the “Legacy Devices on Mini Dock” setting to “Disabled” to disallow the docking station access to the parallel port.

I’m not sure what to make of this, but it’s from Joss Whedon and stars Neil Patrick Harris and Nathan Fillion, so that’s really all I need to know. I’m in.

They finally released a tool on xbox.com that allows you to transfer your downloadable content licenses from one console to another. This is huge. I used to have to wait months (yes, plural) to get this to happen after repair, and people who bought new consoles (upgrade to Elite?) were out-and-out hosed.

That said, there are some important points they blog about on the Gamerscore Blog and there’s a FAQ about the tool. The two big points for me:

• When you get your console repaired by Microsoft, they’ll do this for you so you won’t need to do it yourself. That’s important because…
• You can only do this one time every 365 days.

Apparently this will work with all content but movies because movies aren’t “download-to-own.” I don’t rent movies over Xbox Live, so I’m not too concerned here.

The last time I got my console repaired, which was about a month ago, they did not automatically transfer the licenses even though they said they would. I called Xbox Live Support and it took about a week for them to do the transfer (as opposed to the months it previously took). I’m gathering that if I get another repair and need the licenses transferred, this won’t be the avenue I’m supposed to take - I’ll still need to call them. This is more for folks getting new consoles or getting repairs from non-Microsoft facilities. That said, now that we know there’s a tool, maybe they can do the transfer right there while I’m on the phone rather than waiting a week.

I finally got around to putting a new picture as the home screen image on my new BlackBerry Curve. The problem - every time I synchronized against the BlackBerry Desktop Manager software, my home screen image would get reset to the default for the theme. I’d go set it again, sync up, and watch my wallpaper disappear. The image file was still there, it just wasn’t my wallpaper anymore.

The answer: Store any picture you want as your home screen image on the device memory, not on a media card. If you store the image on the media card, it’ll get reset when you sync. If you store it on the device memory, it’s stays persistent the way you’d expect.

When you’re integrating FxCop into your build using MSBuild, you have three basic options.

1. Build a static project file that contains all of the FxCop settings for your solution and run the command line client against that.
2. Skip the project file entirely and run the command-line client alone, specifying all of the options on the command line.
3. Build a partial project file that contains things that don’t change regularly (like the list of rules you want to run) and tell the FxCop command line client to use that as well as some dynamic properties you specify on the command line.

Usually you end up with option 3 - a partial project file and dynamic properties on the command line. The problem is that command lines have a maximum length limitation and once you get into Very Large Projects, there may be dozens of folders that FxCop needs to search for assembly dependencies as well as several places you need to point FxCop to so it can find the assemblies you want to analyze. Those are things you normally specify on the command line… but in that Very Large Project scenario, you hit the command line length limit pretty quick.

(You might think using a custom task to run the FxCop process might fix it, but only if it doesn’t pipe the output to the command line and try to run it.)

The solution? Dynamically generate an FxCop project file with the list of your dependency folders in it. Then you don’t have to worry about any of that showing up on the command line.

• Create an empty FxCop project. Set up the rules you want to run, etc., but don’t put any target assemblies in there. Save that project and exit FxCop.
• Open the FxCop project in your favorite text editor and find the /FxCopProject/Targets node. It will be empty.
• Open that Targets node and add a block so it looks like this:

<Targets>
  <AssemblyReferenceDirectories>
  <!-- @DIRECTORIES@ -->
  </AssemblyReferenceDirectories>
</Targets>

• Save the FxCop project. We’re going to use that comment to do a replacement in the file and poke in the list of dependency folders.
• Open your MSBuild script and import the MSBuild Community Tasks. You’ll need these for the FileUpdate task.
• Just before you run FxCop, add a section to your build script that creates an item list of all of your potential dependencies. For my build, all of my third-party dependencies are in one directory tree. After that, create a copy of your FxCop project and use the FileUpdate task to poke in the list of directories. (I’ll show the code below.)
• Run FxCop using the new temporary copy of the FxCop project file that has your dynamic list of assembly reference locations. Done - no more need to worry about command line length limits, and if you keep all of your dependencies in one folder tree, you can add or remove them without having to update your FxCop project file and things will still work.

Here’s that snippet of MSBuild code to dynamically enumerate the files and poke them into the FxCop project:

<!--
     Create a temporary copy of the FxCop project.
  -->
<Copy
  SourceFiles="Build\FxCop Project.FxCop"
  DestinationFolder="$(TempDirectory)"/>

<!--
     Create an item with all of the dependencies in it. Creating multiple
     items with the same name will actually append everything into one big
     item. Here we have two folder trees with dependencies and we're
     ignoring the Subversion files.
  -->
<CreateItem
  Include="$(DependencyFolder1)\**"
  Exclude="$(DependencyFolder1)\**\_svn\**">
  <Output TaskParameter="Include" ItemName="Dependencies"/>
</CreateItem>
<CreateItem
  Include="$(DependencyFolder2)\**"
  Exclude="$(DependencyFolder2)\**\_svn\**">
  <Output TaskParameter="Include" ItemName="Dependencies"/>
</CreateItem>

<!--
     Update the temporary copy of the FxCop project with the dynamic list
     of dependencies. Using MSBuild batching, we won't get duplicates. The
     replacement expression shows we're only interested in the directories
     for the dependencies, not the dependencies themselves.
  -->
<FileUpdate
  Files="$(TempDirectory)\FxCop Project.FxCop"
  Regex="&lt;!-- @DIRECTORIES@ --&gt;"
  ReplacementText="&lt;!-- @DIRECTORIES@ --&gt;&lt;Directory&gt;%(Dependencies.RootDir)%(Dependencies.Directory)&lt;/Directory&gt;"/>

<!--
     Now we can run FxCop against the temporary copy of the FxCop project
     and not worry about specifying dependency folders.
  -->

You can apply this pattern to any list of files or folders you need to dynamically poke into files like FxCop or NDepend project files. Even if you’re not worried about the command line length limit, by dynamically generating these things you make your build more robust and require less manipulation as your project changes. Good luck!