O .NET equivalente a bibliotecas estáticas?

Question

Estou construindo uma ferramenta no código gerenciado (principalmente C ++/CLI) em duas versões, uma versão do 'usuário normal' e uma versão 'Pro'.

O fato de o código principal ser idêntico entre as duas versões me causou um pequeno problema, pois quero empacotar a ferramenta resultante como uma única montagem (DLL) e não quero incluir os arquivos .cpp para o comum Código nos projetos das duas versões das ferramentas. Prefiro ter um projeto para o código comum e um projeto para cada versão da ferramenta e ter cada versão do projeto Ferramentas depende do código comum e vinculá -lo conforme desejado.

No C ++ não gerenciado, eu faria isso colocando o código comum em uma biblioteca estática e vinculando as duas versões da ferramenta a ele. Parece que não consigo fazer isso funcionar no C ++/CLI. Parece que sou forçado a construir o código comum em uma montagem de DLL e isso resulta em mais DLLs do que gostaria.

Portanto, em resumo, não consigo descobrir como criar o código comum em um projeto e vinculá -lo a cada um dos projetos finais de produtos para produzir dois assembléias de DLL única que incluem o código comum.

Provavelmente estou fazendo algo errado, mas tentei descobrir como fazer isso usando netmodules e o que quer que seja, e simplesmente não consegui fazê -lo funcionar. No final, a única maneira de fazer isso funcionar foi dizer ao vinculador para vincular os produtos de construção da montagem de código comum, em vez dos resultados que funcionam, mas é um pouco de um hack IMHO.

De qualquer forma, alguém tem alguma sugestão de como eu deveria resolver esse problema?

Editado: Acho que deveria ter mencionado o fato de que os assemblies gerados não são 100% gerenciados, eles contêm uma mistura de código gerenciado e não gerenciado como é, provavelmente, bastante comum com os conjuntos produzidos com C ++/CLI ...

Answer 1

Se você estiver irritado em todas as DLLs, faça o download Ilmerge. Eu uso isso para agrupar várias DLLs em um .exe fácil de usar para meus clientes.

Answer 2

Como disse Ilmerge, é uma maneira, pessoalmente se você estiver com um pouco de exe com muitas DLLs, eu favorece Netz.

Answer 3

Você poderia usar módulos. Você pode vinculá -los a uma montagem usando o vinculador de montagem, al.exe.

Answer 4

Se estou entendendo isso corretamente, você tem uma solução que contém dois projetos. Um projeto para o usuário "normal" e um projeto para o usuário "Pro". O Visual Studio permite adicionar um "link" a outra fonte de arquivo de outro projeto. Se a sua versão "Pro" tiver o arquivo de código principal real e na sua versão "normal", você adiciona existente -> Encontre o arquivo no projeto "Pro" e clique na seta para baixo pelo botão Adicionar e selecione "Adicionar como link ". Agora você tem um único arquivo que é literalmente o mesmo entre dois projetos.

Answer 5

Essa é a desvantagem do processo de compilação .NET, você não pode ter coisas como bibliotecas estáticas e os arquivos de cabeçalho que os mantêm juntos, tudo é mantido em um grande arquivo DLL e a única maneira de compartilhar informações é construir uma DLL comum e faça referência a outros assemblies ou para duplicar o código em cada DLL (possivelmente copiando/vinculando arquivos .cs entre os projetos).

Observe que a segunda maneira declarará diferentes tipos, mesmo que eles tenham o mesmo nome. Isso o morderá na bunda com coisas como remoção (ou qualquer coisa que exija fundição para interfaces compartilhadas específicas entre os processos).

Answer 6

Salamandra de Remotesoft irá conectá -lo. É basicamente um compilador e vinculador nativo.

Answer 7

Ao usar mono (ou cygwin é uma opção) mkbundle Também pode ser uma escolha válida.