martedì 18 dicembre 2012

File di metadati non è stato trovato in un percorso di soluzione con spazi evasi


Dopo un breve scambio di amichevoli ma accusatorio cross-continentali messaggi, ho imparato qualcosa di nuovo su progetti. NET oggi. Vorrei iniziare con i sintomi come questa è la prima cosa che ho su Google e come ho il sospetto gli altri troveranno questo e salvare se stessi un po 'di dolore in futuro.
Diciamo che una soluzione come questa:
Soluzione con due progetti
Si tratta di un marchio newie a destra, fuori dalla scatola per dimostrare il problema. I riferimenti web del progetto il progetto ClassLibrary come riferimento al progetto . In altre parole, il file di progetto contiene qualcosa di simile a questo:
< ProjectReference Include = " .. \ ClassLibrary \ ClassLibrary.csproj " >
  < progetto > {705479f2-2820-44ea-A983-f03c70ae0754} </ Progetto >
  < nome > ClassLibrary </ Nome >
</ ProjectReference >
Fin qui, tutto bene. Tuttavia, quando si va a costruire diventa decisamente infelice:
Costruzione di errore: file di metadati non è stato trovato in un percorso di soluzione
Ho provato tutti i trucchi abituali; pulire la soluzione, rimuovere quindi aggiungere il riferimento, la verifica diagnostica costruire produzione e, naturalmente, esercitato il lancio obbligatorio di abuso. Niente. Non sarebbe costruire in Visual Studio né sarebbe costruire dal comando in diretta via msbuild. L'errore circa la DLL mancante dal progetto di riferimento è rimasto.
Tuttavia, sarebbe costruire sul server di build. E sarebbe costruire sul computer di un collega. E sarebbecostruire sulla mia macchina. Semplicemente non costruire sulla macchina ho voluto.
Alla fine ho controllato di nuovo fuori del controllo del codice sorgente in un altro percorso sulla macchina originale e come su questo punto - ha costruito! Questo è quando sono emersi sospetti sul nome percorso, che era sfuggito spazi.
Ora gli spazi non sono il mio solito modo di nominare percorsi di soluzione e in spazi fatto a tutti sono un po 'di un no-no nel mio libro, perché esattamente questo genere di cose. Quello che era successo era che qualcun altro (no, davvero, questo non è uno di quelli "Ho un amico con un problema" le cose, è veramente stato qualcun altro) aveva deciso di assegnare un nome al percorso di questa soluzione esiste all'interno di Subversion con una spazio. Nel tentativo di fornire una certa assistenza veloce con un problema, avevo semplicemente navigato il percorso nel browser (grazie VisualSVN Server ), e copiare l'URL. Il browser aveva giustamente sfuggito il percorso per il contesto URL in modo gli spazi sono stati convertiti in un 20%.Quando poi ho incollato il percorso su TortoiseSVN per il check-out, la convenzione di denominazione predefinita creato la directory checkout con lo stesso nome del URL del repository ed è lì che tutti i problemi sono iniziati.
È interessante notare che Visual Studio è piuttosto esplicito circa la sua antipatia per il carattere di escape (o più precisamente, il carattere%) se si tenta di creare una nuova soluzione contenente il carattere incriminato:
Caratteri non consentiti in una nuova soluzione di Visual Studio
E 'un peccato che non si può anche dire che quando si apre un esistente soluzione! Ma ciò che, inoltre, non vi dirà è che se si crea una nuova soluzione in un percorso che già contiene un carattere non valido, lo stesso errore di compilazione si verificherà. Soluzione di novità, avete appena inserito da qualche parte sotto un nome di cartella ostile. Piuttosto confuso, se mi chiedete.