Come gestire una nuova versione della directory di Visual Studio?

Una libreria creata per .NET Fw 4.0 (o precedente, fino a 2.0) dovrebbe essere (nella maggior parte dei casi reali) utilizzabile da qualsiasi progetto 4.5 (l'opposto non è vero). Quindi, fintanto che non ci sono motivi validi per aggiornare una libreria a .NET Fw 4.5, raccomanderei di rimanere in 4.0, almeno fino a quando si ha almeno un progetto basato su 4.5 che usa quella lib. Questa strategia ti permetterà di avere una libreria che funziona per entrambi i tipi di progetti, senza la necessità di duplicare nulla.

Si noti che non sarà necessario installare una versione VS precedente per mantenere 4.0 lib - VS 2013 supporta 4.0 e 4.5 progetti, e nemmeno impone un aggiornamento della versione per i file di progetto delle versioni VS precedenti.

Se non è possibile evitare la necessità di mantenere una versione 4.0 di una libreria in manutenzione in parallelo a una versione 4.5 della stessa lib, provare a mantenere le modifiche alla 4.0 piccola, utilizzare un modello di diramazione appropriato del proprio sistema di controllo della versione e assicurati di poter correggere in modo trasparente la versione 4.0 mentre implementa nuove funzionalità nella versione 4.5 in parallelo. Ma tieni presente che tutti i bugfix per la versione 4.0 dovranno essere uniti alla versione 4.5, quindi potresti generare uno sforzo ulteriore in questo modo.

La risposta corretta nel 2014 non è la precedente. Innanzitutto, la posizione di salvataggio dei file di default non ha un vero significato nella vita - sospetto che sia solo Microsoft a seguire le proprie regole su dove i programmi dovrebbero salvare le cose per impostazione predefinita.

Per quanto riguarda il modo di gestire progetti di dipendenza trasversali, la risposta giusta è trattarli come progetti a sé stanti con il proprio sistema di controllo del codice sorgente e costruire sistemi e sfruttare il nuget per utilizzarli in altri progetti. Se non riesci a modificarlo, ti suggerirei di lasciare che ogni progetto tenga una copia delle DLL dipendenti (e se possibile le fonti) in modo che rimangano sulla loro testa.

Facendo direttamente riferimento all'output di build come sembra che tu stia facendo crea alcuni incubi di versioning a dir poco. Se questa è la tua unica opzione, prenderei in considerazione il solo staticamente incluso il codice nel progetto che lo sta usando, quindi ha la sua "libreria".