Compartilhando classes ou interfaces entre diferentes projetos

Eu estava procurando por algumas respostas no SO ou aqui, mas sem resultados, é por isso que gostaria de perguntar.

Vamos supor que eu tenha dois projetos diferentes - por exemplo, parte do servidor e parte do cliente de um aplicativo. Estou desenvolvendo minha própria parte, enquanto meu amigo está fazendo a segunda. Mas nós dois devemos usar algumas interfaces comuns como Userou AccountInfoou ChangableAccount... o que for, a fim de garantir uma compatibilidade. Por exemplo, se um cliente envia dados do Usuário ao servidor, o servidor deve operar na mesma classe. O mesmo com as interfaces etc. Além disso, se houver alguma alteração em uma interface comum, os dois projetos devem ajustar seu código à nova situação.

A única solução que posso ver agora é criar um projeto extra no qual todas as coisas comuns sejam definidas. Nós, eu e meu amigo, devemos adicionar este projeto como uma dependência a um projeto principal (cliente ou servidor). O projeto compartilhado pode ser gerenciado por algum sistema de controle de versão, portanto, sempre temos o estado mais atualizado.

Que outra solução você sugeriria? Como esses problemas são resolvidos em aplicativos profissionais?

criar um projeto extra no qual todas as coisas comuns são definidas

Este é exatamente o primeiro passo para compartilhar peças reutilizáveis ​​- e é a parte mais fácil. A parte mais desafiadora é decidir se os dois projetos que estão usando a biblioteca compartilhada devem ter ciclos de liberação independentes (ou não) e se deve ser possível que o "projeto A" use a versão 1.0 da sua lib compartilhada, enquanto o projeto B use versão 2.0 ao mesmo tempo .

Se você deseja que este último seja possível, você precisa ter um esquema de versão estrito e um gerenciamento de versão para sua biblioteca (e números de versão como parte do nome do arquivo da biblioteca, como sugerido pelo @RoryHunter). Você também deve cuidar da compatibilidade com versões anteriores em sua biblioteca nesta situação. Sua biblioteca deve ser gerenciada como um produto separado, adicionando testes de unidade a ela para garantir que as diferentes versões em produção sejam uma boa idéia, e uma ferramenta como o Maven também faça sentido.

Se, no entanto, você deseja evitar essa situação, você deve gerenciar o "projeto A", "projeto B" e sua biblioteca como um projeto comum, com um processo combinado de desenvolvimento, construção e liberação. Isso permitirá alterar a interface comum da biblioteca compartilhada com muito mais frequência e frequência do que no primeiro cenário. E você não precisará de algo como Maven ou números de versão no nome do arquivo da biblioteca. Mas a desvantagem é que A e B não podem mais ser desenvolvidos de forma independente.

Sua solução é a certa. Coloque o código compartilhado em outro projeto que construa seu próprio arquivo JAR e use-o nos dois projetos. Ao construir o arquivo JAR, você pode incluir a versão no nome, por exemplo, no estilo Debian;

libmyproject-shared-1.0.jar

Não evita problemas de controle de versão, mas deve ajudar. Eu nunca usei o Maven, mas entendo que ele pode ajudar nessa situação.

criar um projeto extra no qual todas as coisas comuns são definidas

É exatamente assim que a .Net espera que você faça isso.

Abstraia esses objetos em uma terceira montagem e faça referência a esses dois projetos. Sugiro fazê-lo como Interfaces, que é mais limpo, mas ...

Cuidado com a serialização:

• A única maneira de serializar / desserializar objetos diretamente entre os dois programas (reconhecidamente isso foi há algum tempo usando o Framework 2.0) foi instalar o assembly "compartilhado" no Global Assembly Cache nas máquinas cliente e servidor. Se a montagem era "local" para cada projeto, o Framework os via como Tipos discretos e recusava-se a des serializar uma na outra.
• E [de] serializar objetos digitados como interfaces é um "desafio". O original, sem tipo de interface, parecia não "passar" pelo "canal" de serialização, de modo que o receptor não sabia qual tipo concreto "construir" a partir do fluxo de entrada.

Como outros sugeriram, seu processo de pensamento é preciso. Profissionalmente, a maioria usaria algo como Maven ou Gradle para gerenciar essas dependências com eficiência.