Persistente assemblea di dipendenza in C# .NET

Question

Il mio progetto C# - la chiameremo la SuperUI - usato per fare uso di una classe da un assembly esterno.Ora non è più così, ma il compilatore non mi permette di costruire il progetto senza il riferimento a un assembly in luogo.Vorrei approfondire.

Questo progetto ha utilizzato per il lancio e la cattura di un'eccezione personalizzata di classe - il SuperException - che è stato derivato dal Sistema standard.Eccezione e vissuto in un separato, precompilato assemblea, SuperAssembly.DLL, cui ho fatto riferimento.

Alla fine, ho deciso che questo era un esercizio sterile e sostituito tutti SuperExceptions con un Sistema di.SuitableStandardException in ogni caso.Ho rimosso il riferimento al SuperException.DLL, ma ora sono incontrato con il seguente cercando di compilare il progetto:

Il tipo 'SuperException' è definito in un'assemblea che non fa riferimento.È necessario aggiungere un riferimento all'assembly 'SuperException, Version=1.1.0.0 (...)'

Il file di origine a cui fa riferimento l'errore non sembrano pertinenti;e ' il progetto dello spazio dei nomi che viene evidenziato nell'IDE.

Ora, qui è la cosa:

1. Tutti gli usi di SuperException sono stati eliminati dal codice del progetto.
2. Rispetto ad un altro progetto che raccoglie bene senza un riferimento a SuperException.DLL, Ho solo riferimento a una più per l'assemblaggio e il that riferimenti nulla che il mio progetto non fa riferimento a se stessa.Mentre è possibile che una qualsiasi di queste dipendenze potrebbe gettare SuperExceptions, Sto solo recuperando l'Eccezione base di classe e, in ogni caso...l'altro progetto costruisce bene!
3. Ho fatto di Visual Studio "Puliti" e cancellato tutto a mano, molte volte.

Non è la fine del mondo, per includere questo riferimento, non vedo il motivo per cui è più necessario.Nrrrgg.Tutti i puntatori benvenuto!!!!

Answer 1

E ' probabile che una transitivo di riferimento, in cui un certo tipo di chiamata del metodo restituisce un'istanza di SuperException boxed ("abbattuto") come ad es.Eccezione, ma dall'analisi del codice in modo transitivo incluso il codice, cioècodice da esterno chiamate di metodo, il compilatore sa che avete bisogno di essere in grado di avere informazioni su che tipo a un certo punto.

Resharper vorrei dirti dove è il caso in cui è necessario aggiungere un riferimento, e si potrebbe utilizzare Lütz Roeder dell'aka RedGate del Riflettore per la scansione compilato IL per un riferimento di questo tipo in due modi:1) utilizzare la ricerca di-impianto, 2) aprire ogni tipo di pubblico che si sta utilizzando e che richiede il "fantasma" di assemblaggio, vi verrà chiesto di specificare la sua posizione.

Questo più spesso accade a me quando mi Castello di riferimento.Windsor, ma non a Castello.MicroKernel.:p

Answer 2

1. L'Uscita Di Visual Studio
2. Eliminare il bin e obj Cartelle nella soluzione directory
3. Riavviare e vedere cosa succede

Answer 3

Sono d'accordo con gli altri commenti qui..C'è un riferimento, in testo normale da qualche parte !Ho avuto problemi simili in passato, dove la ricerca attraverso i file di progetto restituito nulla, scopre che è stato in qualche altro file che non automaticamente raccolti nella ricerca.

Non credo che la creazione di un nuovo progetto, è la soluzione qui..Hai bisogno di essere positivo che NESSUNO i riferimenti nel vostro albero di dipendenze utilizzare SuperException.. NESSUNO

Non ho mai sperimentato al punto in cui ho bisogno letteralmente di pulire il progetto, ho sempre trovato il riferimento da qualche parte.Garantire che stai cercando ogni file.

EDIT:

Solo un punto da aggiungere, se il percorso a cui punta l'errore sembra casuale, che spesso significa che c'è un disallineamento tra la sorgente compilato e il file di codice sorgente..È questo un ASP.NET applicazione?Ho avuto prima dove compilato DLL non è stato sostituito su una ricostruzione in ASP.NET cartella temp causando di ottenere le cose..Interessante quando il debug :)

Answer 4

Non credo che questo è un problema di codice.Quello che vedo che succede è che uno dei tuoi riferimenti esistenti probabilmente fare affidamento su quel tipo nel loro genere, che probabilmente si sta creando nella vostra applicazione.

Se questo è il caso, è necessario che il riferimento, anche se non si utilizza esplicitamente il tipo e la anche se gli altri assembly di riferimento ha il proprio riferimento.A volte puoi avere il problema con 3 componenti di terze parti che hanno bisogno di riferimenti a tipi che non hai fatto riferimento.Il compilatore è, ovviamente, di vedere qualcosa in uno esistente assembly di riferimento e aspetta a cui fa riferimento il dipendente di uno.

Answer 5

Poiché si tratta di un errore del compilatore, ci deve essere un riferimento o l'uso di SuperException da qualche parte nel progetto.

1. Fare un trova/sostituisci l'intero progetto o di una soluzione per il tipo e rimuovere ogni riferimento (è possibile che tu già fatto).
2. Se si fa riferimento a qualsiasi tipo che eredita da SuperException (anche se il tipo definito in un altro assembly), è necessario un riferimento all'assembly che SuperException è definito.

Prendere la linea che il compilatore viene visualizzato l'errore e avviare la registrazione, l'eredità albero degli oggetti utilizzati su quella linea, si potrebbe trovare l'origine di questo modo.

Answer 6

Grazie per le vostre risposte finora.Ho provato ogni suggerimento (tranne uno) senza alcun risultato.

Il suggerimento non ho provato è quello di creare un nuovo progetto e aggiungere tutte le mie cose, il pensiero che davvero le prove la mia voglia di vivere.;) Posso provare domani se posso essere disturbato.Grazie di nuovo.

Answer 7

Non c'è davvero niente di misterioso VS progetti al giorno d'oggi tutti i file di testo, etc.QUALCOSA deve fare riferimento alla classe/dll, e che qualcosa deve essere parte del progetto.

Hai davvero grep d o findstr piacerebbe l'intero albero delle soluzioni, ogni singolo file, per un riferimento a tale eccezione?

Answer 8

Questo suona piuttosto strano.Ecco cosa vorrei verificare avanti:

1. Verificare che non c'è niente di persistente nella vostra Proprietà/AssemblyInfo.cs file.
2. Verificare che non c'è niente di persistente nel vostro SuperUI.csproj file.
3. Eliminare tutti i riferimenti e aggiungerlo nuovamente.

Answer 9

Prova a creare un nuovo progetto, e l'aggiunta di tutte le classi ad esso.

Answer 10

grep cartella del progetto.Potrebbe essere un riferimento nascosto nel progetto, un progetto che i riferimenti del progetto.Pulire con il blocco note, se necessario.

Answer 11

Se si fa riferimento a qualsiasi tipo che eredita da SuperException (anche se il tipo definito in un altro assembly), è necessario un riferimento all'assembly che SuperException è definito.

Distaccato su questo.

Potrebbe non essere di riferimento SuperException, ma si potrebbe essere di riferimento SpecializedSuperException, che è derivato da, o in qualche modo altrimenti usa SuperException - il grep di progetto per SuperException non sarà la cattura di esso, però.

Provare un hack con la prova di NDepend

Answer 12

Questo è dove strumenti come Resharper davvero pagare -- semplice Trovare Usi di solito mi dice di "ghost dipendenze" più volte.

Forse si potrebbe andare per la vostra definizione della SuperException classe e cercare di Trovare Tutti i Riferimenti().Si potrebbe anche voler indagare se l'assemblea SuperException ha un dipendenza circolare principale di montaggio (ad es., assieme principale dipende eccezione di montaggio dipende dal assembly principale...).

Answer 13

Ho avuto un simile riferimento a un assembly problema che stava accadendo, quando la mia libreria di C# era un dipendente C++/CLI assemblea.Il problema che mi fu ereditare una classe pubblica che C++/CLI assemblea nel mio C# assemblea biblioteca.Il che significa che la catena di ereditarietà, era che si estende su più assemblee.

Speravo che qualsiasi client dovrebbe essere abbastanza intelligente indirettamente a carico di C++/CLI assemblea in qualsiasi momento la libreria di C# necessarie, ma che non era il caso, anche in fase di compilazione.

Mi sono liberato di questo problema, rompendo l'ereditarietà tra le classi che sono stati estende tra quei due assieme biblioteche e l'utilizzo di aggregazione, invece.Il mio cliente era finalmente felice e non richiedono la C++/CLI assemblea come una dipendenza più.

Nella tua parola si sarebbe probabilmente necessario assicurarsi che SuitableStandardException non si eredita da SuperException al fine di eliminare le SuperException.DLL come riferimento.

Utilizzare l'incapsulamento invece di successione e di creare un SuperException il membro dei dati nel nuovo SuitableStandardException.

Se non si risolve, si potrebbe avere più classi di spanning ereditarietà attraverso alcune assemblee, nel tuo caso SuperAssembly.DLL e superException.dll.

Se non è possibile trovare tutti provare questo trucco:

1. Rendere tutti i vostri membri pubblici e classi SuperAssembly.DLL interno.

2. Nel SuperAssembly.DLL fare amicizia con SuperException.DLL:

   [assembly:InternalsVisibleTo("SuperException, PublicKey=0024000004800000....)]
   

3. Assicurarsi che costruiscono e rimuovere il SuperAssembly.DLL di riferimento da qualsiasi client che già i riferimenti SuperException.DLL.

Answer 14

grep -R SuperException * alla base del progetto (ottenere grep da qualche parte prima) solo per essere sicuri.