Questa domanda ha pertinenza al di là del mio caso, perché chiunque abbia un'applicazione localizzata e deve consegnare un file EXE autonomo presenta questo problema: vorranno usare ILMerge (o Costura o qualche soluzione homebrew) per mettere le DLL di localizzazione (o qualsiasi altro assembly) nel loro EXE, ma una volta fatto ciò, non possono più eseguire il debug del loro codice. Il debugger VS rifiuterà semplicemente di accettare il file PDB originale generato per l'EXE originale, presumibilmente perché il passo ILMerge aggiorna il checksum o cambia il GUID.Un modo per far sì che VS (2010) accetti i PDB dopo aver utilizzato ILMerge/Costura per combinare gli assiemi?
Quello che mi chiedo è se c'è un modo per aggirare questo .. come qualche opzione ILMerge poco conosciuta, forse? Mi sembra una perdita di debug molto comune e inutile.
Credo che l'unico altro modo per eseguire il debug di questa app dopo la localizzazione sia mantenere un'opzione di compilazione parallela che utilizza le DLL non-ILMerged, il che va bene, a meno che non si desideri eseguire il debug del codice di localizzazione stesso (ad esempio , io) .. allora sei davvero sfortunato. Qualcuno può pensare ad altre opzioni?
Ho anche provato a utilizzare Costura, ma poiché le DLL di localizzazione contengono tutte risorse identificate in modo identico (e identiche alla risorsa principale AppName.resource), è possibile aggiungere solo una di queste DLL ai Riferimenti: quelle successive non sono consentite . C'è un modo per ingannare Costura per lavorare? (se potrebbe essere fatto funzionare, il problema del PDB potrebbe non verificarsi poiché la combinazione fa parte della build dello studio visivo ..?)
Modifica: Sto cercando idee che risultano in un file PDB/EXE incontro. Mi rendo conto che puoi hackerare il pdb in un editor esadecimale. La domanda specifica in particolare sui modi per far sì che il sistema funzioni come previsto.