Mantenere i progetti di Visual Studio su un'unità di rete

https://stackoverflow.com/questions/159627

03-07-2019
|

Domanda

Siamo appena passati dall'archiviazione locale di tutti i file a un'unità di rete. Il problema è che adesso sono memorizzati anche i miei progetti VS. (Nessun sistema di versione ancora, lavorando su quello.) So di aver sentito parlare di problemi con questo in passato, ma non ho mai sentito parlare di una soluzione. C'è un lavoro in giro?

Quindi il mio VS è installato localmente. I file si trovano su un'unità di rete. Come posso farlo funzionare?

EDIT: so cosa DOVREBBE essere fatto, ma c'è un cerotto che posso mettere in questo momento per risolvere questo problema e mantenere l'unità di rete?

EDIT 2: Sono sicuro di non capire qualcosa, ma Bob King ha l'idea giusta. Lavorerò con lo sviluppatore web principale quando tornerà in ufficio per trovare una soluzione temporanea fino a quando non avremo una sorta di configurazione del controllo della versione. Grazie per le idee.

Soluzione

Mentre utilizziamo il controllo del codice sorgente, eseguiamo anche tutti i nostri progetti da unità di rete (non directory condivise, directory private su unità di rete). Il backup delle unità di rete viene eseguito di notte e utilizza anche Volume Shadow Copy, quindi se è necessario ripristinare qualcosa prima , è arrivato a SC, quindi è possibile.

Per far funzionare correttamente i progetti con l'autorizzazione giusta, segui questi passaggi .

Fondamentalmente, devi solo mappare la directory condivisa su un'unità e quindi concedere l'autorizzazione, basata su quell'URL, a tutto il codice. Di 'la mappa su & Quot; N: \ & Quot ;, quindi usa & Quot; N: \ * & Quot; come pattern Url. Non è ovvio che devi jolly, ma lo fai.

Altri suggerimenti

La domanda è piuttosto generica, quindi darò una risposta a un problema che stavo affrontando.

Eseguo Visual Studio 2010 usando una macchina virtuale Parallels sul mio Mac mantenendo tutti i miei progetti sul lato Mac tramite una condivisione di rete. Visual Studio tuttavia non carica i file di assieme dei progetti da lì. Tentativo di impostare i diritti utilizzando & Quot; caspol & Quot; da solo non ha aiutato nel mio caso.

