Moving around VST dlls

This is kind of an extension of a question I asked recently on here.
 
I was wondering, since all my VSTs over the years have installed in multiple different folders... what would happen if I moved them all into one VSTs folder under C:\Program Files\Vstplugins OR 2, one under the x86 program files folder for 32bit vsts and the 64bit ones in the regular Program Files...
 
Would existing projects fail to load the proper plugin because of the move? Would updates for plugins fail to install because of the move?
 
I'm trying to feel it out... It's something I'm definitely curious about... Maybe I'll leave it for my next format and reinstall whenever that may be... But it seems like it would be something worth doing...
 
Thanks

Not entirely true...
 
Some plug-ins have a path stored somewhere and moving them will require a registry/config file change (eg. Rapture).
 
I'd strongly advise against putting any 32 bit VSTs in Program Files (x86) because of UAC and permissions: create a root directory (say) called VST (x86).

Projects are not sensitive to plug-in locations. The only preconditions for a project, is the plug-in be properly installed and scanned.
 
The issue with updates is the same as moving the plug-in in the first place. Updates fall into two categories, those that ask for the plug-in location (sometimes they will pick up a default from the registry) and those which read the previous install location from the registry. If the previous installation location is written in the registry, there are usually dependencies which will cause the relocation to fail anyway.
 
All the existing plug-in locations can be stitched together using mklink with the /d or /j switch into a single directory tree if that is the goal of the exercise.

Well, many plugins don't have an install, and are simply copied into a folder or sub-folder, and these can be moved anytime to anywhere, as long as you maintain their current location in the search paths for Sonar.  
 
It seems to generally be stand-alone versions of synths/effects that get the actual Windows installation, with Registry entries and all of that, and then the accompanying 32-bit and 64-bit plugins routinely just end up copied into a common path, such as VST Plugins, or wherever.
 
From Sonar's perspective, as long as it finds it, through search-path inclusion, it will attempt to load it.
 
The other aspect is when there is associated CONTENT for a given plugin, such as a sample library for Kontakt 5, or Dimension Pro, or a preset library - and such.  These generally EITHER are fixed, for some products, in which case you may have to reinstall to move, or might not be able to move at all, OR they may have an internal parameter that you can adjust to point the product to wherever its associated content lives.  In that case, this is usually an install option, and if you change it later, you would change the path in the software and then typically do some sort of 'refresh' function to reconnect it to its associated content at the new location.
 
So, the bottom line is that you should be able to move many/most things around, but you will certainly have to look at the nature of what any particular plugin's processing requirements are designed, and then you would react accordingly.
 
When I install things, I usually install into the appropriate program files folder (x32/x64) per a given program's installation process defaults, and for dll placement, if given a choice, I specify either the Cakewalk plugins folder, or to one I created - VST Plugins (a sub-folder within the x32 and x64 program folders).  
 
Plugins that are just downloaded dll's from places such as KVR, or wherever, usually get placed by me into one of the 2 VST Plugins folders.
 
You can also group the display of things in many ways - here are a couple of Sonar documentation links that talk about this:
 
http://www.cakewalk.com/Documentation?product=SONAR%20X3&language=3&help=Browser.07.html
 
http://www.cakewalk.com/Documentation?product=SONAR%20X3&language=3&help=Mixing.36.html
 
I hope that helps, 
 
Bob Bone