This whole thing started out because I was trying to get Logitech SetPoint to use the built-in Windows Aero Flip 3D task switcher rather than the built-in one (I like the Aero one better). SetPoint doesn’t have an option to use the built-in one, so I thought I might be able to use the “keystroke assignment” function. (I didn’t figure out how to get SetPoint working, but I learned a lot of other things.)

The first thing I discovered was that while Winkey + Tab brings up Flip 3D, Winkey + CTRL + Tab will bring it up and let it sit there so you don’t have to hold the keys down anymore. That’s what I wanted to do with the task switcher.

I tried to assign Winkey + CTRL + Tab to the mouse button for task switching… but it turns out you can’t assign Windows key combos to mouse buttons through SetPoint. Fine.

A little more searching and I found that you can also bring up Flip 3D in a persistent fashion by running the following:

C:\Windows\System32\rundll32.exe DwmApi #105

That got me wondering if I could have the mouse button execute an arbitrary program.

You can’t. You can only assign a keystroke.

So can you have a global shortcut key that doesn’t involve the Windows key? Turns out you can. You can create a program shortcut on your desktop (or in your Start Menu hierarchy), assign it a shortcut key, and that becomes a global shortcut.

First, create a folder in your Start Menu. I created mine at C:\Users\tillig\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Tools. (That’s on Windows Server 2008/Windows 7 – you’ll need to adjust that for your Windows version appropriately.)

Set your shortcut to execute that rundll32.exe command line I gave you earlier.

Give your shortcut a nice name like “Aero Flip3D Task Switcher.”

So now you should have a shortcut like this:

Now right-click that shortcut, select “Properties,” and on the Shortcut tab, click in the “Shortcut key” field and then press your shortcut key combination. Your shortcut key will show up in that box. Click OK to save the changes.

Now you should be able to use that new shortcut key combination to run the shortcut regardless of where you are. Nice!

Note that this order appears to be pretty important. I had to make sure the shortcut was in the Start Menu hierarchy before setting up the shortcut key or it wouldn’t work. The first time I tried it, I set the shortcut and shortcut key up in some other folder not on the desktop or in the Start Menu… and it didn’t work. If your shortcut key isn’t working, make sure you put the shortcut into the Start Menu and then set up the shortcut key.

Unfortunately, as it turns out, I still couldn’t use this to hook Logitech SetPoint up the way I wanted. I’m not sure why, but it just wouldn’t issue the key right, or maybe it wasn’t being issued the same way it does with the keyboard so Windows wasn’t handling the key.

Regardless, I learned a lot about some long-time Windows features and it looks like it could be useful in other situations. Hopefully it helps you, too.

I develop on a daily basis on a Windows Server 2008 R2 machine. I do that because that’s my target deployment environment and it’s really helpful to be able to actually run the full product and debug right there on my “workstation.” As such, I have the full “desktop experience” enabled - Aero, themes, the whole bit.

One problem I noticed was that the drop shadows under the icons on the desktop… they just don’t stick around. I set my visual effects settings to “best appearance” and everything looks correct, but if I log out and back in, the setting remains checked but there’s no drop shadow. That doesn’t sound like a big deal except… well, I have a theme on the desktop that changes background images periodically and the icons get impossible to read without that shadow.

The only way I’ve found to get the drop shadows back is to go all the way into the control panel, select “Adjust for best performance,”click “Apply,” and then select “Adjust for best appearance” and click “Apply” again. Basically, reapply the settings.

I’ve tried just modifying the registry values corresponding to these settings, but those values don’t get applied when they change. You actually have to inform the desktop engine somehow to “refresh.” I couldn’t figure out how to do that… so I went about it a different way.

UsingAutoIt v3, I wrote a little script that automates this for you: it actually opens up the dialog and does the whole re-application of the settings. In the event you’re in the same boat as me (both of you still reading), here’s the script:

#RequireAdmin
ShellExecute("sysdm.cpl")
WinWaitActive("System Properties")
ControlCommand("System Properties", "", 12320, "TabRight", "")
ControlCommand("System Properties", "", 12320, "TabRight", "")
Send("!s")
WinWaitActive("Performance Options")
Send("!p!a")
WinWaitActive("Performance Options")
Send("!b{ENTER}")
WinActivate("System Properties")
ControlClick("System Properties", "", 1)