Ciò che alla fine ha funzionato per me per consentire a Visual Studio di caricare gli assembly da una condivisione di rete è stato modificare il file " C: \ Programmi (x86) \ Microsoft Visual Studio 10.0 \ Common7 \ IDE \ devenv.exe.config " (presupponendo un'installazione predefinita).

in xml " < runtime > " sezione che devi aggiungere

<loadFromRemoteSources enabled="true"/>

Potrebbe essere necessario modificare le autorizzazioni per quel file per consentire l'accesso in scrittura. Salva il file. Riavvia Visual Studio.

Nell'interesse di rispondere effettivamente alla domanda, ho copiato questo commento da jcarle.com:

Affidabilità delle condivisioni di rete con Visual Studio 2010 / .NET Framework v4.0

20 gennaio 2011, 16:10 Se sei come me e memorizzi tutto il tuo codice su un server, probabilmente avrai imparato a fidarti di una condivisione di rete usando CasPol.exe. Tuttavia, quando passi da Visual Studio 2008 (.NET Framework 2.0 / 3.0 / 3.5) a Visual Studio 2010 (.NET Framework 4.0), potresti ritrovarti a grattarti la testa.

Se si è abituati a utilizzare il prompt dei comandi di Visual Studio per accedere rapidamente a CasPol, è possibile che alcuni dei progetti sembrino non rispettare le nuove impostazioni di FullTrust. Il motivo è che, se non si presta attenzione, il prompt dei comandi di Visual Studio imposta automaticamente l'aggiunta della cartella .NET Framework 4.0 al suo percorso. Se il progetto è ancora in esecuzione in .NET Framework 2.0 / 3.0 / 3.5, sarà necessario impostare CasPol anche per quelle versioni. Solo una nota, ho anche avuto personalmente più successo con l'utilizzo di 1 come gruppo di codice anziché 1.2.

Per fidarti di una condivisione di rete per tutte le versioni di .NET Framework, chiama CasPol per ogni versione usando il percorso completo come di seguito:

C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CasPol -m -ag 1 -url file: // YourSharePath * FullTrust
C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ CasPol -m -ag 1 -url file: // YourSharePath * FullTrust

Non consiglierei di farlo se hai (o anche se non hai) più persone che stanno lavorando ai progetti. Stai solo chiedendo problemi.

Se sei l'unico a lavorarci su, d'altra parte, eviterai gran parte dei problemi. Tuttavia, le prestazioni finiranno fuori dalla finestra. Per quanto riguarda come farlo funzionare, basta aprire il file della soluzione da VS. Probabilmente incontrerai problemi di sicurezza, ma puoi correggerlo usando CASPOL. Come ho detto, tuttavia, le prestazioni saranno terribili. Ancora una volta, non è affatto raccomandato.

Fai un favore a te e al tuo team e installa SVN o qualche altra forma di controllo del codice sorgente e inserisci il codice al più presto.

EDIT: ritirerò parzialmente i miei commenti. Bob King spiega di seguito il motivo per cui eseguono progetti VS da un'unità di rete e ha senso. Direi che a meno che tu non lo stia facendo per un motivo specifico come Bob, stai alla larga. Altrimenti, metti le tue anatre di fila prima di creare un tale ambiente di sviluppo.

Capisco che questo è un thread più vecchio, ma questo è stato il miglior thread che ho trovato quando ho cercato di risolvere un problema simile che avevo Visual Studio 2013 su un box virtuale (usando Win 8.1) e il codice sul computer host (Win 7 ). Anche se ho potuto aprire la soluzione, non ho potuto compilare. Tutte le altre risposte su questo si riferiscono a software più vecchi, quindi aggiungo questa risposta per aggiornare questa domanda frequente con la soluzione che ha funzionato per me.

Ecco cosa ho fatto; Creato una voce di registro per poter utilizzare un percorso UNC come directory corrente.

ATTENZIONE: L'uso errato dell'Editor del Registro di sistema può causare seri problemi a livello di sistema che potrebbero richiedere la reinstallazione di Windows NT per correggerli. Microsoft non può garantire la risoluzione di eventuali problemi derivanti dall'uso dell'Editor del Registro di sistema. Utilizzare questo strumento a proprio rischio.

Sotto il percorso del registro: HKEY_CURRENT_USER \Software \ Microsoft \ Processore di comando

aggiungi il valore DisableUNCCheck REG_DWORD e imposta il valore su 0 x 1 (esadecimale).

AVVERTENZA: se si abilita questa funzione e si avvia una Console che ha una directory corrente con un nome UNC, avviare le applicazioni da quella Console e quindi chiudere la Console, potrebbe causare problemi nelle applicazioni avviate da quella Console.

Trovate queste informazioni al link: http://support.microsoft.com/kb/156276

Che ne dici di riformularlo in una domanda a cui tutti possono rispondere? Ho lo stesso identico problema del poster iniziale.

Ho una copia di VB 2008 (recentemente aggiornato da VB6). Se conservo le mie soluzioni sull'unità di rete di cui è stato eseguito il backup, non funzionerà mai più. Fornisce & Quot; chiamante parzialmente attendibile & Quot; errori di accesso a un modulo, anche quando " allowpartiallytrustedcallers " è impostato nell'assieme. Se memorizzo i file sulla mia C: (non sottoposta a backup), funzionerà meravigliosamente, fino a quando non li inserirò nell'unità di condivisione affinché tutti possano usarli, e tornerò al mio stesso problema.

Questa non è una grande richiesta. Voglio solo essere in grado di mettere una soluzione ed eseguibile sull'unità di condivisione ed eseguirlo senza un'assurda quantità di sciocchezze sulla sicurezza. Non dovrei stipare tutto il mio lavoro in file di modulo.

-Edit: ho riscontrato il problema con il motivo per cui ignorava il comando AllowPartialllyTrustedCallers. Sto cercando di fare riferimento a ADODB, che non consente in parte attendibile. Quindi, nessun eseguibile di rete può accedere a un database? Che cosa ha comunque Microsoft contro le intranet?

Non farlo. Se si dispone del controllo del codice sorgente (controllo delle versioni), non si desidera che i file su un'unità di rete. Ignora totalmente tutto ciò che vuoi ottenere usando il controllo del codice sorgente, perché una volta che i tuoi file si trovano su un'unità di rete, chiunque può modificarli ... anche mentre stai attualmente costruendo il tuo progetto. Ka-boooom!

PS: mi sembra un tipico caso di sovraingegneria.

Stai riscontrando problemi specifici?

Se consenti a più di una persona di aprire la soluzione, il tuo primo problema sarà che il file .NCB (Intellisense) verrà bloccato esclusivamente e solo un utente sarà in grado di sfogliare l'albero delle classi. E ovviamente hai il potenziale per le modifiche di un utente di sovrascrivere le modifiche di altri utenti.

Quindi avevo un problema simile. Visual Studio non riconosceva un percorso di rete che avevo mappato per una lettera di unità per nulla. La cosa divertente è che ha funzionato per un giorno. Ho impostato il mio progetto e ho iniziato a lavorarci su senza problemi. Poi, ho chiuso e il giorno dopo non funziona nulla. Non sono riuscito a leggere / scrivere file nel codice, a produrre i miei eseguibili o altro. Il mio progetto è locale ma il mio output era destinato a essere lanciato sulla rete.

Ad ogni modo, il problema riguarda probabilmente il contesto dell'amministratore, ma un modo per risolverlo, che ho scoperto mentre cercavo online, è far sì che Visual Studio possa navigare sull'unità in questione in qualche modo. Esistono molti modi per farlo, ma VS sarà magicamente in grado di riconoscere le lettere di unità mappate. La mia soluzione è quella di andare nella posizione di output del debug nelle proprietà del progetto, fare clic su Sfoglia e andare alla posizione di output precedentemente creata sul mio drive di rete e Voila !!!

Volevo metterlo su perché ho trascorso mezza giornata cercando di capirlo e ho pensato che avrebbe potuto salvare qualcun altro un po 'di tempo. Grazie mille e buona fortuna !!!

Erik

Di recente ho riscontrato lo stesso problema, quindi questa risposta è più utile per tenere traccia delle mie conoscenze. Comunque, se qualcuno lo trova utile, di seguito è riportato il problema e la soluzione.

Problema: Progetti NET 4.0, repository SVN, cartelle di checkout si trovano su unità locali, gli assembly di riferimento vengono creati dal server di build e disponibili su un'unità di rete. Visual Studio su W7 è in grado di aggiungere il riferimento ma non è in grado di creare progetti.

Soluzione: Poiché NET 4.0 non fornisce più automaticamente un sandbox per gli assembly di rete, è necessario renderli completamente attendibili tramite aggiornamento machine.config. http://msdn.microsoft.com/en-us/library/dd409252.aspx

Se ti capisco correttamente, i tuoi file di progetto di Visual Studio sono memorizzati sull'unità di rete e li stai eseguendo da lì. Questo è quello che faccio e non ho alcun problema. Dovrai assicurarti di aver impostato la politica di sicurezza. Puoi usare Caspol per fare questo, oppure tramite il menu degli strumenti di amministrazione del pannello di controllo.

Dovresti essere avvisato che alcune funzionalità di Visual Studio si rifiuteranno di funzionare con l'unità di rete.

Ad esempio, il file mdf dell'istanza utente di SQL Express deve trovarsi nell'unità locale.

Per un altro esempio, se usi il percorso UNC, devi assicurarti che siano abbastanza corti.

L'ho trovato utile durante il tentativo di utilizzare vc11 con paralleli che funzionano su Mac: http: //social.msdn .microsoft.com / Forums / it-US / toolsforwinapps / thread / 2ffdcb01-c511-4961-834b-afd5f2fbb8e1 , e in particolare:

1) È possibile passare dal debug locale al debug remoto e impostare il nome del computer come "localhost". Ciò eseguirà una distribuzione remota sul computer locale (quindi non utilizzando la directory del progetto). Non è necessario installare gli strumenti di debug remoto, né avviare msvsmon affinché funzioni su localhost.

