2009-05-01 13 views
16

Quando si aggiunge un riferimento a un progetto di applicazione Web in VS (2008 in questo caso), il "hintpath" nel file csproj viene creato come riferimento relativo. C'è un modo (utilizzando la GUI, non modificando manualmente il file) per rendere questo un riferimento assoluto (ad esempio C: \ Temp \ DllName.dll)?Forza un riferimento a essere assoluto utilizzando Visual Studio

Il problema che sto incontrando è quando le macchine di compilazione separate hanno una diversa directory di lavoro per il progetto. Quando il riferimento è relativo e la DLL di riferimento non si trova all'interno della directory di lavoro del progetto, il riferimento relativo potrebbe non puntare alla stessa posizione su entrambe le macchine.

+1

Qual è lo scopo per cui si desidera un percorso non relativo? Potrei capire di volere un percorso che includa una SpecialFolder, ma un percorso interamente codificato non è flessibile tra i sistemi. – STW

+2

@Yoooder Non si sono visti i percorsi esilaranti relativi che lo studio visivo ama utilizzare, ma potrebbe anche essere codificato. Li ho visti .. \ .. \ se stessi fino alla radice e poi di nuovo alla cartella di destinazione, è grandioso. – hova

+0

stavo cercando questo. Perché? Ho alcuni metodi di estensione che si ripristinano dopo aver rotto le modifiche nelle varie versioni dell'app nel corso degli anni. Grazie a AutoDesk. Aspetta, no. Questi metodi di estensione sono universali in tutte le mie app. Non voglio dover applicare patch a tutte le app sul mio computer perché devo modificare o aggiungere una correzione per le incoerenze di AutoCAD. Voglio sistemarlo in un posto. L'unico altro modo corretto per farlo è con un server Nuget locale. Overkill molto? –

risposta

-1

Mi piacerebbe aiutare ma perché è necessario? Non ho mai dovuto fare questo mai - dal vsnet beta 2003. Penso che ci sia un'altra domanda più profonda qui.

Se è necessario si può provare la pagina di percorso di riferimento nelle proprietà del progetto

+0

Di solito, questo accade quando qualcun altro carica un progetto in una soluzione, con una profondità di percorso diversa da quella originariamente creata. – hova

+2

Ho guidato team .net per anni e andrai # @ # $ nuts in questo modo. Questa è la prima cosa che aggiusto. Fai in modo che tutti possano mordere il proiettile e organizzare il tuo progetto di soluzione e fa riferimento a un tagliando di chiunque (beep) chi (bip) con esso. – Gary

+0

Bene, questo spiega perché non hai mai dovuto farlo allora. – hova

0

Prova clic destro le proprietà del progetto, e poi andare a riferimento percorsi, e aggiungendo i percorsi hard coded lì.

+1

Ho fatto questo, ma sembra che non cambi davvero nulla nel file .csproj. Quindi, questo non dovrebbe essere aggiunto su ogni macchina dev/build? – Jeremy

5

Per impostazione predefinita, Visual Studio utilizza i riferimenti relativi quando il riferimento viene inizialmente aggiunto, poiché presuppone che il riferimento sia a un file altrove nella copia di lavoro.

Questo utilizzato per guidare mi noci, ma ho risolto in tre modi diversi:

  1. Mantenendo il mio codice sorgente sul mio D: unità, il che significa che le DLL fa riferimento a C: non poteva essere conservato con percorsi relativi.
  2. Persuadendo i poteri di utilizzare un'unica immagine/script per tutte le workstation dello sviluppatore. Ora che sono tutti uguali, i file si trovano tutti nello stesso punto sul disco C :.
  3. Realizzando che è possibile aggiungere cartelle allo AssemblyFolders registry key, significa che non è più necessario utilizzare percorsi di alcun tipo per fare riferimento a assiemi noti.
+1

Yar, mettendolo su un'altra unità, o qualcosa mappato come un altro disco sembra l'unico modo per sconfiggerlo. –

+0

Link in 3 è rotto .... è questo? http://stackoverflow.com/a/238445/1507899 – RJB

+0

Abbastanza vicino, sì. –

5

L'unico modo in cui ho trovato di farlo è modificando manualmente il file csproj dopo aver aggiunto il riferimento.

<Reference Include="foo, Version=1.2.3.4, Culture=neutral, ..."> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>C:\absolute\path\foo.dll</HintPath> 
</Reference> 

e sì, io odio percorsi assoluti e tutta la follia distribuzione automatica si crea, ma in questo caso devo fare riferimento a un wrapper .NET che utilizza una DLL COM che deve essere "installato" e fare le cose al registro, ecc. quindi un percorso assoluto è l'unica strada da percorrere.

