locked
Add Reference and AssemblyFolders RRS feed

  • Question

  • I need to simulate some of the functionality of Add Reference (as seen in visual studio) in a separate tool we are developing.

    I know that installed components often have a folder specified in the AssemblyFolders registry key, this tells VS to search that folder when populating its Add Reference dialog box.

    However, I have code that does the same and we do not get everything that visual studio has, there are numerous components listed in the VS Add Reference whose contaning folder does NOT appear in the AssemblyFolders registry key (either the 32-bit or 64-bit nodes).

    For example IronMath or IronPython domponents (and many others) are stored in this folder:

    C:\Program Files (x86)\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Common\Assemblies

    Yet this folder appears nowhere beneath either of the two AssemblyFolders registry areas.

    Now I can live with what we have, but I wanted to know if there are additional rules/heuristics published by MS that explain where else to look for assemblies.

    Also our tool is 64-bit on x64 machines, but 32-bit on x86 machines, so if we follow standard Microsoft rules we see different sets of AssemblyFolder paths (because there are two instances on in the 'normal' registry and one beneath the Wow3264Node subkey) and these are not the same.

    Therefore we think we should always look at BOTH of these registry areas irrespective of whether we are running 64-bit or 32-bit, but this violates standard MS guidelines, but I cannot see any other way. Visual Studio runs as a 32-bit app, yet we know that it lists assemblies whose paths are defined beneath the non-Wow6432Node, so it too is explicitly examining the 64-bit registry key - but MS says one should not do so !

    Any tips or info etc, much appreciated.

    Cap'n

     

     

     

     

    Saturday, October 9, 2010 4:30 PM

Answers

  • Sorry about the slow response on this one. I had to do some digging to see how we populate that component picker page. Wound up having to debug through a bit of IDE code to figure this out.  If you're tool is running in the VS process space (aka an add-in or package), you can simply use the IVsComponentEnumeratorFactory3.GetComponentsOfPathEx, to enumerate through all the assemblies on the search paths. This is what the default AddReferences dialog uses to populate the list of available reference assemblies.

    I suspect each project type may be able to add additional references (like IronPython) and you may not be able to easily account for these. Meaning, the project type may be adding them from a location that only it knows about, but the IDE probably does not. If the language/project installer happens to install these additional assemblies to one of the known reference paths, then they should be picked up. But if the project type just adds them from a 'private' location, then you'll have to figure that out project type by project type.

    If you are not running inside the VS IDE, you can use the ToolLocationHelper::GetPathToReferenceAssemblies implemented in the Microsoft.Build.Utilities.v4.0.dll assembly. Turns out, this is what the IDE's IVsComponentEnumeratorFactory3 uses under the hood to find all the search paths to look for, based on the specified target framework.

    Sincerely,


    Ed Dore
    Tuesday, October 19, 2010 9:14 PM