In Part 1, I mentioned an issue regarding AssemblySearchPaths. Specifically, Microsoft.Common.targets contains a property group whose elements define a registry path. The corresponding values of subkeys underneath the registry path contain certain Whidbey assembly paths that are searched by RAR. Since we only want to search for Everett assemblies, however, the registry path needed to be changed. I initially expected to simply alter the property values to build a different registry path and obtain values under that path. Unfortunately, I was wrong. It turns out there's an issue with the version property...

In Microsoft.Common.targets, the TargetFrameworkVersion property is set as follows:

<TargetFrameworkVersion Condition=" '$(TargetFrameworkVersion)' == '' ">v2.0</TargetFrameworkVersion>

The TargetFrameworkVersion property is used when building the registry path. Although I changed the value of this property in my targets file, the registry path I'm interested in is tied to the VS version, not the .NET Framework version. Thus, I created a VisualStudioVersion property in my targets file:

<VisualStudioVersion>7.1</VisualStudioVersion>

Note that it's not v7.1, just plain 7.1. The reason for this is that the registry path I need to search (SOFTWARE\Microsoft\VisualStudio\7.1\AssemblyFolders) contains 7.1, not v7.1. And therein lies the rub. MSBuild expects that the supplied version starts with a v. If it doesn't, the version string isn't processed which causes the registry path to not be built and consequently not be searched. To work around this, I ended up creating a GetRegistryValue task which takes a registry path and returns the values of all keys and subkeys underneath the path. Thus, I provide the task my registry path and it returns a list of the values underneath it, which are the assembly paths that RAR needs to search.