Silverlight resource dll build prevention

Question

Quando si genera un'applicazione Silverlight, viene sempre generato un intero gruppo di dll di risorse di localizzazione in \bin\de\\bin\es\\bin\fr\ ecc. (Che può finire impacchettato nel .xap). Questo è meraviglioso ma non sto usando questi, non sono necessari per far funzionare l'app e stanno ingombrando la radice del nostro server di costruzione TFS.

Mi rendo conto che c'è un piccolo bug con TFS 2K8 che è facilmente risolvibile per garantire che questi file non vengano scaricati nella radice del server di build, tuttavia ciò che vorrei idealmente è impedire che questi file vengano mai generati.

Ho provato tutto sotto il sole per impedire la creazione di questi file. Perché in realtà non esistono prima del tempo di costruzione, non posso dire loro di non produrre.

Ho trovato tonnellate di informazioni sulla localizzazione/globalizzazione, su come funzionano questi file e su molti modi per manipolarli, ma nulla su come impedire che vengano creati in primo luogo.

Qualcuno sa di un modo in cui posso impedire che vengano visualizzati in \ bin \ on build? C'è un interruttore che posso usare nelle opzioni di compilazione o qualcosa di simile?

Modifica. Voglio un modo per PREVENIRE questo evento. Può essere ripulito con eventi post-build ma non è l'ideale.

Answer 1

Che ne dici di utilizzare un passaggio di post-produzione per pulire ciò che non ti serve? Per fare ciò: fare clic con il tasto destro del mouse sul progetto -> Proprietà -> Crea eventi Rispetto alla generazione del post è possibile utilizzare i comandi della riga di comando standard di Windows.

Answer 2

Nel caso in post-costruzione:

rmdir /Q /S $(TargetDir)de 
rmdir /Q /S $(TargetDir)fr 
rmdir /Q /S $(TargetDir)it 
rmdir /Q /S $(TargetDir)ja 
rmdir /Q /S $(TargetDir)ko 
rmdir /Q /S $(TargetDir)zh-Hans 
rmdir /Q /S $(TargetDir)zh-Hant 
rmdir /Q /S $(TargetDir)es 

Answer 3

Se si guarda in queste cartelle dopo si genera il progetto si vedrà un po 'di DLL e/o file di risorse in loro. Le DLL/risorse che vedi nella cartella sono ciò che sta causando la generazione delle cartelle stesse. Poiché si fa riferimento a queste DLL nel progetto, quando si crea il progetto, il riferimento acquisisce quei file dalla cartella SDK (o da qualsiasi punto di riferimento).

Quindi, ad esempio, se si guarda System.Windows.Controls.dll che verrà installato nella cartella% ProgramFiles% \ MicrosoftSDKs \ Silverlight \ v3.0 \ Libraries \ Client. In quella cartella vedrai le stesse cartelle generate durante la compilazione (de, fr, it, ecc.). Quindi per evitare che vengano generati puoi fare un paio di cose.

1) Copiare la DLL in una cartella separata e fare riferimento a tale file. Ho dovuto rimuovere la DLL dalla cartella sdk perché il riferimento funzionasse in VS 2010, non sono sicuro che il riferimento verrà corretto nel 2008.

2) Rinominare o rimuovere i file e le cartelle globali dallo stesso SDK . Ciò influenzerebbe tutti i progetti, non solo il tuo singolo progetto, ma potrebbe risolvere il problema per te.

Buona fortuna!

Answer 4

ho risposto questo in un altro thread StackOverflow: Language folders for Silverlight projects when building with Team Build

Aprire Esplora risorse. Vai a C: \ Programmi \ Microsoft SDK \ Silverlight \ v4.0 \ Libraries \ Client. (C: \ Programmi (x86) \ Microsoft SDK \ Silverlight \ v4.0 \ Libraries \ Client \ se si esegue Windows a 64 bit). In quella posizione, vedrai un sacco di cartelle linguistiche/culturali.

• Creare una nuova cartella. Ho chiamato il mio "Culture inutilizzate".
• Sposta tutte le cartelle della cultura che non si desidera utilizzare nella nuova cartella. Assicurati di NON spostare la cartella "Design", che appare nel mezzo delle cartelle cultura nell'elenco delle cartelle.
• Nel progetto, eliminare i contenuti delle cartelle Raccoglitore, Rilascio, ecc. . Ricostruire.
• Quando si desidera aggiungere il supporto per un'altra cultura, è sufficiente spostare il quello che si desidera tornare alla posizione originale.

Ogni volta che si ottiene un aggiornamento per l'SDK di Silverlight, probabilmente si dovrà farlo di nuovo.