10

Questa è una vecchia domanda, ma è comunque pertinente. Mi sono imbattuto in esso mentre cercavo una soluzione su come fare riferimento agli assembly da un repository globale di software di terze parti.

Il mio approccio al momento è simile alla risposta scritta da thinkOfaNumber. Invece di utilizzare un percorso assoluto hardcoded, preferisco incorporare una variabile di ambiente nel file .csproj. La variabile di ambiente quindi mantiene il percorso assoluto. Esempio:

<Reference Include="Foo"> 
    <HintPath>$(THIRDPARTY_ROOT)\foo\3.1.0\bin\foo.dll</HintPath> 
</Reference> 

Questo ulteriore livello di riferimento indiretto offre la flessibilità di avere diversi percorsi su macchine diverse build (per esempio di sistema sviluppatore vs. build server).

Ho ancora bisogno di modificare manualmente il file .csproj per fare questo, però.

+0

Sì, la tua risposta è quella che arriva veramente al punto. È sciocco discutere su chi può fare la chiamata su quale sia il percorso, e se i percorsi relativi o i percorsi assoluti siano la chiamata migliore. La realtà è che se si può affermare che tutti gli sviluppatori hanno la stessa configurazione o meno (NOT!), È probabile che il server di compilazione stesso sia impostato diversamente. Se non usi le variabili nei tuoi percorsi suggerimento, non lo farai in maniera molto sofisticata o flessibile. Detto questo, Microsoft ha bisogno di renderlo intuitivo in modo che le variabili di progetto o ambiente possano essere definite per contenere questi dati. – paulyphonic

+1

Microsoft dovrebbe inoltre consentire più elementi HintPath in modo che itererà attraverso di essi fino a quando non trova una corrispondenza. In effetti, ho assunto che fosse basato sulla parola "suggerimento" (se dai un suggerimento a qualcuno, e non aiuta, probabilmente dovresti dare loro un altro suggerimento ... "suggerimento") che questo sarebbe permesso, e è stato scoperto solo attraverso una lunga risoluzione dei problemi a cui interessa solo l'ultimo elemento HintPath che trova! – paulyphonic

+4

Ricordare che VS memorizza nella cache i percorsi degli assembly di riferimento nel file '.suo'. Quindi, se si modifica il valore della variabile env THIRDPARTY_ROOT, non dimenticare di chiudere la soluzione e rimuovere il file '.suo', quindi riaprire la soluzione. – SergeyT

0

Abbiamo anche riscontrato questo problema. Volevamo utilizzare percorsi assoluti perché ogni distribuzione creava la cartella Pacchetti in posizioni diverse (e abbiamo anche più macchine di compilazione). L'idea era di avere i pacchetti NuGet in un unico posto, liberando così la memoria sprecata dall'avere più copie della stessa cosa.

Il nostro problema specifico era che potevamo impostare il percorso assoluto nel file NuGet.Config, i pacchetti Nuget avrebbero ripristinare in quella posizione durante una distribuzione, ma poi non tutti riuscivano a trovare durante la fase di MSBuild nel stessa distribuzione.

Ho scritto uno script PowerShell per risolvere questo problema. Sostituisce sostanzialmente i riferimenti relativi a HintPath con il percorso assoluto che voglio usare.

#Get list of all csproj files in a solution 
$dir = Get-ChildItem $pwd -Recurse 
$list = $dir | Where {$_.extension -eq ".csproj"} 

#Replace relative paths with absolute path 
$absolutePath = 'C:\absolute\path\Packages' 
function replaceRelativePath($line){ 
    if($line -match '<HintPath>[^C].+\\Packages') 
    { 
     $relative = $matches[0] -replace '\\','\\' 
     return ($line -replace "$relative", "<HintPath>$absolutePath") 
    } 
    else 
    { 
     return $line 
    } 
} 

#Updating files 
Foreach($file in $List) 
{ 
    (Get-Content $file.FullName)| ForEach-Object{replaceRelativePath($_)} | Set-Content $file.FullName 
} 

Abbiamo installato questo script da eseguire come un passo PowerShell costruire prima dei passaggi MSBuild nel nostro schieramento. Il risultato è che i file csproj vengono modificati per la directory di lavoro sui computer di compilazione ma non nel controllo del codice sorgente di Visual Studio. (Se si desidera che vengano modificati nel controllo origine, è possibile eseguirlo in PowerShell e archiviare le modifiche.)

Problemi correlati