Aggiornamento dei riferimenti ai progetti di Visual Studio a livello di programmazione

Question

Desidero aggiornare i riferimenti nei progetti nella mia soluzione Visual Studio.

Ho circa 15 progetti nella mia soluzione e quando sviluppo/debug voglio che i riferimenti rimandino ai progetti all'interno della soluzione.

Come parte della mia procedura di rilascio, a volte ho bisogno di fare una copia di un progetto e quindi aggiornare i riferimenti per puntare a dll incorporati in una determinata cartella.

Posso elaborare la struttura dei file di progetto e come funzionano i riferimenti all'interno di essi e sto pensando di creare uno strumento da riga di comando per analizzare i file di progetto e modificare i riferimenti come richiesto.

Le mie domande sono:
1. Vi sembra una cosa sensata da fare
2. Qualcuno ha esperienza di questo e/o come si occupano di gestire il passaggio tra lo sviluppo e il rilascio modalità
3. Qualcuno ha qualche librerie che si occupano di analizzare i file di progetto di Visual Studio.

PRECISAZIONE:

Grazie per le risposte. Forse dovrei chiarire alcune situazioni in cui desidero utilizzarlo.

a) La mia applicazione contiene 15 progetti. Cerco di mantenere la soluzione il più piccola possibile per quello a cui sto lavorando, quindi di avere 5 progetti nella mia soluzione. Ora devo eseguire il debug/sviluppare uno dei progetti non nella soluzione, quindi aggiungo questo progetto, ma devo: - impostare i riferimenti nei progetti originali per puntare a riferimenti di progetto piuttosto che a dll compilati - cambiare i riferimenti nel progetto appena aggiunto per puntare al progetto opportuni riferimenti

Vorrei che il mio strumento per farlo automaticamente e l'unico modo che conosco per cui questa attualmente sta manipolando i file di progetto

b) nell'ambito di un servizio di procedura di compilazione del pacchetto Prendo una copia di uno dei progetti, apporta le modifiche necessarie al codice e costruisco utilizzando Visual Studio. Per fare ciò devo modificare tutti i riferimenti alle DLL compilate

Answer 1

Penso che un approccio migliore sarebbe utilizzare i blocchi condizionali sui riferimenti direttamente nel file di progetto. Quindi tutto ciò che devi fare è impostare un flag particolare durante il msbuild per la build "release" e raccoglierà i riferimenti corretti.

Per esempio

<ItemGroup Condition="'$(IsRelease)'=='True'"> 
    <Reference Include="..." /> 
</ItemGroup> 
<ItemGroup Condition="'$(IsRelease)'!='True'"> 
    <Reference Include="..." /> 
</ItemGroup> 

Answer 2

Suona come una situazione strana.

Il mio suggerimento è questo.

1. Suddividere i progetti con versioni predefinite in una soluzione separata.Averli tutti a costruire a

   \ Assemblies \ fromsource

2. Copia quelli predefiniti in;

   \ assembly \ precompilati

3. Prima di sviluppare il resto dei progetti, copiare o directory in

   \ assembly \ sviluppo

4. modificare i vostri progetti per puntare alle versioni in \ assembly \ sviluppo.

Così ora, si crea sempre il prodotto con i binari precompilati in una cartella conosciuta, quindi non è mai necessario modificare il progetto. Ma puoi scambiare tra le versioni a piacere.

Per i punti bonus, modificare un evento di preinstallazione per copiare le DLL prima che le cose inizino a creare e fare in modo che la cartella di origine vari in base alla configurazione. Quindi aggiungere una configurazione PREBUILT insieme a DEBUG e RELEASE.

Answer 3

Tiger, Tiger ROAR !!!

Questo sta utilizzando DTE e VSProject ai riferimenti di aggiunta programmatici. Ho commentato il codice per la maggior parte della spiegazione. Ma per aggiungere ho buttato una tonnellata di riferimenti extra diversi perché sono piuttosto pigro. Ma basta ordinare con Visual Studio e dovresti stare bene. Se per qualsiasi motivo questo non si compila sentiti libero di urlarmi contro.

 

using System; 
using System.Collections.Generic; 
using System.ComponentModel; 
using System.Linq; 
using System.Runtime.InteropServices; 
using System.Text; 
using System.Windows.Forms; 
using EnvDTE; 
using EnvDTE80; 
using EnvDTE90; 
using EnvDTE90a; 
using Extensibility; 
using Microsoft.VisualStudio.Shell; 
using Microsoft.VisualStudio.Shell.Design; 
using Microsoft.VisualStudio.Shell.Interop; 
using VSLangProj; 

namespace ConsoleApplication2 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      //Disclaimer: 
      //I am doing this through an extention, Getting 
      //a ref to DTE may not work quite the same for you as 
      //there are several different ways to do it. But the 
      //VSProject stuff shouldn't be an issue 

      //Get your DTE Reference, I'm using DTE2 from EnvDTE80 
      //I hadn't dug into whats the earilest compatible version 
      //The Package is Microsoft.VisualStudio.Shell.Package 
      DTE2 _appObject = Package.GetGlobalService(typeof(DTE)) as DTE2; 

      //This gets the first project in the solution set and casts it as a VSProject 
      //Note that Web projects use a different type , Something like VSWebProject 
      //or something I forget... 
      var pj = (VSProject)_appObject.Solution.Projects.Item(1).Object; 

      //Your dll path 
      pj.References.Add(@"c:\MyRefs\Pastry.dll"); 
     } 
    } 
} 

Answer 4

penso che se si utilizza la libreria Microsoft.Build.BuildEngine è possibile manipolare i progetti di programmazione dopo il caricamento.

http://msdn.microsoft.com/en-us/library/microsoft.build.buildengine.aspx

Answer 5

Non credo che ci sia una risposta facile alla tua prima domanda. Di regola, raccomanderei di evitare questa situazione. È difficile da gestire manualmente e il codice per gestirlo non è banale.

Detto questo, ho incontrato una situazione nel mio lavoro in cui semplicemente non riuscivo a risolvere il problema. Nel nostro caso, stavamo lavorando per rilasciare un SDK che necessitava di includere una serie di progetti di esempio. La versione "sviluppo" di quei progetti utilizzava sia riferimenti di progetto che riferimenti a librerie di terze parti.

Questo ci porta al n. 3 che è fondamentalmente, sì. In realtà ho rilasciato un open source project with a library, a simple windows utility and a NAnt extension to automatically change project references to dll references. Infatti, gestisce anche lo spostamento di quelle librerie di terze parti nella stessa cartella locale e aggiorna tali riferimenti nel file di progetto.

Questa soluzione non è perfetta e ci sono molti miglioramenti che mi piacerebbe aggiungere il tempo, ma funziona per la nostra situazione. Parte del nostro script di rilascio, che è tutto in NAnt, esegue questo processo per scambiare tutti i riferimenti a un percorso relativo. Quindi possiamo facilmente raggruppare l'intero setup. Un giorno forse avrò il tempo di aggiungere un compito MSBuild insieme al progetto.

Ancora una volta, penso che sia meglio evitarlo il più possibile, ma se rimani bloccato come me, il codice che ho rilasciato dovrebbe almeno aiutare.

Answer 6

C'è uno strumento sulla galleria di Visual Studio che potrebbe aiutarti.

È possibile sostituire i riferimenti sulla soluzione con i progetti durante l'aggiunta e viceversa se rimossi.

https://visualstudiogallery.msdn.microsoft.com/056617a4-da39-4d7b-8ecf-933009d9b721