Errore di Compilazione di un Programma in Visual Studio 2008

Question

Non ho mai visto questo problema prima e non so da dove iniziare a risolvere il problema.

Cannot register assembly "obj\Debug\MyProject.Vsto.dll".
Loading this assembly would produce a different grant set from other instances. 
(Exception from HRESULT: 0x80131401)  

Dove posso iniziare a risolvere questo?

Vorrei ricordare che questo è un VS2008 ambiente con VS2008 SP1 e questa soluzione è:
1.Un VSTO Progetto Excel 2007 (C#)
2.Di Accesso ai Dati / Livello di Servizio DLL (C#)
3.Un MbUnit progetto di test per il #2 (C#)

AGGIORNAMENTO: Devo aggiungere questo ha funzionato bene per diversi mesi.L'unica cosa che ho cambiato nell'ultima settimana o così ho iniziato a lavorare sul codice via di Team Foundation Server (TFS).

AGGIORNA 2: Eliminare il .suo file lavorato per un po'.Ora ho trovato lo stesso errore di nuovo....hmmm.Immagino che ti chiudere il progetto di eliminare il .suo di nuovo.

AGGIORNA 3: VS2008 mi permetterà di compilare la soluzione di una volta.La seconda volta che provo mi esce l'errore.Se esco, eliminare il .suo file, e riaprire posso compilare una sola volta.Ogni pensiero per la causa?È questo un 2008 SP1 cosa?

Per il bounty sto cercando la soluzione permanente.

Answer 1

Proprio A proposito ... che sembra un HRESULT CLR (il 13 al centro indica che). Tronchi con a questo post del blog: Un sacco di codici HRESULT ... quella specifica HRESULT è SECURITY_E_INCOMPATIBLE_SHARE 0x80131401 -2.146,233343 millions

Molto probabilmente qualche processo errante è in possesso di un handle aperto sul gruppo e prevenire il compilatore da che prevede una nuova. Dato update # 3 che processo è probabilmente devenv.exe ... che è inutile in restringendo il campo, tuttavia potrebbe essere qualche processo in background che spegne con VS (come ad esempio il processo di debugger hosting).

Supponendo che qualcosa sta tenendo sul file per eseguire il debug ... questo tipo di cose il primo passo è quello di aprire procexp.exe da SysInternals set di strumenti. In esso è possibile utilizzare Trova per determinare quale processo ha un handle aperto per il file. Mi aspetto per mostrare un manico aperto all'interno devenv.exe quando si colpisce questo problema.

Da dentro Procexp si può fare la cosa molto pericolosa della chiusura del manico. Dopo di che provare di nuovo i passi senza spegnere. Se il problema non si repro poi si sa la maniglia è stata chiusa è stata la causa del problema. Se qualsiasi altra cosa succede così ... che 'altamente pericolosa' passo è stato probabilmente la causa.

Se si sa quale processo ha la maniglia aperta allora avete bisogno di vedere se è possibile evitare che colpire la perdita apparente del manico. Vorrei controllare le impostazioni del progetto ... compresi quelli di debug per tutto ciò che copia i file. Se c'è un ambiente debugger chiamato processo VSHosting ... spegnerlo.

In bocca al lupo.

Answer 2

Ho fatto qualche usare Google e ho trovato questo post su MSDN che può (o non può) essere utile a voi.

Si parla di un paio di patch di aggiornamenti Windows che dovrebbero essere installati (se siete su Vista), così come una soluzione se siete su XP. Anche se il posto si riferisce a problemi con Silverlight ... l'errore è lo stesso, quindi forse?

In bocca al lupo!

Answer 3

Non ho visto che l'errore esatto, ma errori simili si possono verificare se c'è un altro copia della DLL che viene caricato da una posizione diversa.

mi piacerebbe fare una ricerca per vedere se ci sono altre copie di quel DLL in giro

dir MyProject.*.dll /s

Answer 4

Così si crea la DLL, ma non piace usarlo dopo? Se questo è il caso, hanno si è tentato di aprire le DLL in Reflector per vedere quali differenze ci potrebbe essere tra la prima e la seconda compilation?

Un altro pensiero - Hai provato un pulito / ricostruzione dopo la prima build di successo? Si stanno aggiornando i numeri di versione su ogni compilazione? Mi chiedo se un file obsoleto viene fatto riferimento, ma aggiornato dopo la prima compilazione. A quel punto i riferimenti non corrispondono a quelli attesi.

Un altro pensiero casuale - il file .suo generalmente contiene informazioni relative alla vostra singola macchina. Qualcosa connesso alla compilazione non deve essere salvato in quel file - si dovrebbe andare al .sln invece. Sembrerebbe strano che il .suo è la causa principale ...

Answer 5

sembra che si sviluppa un ms - office estensione.Quindi è necessario installare l'ultima versione COM Spessore Guidata.Download per VS2008 è qui.

Office gestito le estensioni devono essere isolate le une dalle altre. Questo articolo su MSDN spiega come e perché.

Presumo che il tuo .dll non è isolato, e quindi il vostro get "la Sicurezza-condividere-errore":

L'isolamento. Se non si utilizza un COM standard spessore (come il Visual Studio Tools per Office loader) o personalizzato COM shim, estensione DLL viene caricata in default dominio di applicazione, insieme con tutti altre agenzie delle nazioni unite-spessorato estensioni.Tutte Le Dll in esecuzione nello stesso dominio di applicazione sono vulnerabili a danni potenziali causati da qualsiasi altro DLL nella stessa dominio di applicazione.Inoltre, qualsiasi onu-spessorato add-in che si blocca in un applicazione host disattiva tutti gli altri onu-spessorato aggiuntivi per che applicazione.

Lo sviluppo di office estensioni sembra così semplice all'inizio, ma poi ....

Thomas

Answer 6

Ho visto questo thread che sembra evidenziare alcune questioni affini.

come risolvere i problemi? Direi primo controllo che, se la vostra applicazione potrebbe generare questo tipo di messaggio di errore. Poi controllate se le librerie o sistema il software si basa su potrebbero essere difettosi (poi chiedere per il supporto o il sostegno della comunità).

In bocca al lupo.

Answer 7

Questo è un po 'fuori dalla mia zona, ma ho trovato la seguente Link che suggerisce che si è verificato un difetto noto con .net 2.0.

Ho copiato quanto segue dal suggerito work-around da Microsoft:

  

Il problema si verifica quando il marshalling   un oggetto valore tra due   AppDomain nello stesso processo in cui   il tipo dell'istanza è generico,   il tipo di modello generico è definito   in mscorlib, uno o più dei suoi   instantiating tipi non è definita   mscorlib e multi-dominio loader   l'ottimizzazione è stata abilitata in uno   dominio ma non l'altro.

     

Purtroppo questo bug è stato scoperto   troppo tardi e non ha fatto il bar per   il prodotto V2.0. Ci sono alcuni   soluzioni temporanee però:

     

Questo bug è specifico per un ottimizzato   versione della in-process,   canale remoting cross-appdomain e   pertanto può essere evitato commutando   questa ottimizzazione off per il processo.   Ciò può essere ottenuto sia modificando   la seguente variabile di ambiente   nella finestra di comando in cui il test   saranno eseguiti:

set complus_UseNewCrossDomainRemoting=0

     

o impostando il   HKEY_CURRENT_USER \ Software \ Microsoft.NETFramework \ UseNewCrossDomainRemoting   valore di registro (un valore DWORD) a 0 (o la   Versione in HKEY_LOCAL_MACHINE).

     

Questi sono un po 'pesante, ma è   inoltre possibile ingannare il ottimizzato   percorso in evitando solo la specifica   nomina che trasferisce la problematica   oggetto. Per fare questo aggiungere un manichino fuori   parametro per la chiamata (per vari   ragioni tecniche il percorso ottimizzato   non implementa out parametri ancora).

     

Si può anche evitare di utilizzare un mscorlib   tipo generico definito. Nel Repro   caso presentato questa è abbastanza semplice   dal momento che si può solo sottotipo di listino:

[Serializable]
public class MyList<T> : List<T>
{
}

     

(Basta sostituire tutti gli usi di List con   MyList).

     

Infine, il problema non dovrebbe verificarsi   se entrambi AppDomain utilizzano il   ottimizzazione multi-dominio. Non è possibile   impostare il caricatore del dominio predefinito   ottimizzazione dopo sei già   in esecuzione, ma è possibile impostarlo   esternamente (Credo tramite   API di hosting non gestito o un config   presentare, anche se non sono un esperto in   o, sorry) o mediante la creazione di un nuovo   dominio (con opt multi-dominio) entro   il codice e il trasferimento di controllo per   (tramite una chiamata su un oggetto in MBro   quel dominio).

Scusa se hai già trovato questo articolo nella vostra ricerca, ma non ho visto ha offerto qui come una soluzione.

Answer 8

Non stai scherzi con il tempo di sistema sei? Facendo che può rovinare le vostre assemblee.