Running that will prompt you for admin credentials if you’re not already an admin (because changing system settings requires admin privileges) and clicks all the right buttons to switch you to “best performance” and back to “best appearance.”

Visual Studio allows you to specify different code formatting rules for different languages it understands, but in many cases the formatting only applies to new code you’re writing. For example, C# lines generally get formatted when you hit the end of the line and type the semicolon… but the only line that gets formatted is the one you just completed.

Wouldn’t it be nice if the whole document would adhere to the same formatting without you having to pay attention to it?

With this plugin, you can automatically have Visual Studio apply code formatting to the entire document you’re working on when you save. That way you don’t have to think about it - your documents will always be formatted.

(You used to be able to do this in VS2008 using PowerCommands, but that doesn’t exist for VS2010 and this way you don’t need to install PowerCommands just for the one functionality.)

You also have the ability to choose which types of documents you want formatted on save:

It’s free, right now, on the DXCore Community Plugins site. Go get it!

This weekend I took Saturday from about 11:00a to 7:00p installing and configuring my new Onkyo TX-NR3007 receiver.

This replaces a Yamaha receiver I had from probably 10 years ago from The Good Guys (a now-defunct consumer electronics store that used to be everywhere locally). The primary driver for the upgrade is that I have a Bose Acoustimass 16 speaker kit that will support 6.1 surround, but the Yamaha receiver only has 5.1 outputs… so there’s a speaker that’s been sitting idle in a cabinet for a few years, yearning to break free. This Onkyo supports 9.2 surround, so plenty of room to upgrade.

I compared several options before settling on this particular receiver. My initial criteria:

• Between $750 and $2000.
• At least four HDMI inputs.
• At least 6.1 surround support.

I started looking at models from Denon, Onkyo, Yamaha, and Pioneer, but quickly came down to Denon vs. Onkyo. From there, I compared:

• Denon AVR-2310CI
• Denon AVR-3310CI
• Denon AVR-4310CI
• Denon AVR-4810CI
• Onkyo TX-NR807
• Onkyo TX-NR1007
• Onkyo TX-NR3007
• Onkyo TX-NR5007

All of those have at least 5 HDMI inputs and 7.1 surround, and all are in the price range.

I ruled out the AVR-2310CI based on the fact it was the only one that didn’t have network connectivity and all the others did - I have a lot of music on my Windows Home Server and I want to have access to it if possible. I ruled out the TX-NR807 based on the very few component inputs, lack of discrete channel inputs, and no USB port. So the lower-end items in the list got ruled out.

I then started looking at the expandability of the speakers and ruled out the AVR-3310CI and AVR-4310CI. Both of those are 7.1 outputs while the remaining Onkyo units have 9.2 surround and the AVR-4810CI has 9.3.

After that, it was a bang-for-the-buck comparison. The remaining contenders price out like this (roughly):

• Denon AVR-4810CI: $3000
• Onkyo TX-NR1007: $1200
• Onkyo TX-NR3007: $1500
• Onkyo TX-NR5007: $1900

Again, that’s rough pricing - you can find sales and such that’ll save you a couple hundred, give or take, but that’s around the average price I saw.

The Denon, then, was well beyond the pricing of the Onkyos. Like, double. I can’t justify that much price difference, especially given my original budget constraints, even if the brand is potentially more reliable.

Of the remaining Onkyos, I went middle-of-the-road. The TX-NR3007 has a USB flash drive port, which the 1007 does not, and has one more HDMI input than the 1007, for a total of seven HDMI inputs. The TX-NR3007 has one fewer HDMI input and one fewer optical audio input than the 5007, and the 3007 has a 24-bit DAC while the 5007 has a 32-bit DAC… but I couldn’t justify the additional price for those features.

So: the Onkyo TX-NR3007. I got a screamin’ deal on it through some friends (big thanks to them) which got me the receiver and the three-year warranty for $1400. (Yes, I got the warranty. I’ve had the warranty save me on electronics purchases twice now, so pretty much anything over $750 I’ll consider getting it. Did you know that geomagnetic forces affect large-tube TVs?)

Anyway, thanks to Alex Scoble for helping me figure some of the receiver stuff out. That guy is an A/V king.