Nel caso in cui ciò aiuti qualcun altro, ho dovuto fare i passaggi indicati qui per aggiungere la posizione della condivisione di rete a Windows zona intranet. In particolare, ho avuto problemi con Visual Studio in sospeso quando si apriva una soluzione su una condivisione di rete (ovvero utilizzando VMware Fusion e aprendo una soluzione dal disco rigido del mio Mac). Ho anche avuto problemi con PostSharp in esecuzione in questo scenario.

Ho avuto un problema simile con l'apertura di progetti Visual Studio su un'unità di rete e l'ho risolto creando un collegamento simbolico sul mio disco C: \ locale che punta alla directory UNC

per es.

mklink /D "C:\Users\Self\Documents" "\\domain.net\users\self\My Documents"

quindi puoi semplicemente aprire il progetto usando il percorso C: \ Users \ Self \ Documents \, invece del percorso UNC

(Devi stare attento, perché Visual Studio ti reindirizzerà automaticamente al percorso '\\ domain.net ..' se fai doppio clic sul link simbolico mentre navighi per il progetto. Ho dovuto copiare incollare il Percorso "C: \ Users \" per aprirlo con il percorso della lettera di unità)

" Come posso farlo funzionare? " Hai un paio di scelte:

Scelta A: 1. Riporta tutti i file sul tuo disco rigido locale 2. Implementare un tipo di software di backup sul computer 3. Testare detta soluzione di backup 4. continua a scrivere codice

Scelta B: 1. Ottieni una copia di uno dei prodotti di controllo del codice sorgente GRATUITO e implementalo. 2. Assicurarsi che venga eseguito il backup 3. Provalo

Scelta C: Utilizzare uno dei molti repository di controllo del codice sorgente ONLINE disponibili. Google, SourceForge, CodePlex, qualcosa del genere.

Bene, la mia domanda sarebbe perché lo stai chiedendo. Non funziona quando lo si memorizza su un'unità di rete? Non ho provato questo da solo, e un problema che potrei immaginare sarebbe che il codice .NET in esecuzione da un'unità di rete (cioè dalla directory bin \ Debug, anch'essa situata sull'unità di rete) sarebbe in esecuzione in modalità sandbox, a meno che non si scherzi con CASPOL (o usi 3.5 SP1 che ho sentito ha rimosso quell'ostacolo).

Se hai problemi specifici, chiedi di loro. Non chiedere mai & Quot; Perché X non funziona? & Quot ;.

Non stai dicendo se sei solo una o più persone che accedono alla stessa unità remota, ma suppongo che tu sia solo una per ogni directory di rete. È corretto? In caso contrario, no, non esiste un cerotto. Ottieni il controllo della versione, sposta i file su un disco locale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow