Condivisione di classi o interfacce tra diversi progetti

create a one extra project in which all common things are defined

Questo è esattamente il primo passo per condividere parti riutilizzabili - ed è la parte facile. La parte più difficile è decidere se i due progetti che utilizzano la libreria condivisa devono avere cicli di rilascio indipendenti (o meno), e se dovrebbe essere possibile che "progetto A" utilizzi la versione 1.0 della tua lib condivisa, mentre il progetto B usa versione 2.0 allo stesso tempo .

Se si desidera che quest'ultimo sia possibile, è necessario disporre di uno schema di controllo delle versioni rigoroso e di una gestione del rilascio per la libreria (e numeri di versione come parte del nome del file della libreria, come suggerito da @RoryHunter). In questa situazione dovresti anche preoccuparti della retrocompatibilità della tua lib. La tua biblioteca dovrebbe essere gestita come prodotto separato, aggiungendo test unitari per assicurarti che le diverse versioni in produzione siano una buona idea, e anche uno strumento come Maven può avere senso.

Se, tuttavia, vuoi prevenire quella situazione, dovresti gestire "progetto A", "progetto B" e la tua lib come un progetto comune, con un processo combinato di sviluppo, costruzione e rilascio. Ciò consentirà di modificare l'interfaccia comune della libreria condivisa molto più spesso rispetto al primo scenario. E non avrai bisogno di qualcosa come Maven o numeri di versione nel nome del file della libreria. Ma il compromesso è che A e B non possono più essere sviluppati indipendentemente.

La tua soluzione è quella giusta. Inserisci il codice condiviso in un altro progetto che crea il proprio file JAR e utilizzalo in entrambi i progetti. Quando si crea il file JAR, è possibile includere la versione nel nome, ad es. in stile Debian;

libmyproject-shared-1.0.jar

Non impedisce problemi di versionamento, ma dovrebbe aiutare. Non ho mai usato Maven, ma capisco che può aiutare in questa situazione.

create a one extra project in which all common things are defined

Questo è esattamente il modo in cui .Net si aspetta che tu lo faccia.

Estrarre questi oggetti in una terza Assemblea e fare riferimento a entrambi i progetti. Suggerirei di farlo come interfacce, che è più pulito, ma ...

Attenzione per la serializzazione:

• L'unico modo per serializzare / deserializzare direttamente gli oggetti tra i due programmi (ammettiamolo era mentre fa usando Framework 2.0) era installare l'assembly "condiviso" nella Global Assembly Cache su entrambi macchine client e server. Se l'assembly era "locale" per ciascun progetto, il Framework li vedeva come tipi discreti e si rifiutava di [serializzare] l'una nell'altra.
• E la [de] serializzazione di oggetti digitati come interfacce è un po 'una "sfida". Il tipo non-Interface originale non sembrava "renderlo" attraverso la "pipa" di serializzazione, quindi il ricevitore non sapeva quale tipo concreto "costruire" dal flusso in arrivo.

Come altri hanno suggerito, il tuo processo di pensiero è accurato. Professionalmente, la maggior parte userebbe qualcosa come Maven o Gradle per gestire queste dipendenze in modo efficiente.