Since I was able to use HDMI to connect audio and video at the same time (my old Yamaha receiver only had audio inputs), I had to tear out pretty much all the wiring I had so I could rewire using HDMI. That’s actually what took me all day - the rewiring effort. I’m pretty anal about my cable management, so when all is said and done, it’s nicely bundled using velcro ties and cable wraps. But that also means it’s a pain in the ass to take apart if you’re redoing the whole system, so… much un-velcro-ing ensued. This picture to the right is of some of the wiring as I was in the process of ripping things out. Painful.

I also found that the receiver is 18.25” deep and my entertainment center is 18.5” deep, so there wasn’t enough room to plug anything into the back of it. That meant “cut a flap in the back of the entertainment center so you can plug stuff in.” That wasn’t too bad, but I wanted to do a nice job so it was time consuming and involved a couple of X-Acto knife blades. (The back of the entertainment center is a thick paperboard, not wood.)

After slotting that 65-pound beast into place, it was a matter of connecting everything up. There are a lot of inputs on the back, so this was mostly just trying to figure out which one(s) to use. Luckily, it turns out they’re all totally assignable, so you can say “The ‘CABLE/SATELLITE’ input really corresponds to HDMI input 3.”

And the final step, before strapping all the wires back down, was to test out the various components and make sure everything was connected correctly. I had a minor issue in that the HDMI inputs are numbered right-to-left instead of left-to-right, so what I thought I had plugged into HDMI input 1 was actually in HDMI input 7 (and so forth), but that was easy enough to straighten out. Chalk it up to me not paying close enough attention.

I got all the cables strapped down, pushed it all into place, ran the Audyssey MultEQ auto configuration utility, and watched me a little TV!

We also tried out some of the cool internet features, like listening to vTuner radio (free through this receiver) from around the world and logging into Pandora and listening/rating tracks right through the receiver. My sister and brother-in-law are living in Malta right now so we listened to some Maltese radio just to hear what they’re listening to. Very neat! It also detected my Asset UPnP installation on my Windows Home Server and I was able to browse and play my music library right through the receiver. (I did have to switch Asset to stream using WAV rather than LPCM, but WAV seems to work for both PS3 and the receiver.)

In playing some games and watching some movies, I found that my previous configuration had the rear surround turned down way too low and things were just not balanced as well as I thought. The surround after the Audyssey MultEQ configuration is much richer and more defined. I did notice that I had to mess with some of the “listening modes” to find the best one for standard stereo TV content and stereo streaming Netflix over Xbox 360, but the “THX Games” mode for Xbox 360/Dolby Digital games is really sweet and had Left4Dead 2 sounding phenomenal.

I was surprised at how cool the receiver runs. I figured this behemoth would run hot, but it’s actually not too bad. Warm, but not hot. I’m sure the big ol’ flap I cut for the cables in the back of the cabinet helps to keep the air circulating. Might have to consider doing that for the PS3, which sounds like a damn jet engine all the time it runs so hot.

Another surprising and cool detail was that my media center PC (running Windows 7) detected the new “display” as “TXNR3007” - it knew the kind of “monitor” it was hooked to. It also knew that the display “supported” several different HD-compatible resolutions, while connecting to the TV all it registered support for was 1920x1080. This allowed me to turn down the resolution a tad (I don’t watch full HD video through the media center) and hopefully save some video processing cycles.

Only negatives I’ve found to the new receiver:

The remote control situation. The remote it comes with doesn’t have enough buttons to replace my current universal and support all of the things my TV, cable box, etc. does… but the receiver remote also has two separate power buttons - one for “on” and one for “standby” - and my current universal remote only has one power button that can either turn the receiver on or off, but not both. The receiver remote also has a ton of stuff that I won’t be messing with once I’ve got everything set up to my liking, and Jenn’s got the current universal mastered… so I may just have to use the “learning” capacity on the current universal and teach some button to be the “off” for the receiver. Kind of kludgy, but them’s the breaks.

The “click.”It has this “click” noise that it makes as it switches from stereo to surround inputs. For example, if you’re watching HDTV and you’re crusing along great in Dolby Digital, then the local affiliate jams in a standard-def stereo signal, the receiver goes “click” as it switches from processing surround to stereo… then “click” again as it switches back. Not a deal breaker, but I kind of wish it didn’t do that.

Video processing warmup time. Turn on the TV, turn on the receiver, switch to the Xbox input, and turn on the Xbox. You hear the sound of the Xbox starting up, but the video signal takes three-to-five seconds to show up as all the internal signal switching goes on and everything filters through to the TV. Again, not a huge deal, but it was kind of scary the first couple of times as I was caught thinking, “Whooooooa… where the hell is my video?” That said, my TV (Samsung LN52A750) is not entirely blame-free - when a single input switches resolutions, it takes a couple of seconds to reacquire the signal for display. Found that out while messing with my media center PC resolutions.

None of those negatives is a huge issue, but something to be aware of. I don’t think I’d make a different purchasing decision based on them. I like the flexibility, the power, and the price of the unit, so no regrets. As things unfold, like if I find new or interesting things with it, I’ll keep the blog posted.

(I’m actually thinking of starting a wiki site dedicated to my home theater/media center setup - not really “community contribution” like a usual wiki so much as my notes on things I discover, how I set things up, etc., so interested folks can learn from my mistakes. Does that sound interesting to people?)

UPDATE 4/27/2010: I’ve posted about what I’ve learned two weeks in with this receiver.

In VS2010 Microsoft really hasn’t accounted for integrating FxCop into your continuous integration/scripted build in any way other than building through Visual Studio (unless you’re running Team Foundation Server, which I’m not). If you want your CI server to run FxCop, you have to have VS installed, which is pretty lame.

In addition, the format of the project files changed slightly, the list of assemblies containing rules has changed, and the way you specify which rules to run and which not to run is different (there’s a new concept of a “ruleset”).

And, of course, none of this is documented.

So here’s what I want:

• I want to run FxCop in continuous integration.
• I don’t want to have to install Visual Studio on the build server.
• I want to be able to run analysis as a big batch job at the end rather than one project/solution at a time during the build process. (That way I can also potentially run it asynchronously with other analysis.)

It took a bit, but I think I’ve figured it out.

Get a copy of FxCop from an installed Visual Studio. You’ll find it under your VS2010 install folder in a place like this: C:\Program Files\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop

Take that whole folder and put it on your build server somewhere, or check it in alongside your source code as a dependency/tool. (I don’t know if that somehow violates licensing or not, but you won’t be distributing it, you just want to run it. YMMV. I’m no lawyer.)

Create a RuleSet. This is the new way of saying which rules to run. It used to be part of the FxCop project file, but they changed it up a bit. To get a RuleSet:

1. Create a new throwaway project in Visual Studio.
2. Right-click on the project and select “Properties.”
3. On the left side of the properties window, select “Code Analysis.”
4. You should see a “Rule Set” area with a dropdown box marked “Run this rule set.” Select one of the pre-defined rule sets to start with and click “Open.”
5. Make changes to the rule set. Deselect rules you want run, etc.
6. Select File -> Save As… and save the modified rule set somewhere you can get it later.

Put the RuleSet along with your build scripts. The build script (when you run FxCop) will need to find that RuleSet, so put it along with your other build scripts and artifacts.

Add the location of the FxCop rules to the RuleSet. Open the RuleSet file in a text editor. Under the “RuleSet” root element, add a new “RuleHintPaths” element. Inside “RuleHintPaths,” add a “Path” element with text that has the path to the FxCop “Rules” folder - it needs to be able to find all of the rules assemblies that will be running. If you have custom rules, you’ll need to add more “Path” elements.

Your RuleSet will look something like this:

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="My Rules"
         Description="Rules that should be run on my assemblies."
         ToolsVersion="10.0">
  <RuleHintPaths>
    <Path>..\toolset\thirdparty\fxcop-vsts\Rules\</Path>
  </RuleHintPaths>
  <IncludeAll Action="Error" />
  <Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">
    <Rule Id="CA1006" Action="None" />
    <Rule Id="CA1014" Action="None" />
    <Rule Id="CA1016" Action="None" />
    <Rule Id="CA1020" Action="None" />
    <Rule Id="CA1054" Action="None" />
    <Rule Id="CA1055" Action="None" />
    <Rule Id="CA1056" Action="None" />
    <Rule Id="CA1303" Action="None" />
    <Rule Id="CA2210" Action="None" />
    <Rule Id="CA2243" Action="None" />
  </Rules>
</RuleSet>

Update your FxCop project file. If you were using an FxCop project file before, for example, if you were generating a dynamic dependency list, you have to do some updates. I’ll enumerate them first, then I’ll show you my FxCop project file.

• Change your PlatformAssembliesLocation to point to the .NET 4.0 install location.
• Remove the TargetFrameworkVersion node. (There’s no explicit .NET 4 target it seems, so omitting it will automatically target .NET 4.)
• Update the Rules/RuleFiles element to contain a list of all of the assemblies with rules in them, and make sure AllRulesEnabled on each is set to “True.” You’ll disable rules using your RuleSet.

Here’s what my FxCop project file looks like. I am dynamically generating the list of dependency locations as well as the list of assemblies to analyze, which is why you see some weird looking <!-- @DIRECTORIES@ --> comments in there. Check out my blog entry for more on that. In your project, you’ll probably have a real list of directories/assemblies to analyze there.

<?xml version="1.0" encoding="utf-8"?>
<FxCopProject Version="10.0" Name="FxCop Project">
 <ProjectOptions>
  <Stylesheet Apply="False">FxCopReport.xsl</Stylesheet>
  <PlatformAssembliesLocation>c:\WINDOWS\Microsoft.NET\Framework\v4.0.30128</PlatformAssembliesLocation>
  <SharedProject>True</SharedProject>
  <SaveMessages>
   <Project Status="Active, Excluded" NewOnly="False" />
   <Report Status="Active" NewOnly="False" />
  </SaveMessages>
  <ProjectFile Compress="True" DefaultTargetCheck="True" DefaultRuleCheck="True" SaveByRuleGroup="" Deterministic="True" />
  <EnableMultithreadedAnalysis>True</EnableMultithreadedAnalysis>
  <EnableMultithreadedLoad>True</EnableMultithreadedLoad>
  <SourceLookup>True</SourceLookup>
  <AnalysisExceptionsThreshold>10</AnalysisExceptionsThreshold>
  <RuleExceptionsThreshold>1</RuleExceptionsThreshold>
  <Spelling Locale="en-US" />
  <OverrideRuleVisibilities>False</OverrideRuleVisibilities>
  <SearchGlobalAssemblyCache>True</SearchGlobalAssemblyCache>
  <DeadlockDetectionTimeout>120</DeadlockDetectionTimeout>
  <IgnoreGeneratedCode>True</IgnoreGeneratedCode>
 </ProjectOptions>
 <Targets>
  <!-- @TARGETS@ -->
  <AssemblyReferenceDirectories>
   <!-- @DIRECTORIES@ -->
  </AssemblyReferenceDirectories>
 </Targets>
 <Rules>
  <RuleFiles>
   <RuleFile Name="$(FxCopDir)\Rules\DataflowRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\DesignRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\GlobalizationRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\InteroperabilityRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\MaintainabilityRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\MobilityRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\NamingRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\PerformanceRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\PortabilityRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\ReliabilityRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\SecurityRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\SecurityTransparencyRules.dll" Enabled="True" AllRulesEnabled="True" />
   <RuleFile Name="$(FxCopDir)\Rules\UsageRules.dll" Enabled="True" AllRulesEnabled="True" />
  </RuleFiles>
  <Groups />
  <Settings />
 </Rules>
</FxCopProject>

Update your FxCop command line. The last thing you have to do is modify the <Exec> task you have in your MSBuild script so it points to your project and your RuleSet. Just add the /ruleset parameter to point to run your rules, like /ruleset:=YourRuleset.ruleset

My FxCop command line looks something like this (anonymized/simplified for illustration purposes):

<PropertyGroup>
  <FxCopProject>Path\To\Project.FxCop</FxCopProject>
  <FxCopOutput>Path\To\Output\FxCopReport.xml</FxCopOutput>
  <FxCopXsl>$(FxCopDir)\Xml\FxCopReport.xsl</FxCopXsl>
  <FxCopDictionary>Path\To\CodeAnalysisDictionary.xml</FxCopDictionary>
  <FxCopRuleset>Path\To\YourCustom.ruleset</FxCopRuleset>
</PropertyGroup>
<Exec ContinueOnError="true" Command="$(FxCopDir)\FxCopCmd.exe /dictionary:&quot;$(FxCopDictionary)&quot; /ruleset:=&quot;$(FxCopRuleset)&quot; /o:&quot;$(FxCopOutput)&quot; /p:&quot;$(FxCopProject)&quot; /fo"/>

Once you have that, you should be able to run FxCop from the command line in your build without having to install Visual Studio.

Now to go through and fix all the new errors it found…