Qual é a diferença entre um projeto compartilhado e uma biblioteca de classes no Visual Studio 2015?


240

Eu estava estudando bastante os novos recursos do Visual Studio 2015 e o Projeto Compartilhado, mas não entendo como é diferente usar uma Biblioteca de Classes ou uma Biblioteca de Classes Portátil. Alguém pode explicar?

Editar: Projeto Compartilhado é um novo recurso do Visual Studio 2015 e é diferente de uma Biblioteca de Classes Portátil. Entendo o que é uma Biblioteca de Classes Portátil. O que estou tentando entender é como um projeto compartilhado difere de uma biblioteca de classes. Veja o link abaixo.

http://www.c-sharpcorner.com/UploadFile/7ca517/shared-project-an-impressive-features-of-visual-studio-201/


Respostas:


238

A diferença entre um projeto compartilhado e uma biblioteca de classes é que o último é compilado e a unidade de reutilização é a montagem.

Considerando que, com o primeiro, a unidade de reutilização é o código-fonte e o código compartilhado é incorporado a cada assembly que faz referência ao projeto compartilhado.

Isso pode ser útil quando você deseja criar montagens separadas direcionadas plataformas específicas , mas ainda possuem código que deve ser compartilhado.

Veja também aqui :

A referência do projeto compartilhado aparece no nó Referências no Solution Explorer, mas o código e os ativos no projeto compartilhado são tratados como se fossem arquivos vinculados ao projeto principal.


Nas versões anteriores do Visual Studio 1 , era possível compartilhar o código-fonte entre os projetos em Adicionar -> Item Existente e depois escolher Vincular. Mas isso era meio desajeitado e cada arquivo de origem separado precisava ser selecionado individualmente. Com a mudança para oferecer suporte a várias plataformas diferentes (iOS, Android etc.), eles decidiram facilitar o compartilhamento de fontes entre projetos, adicionando o conceito de Projetos Compartilhados.


1 Esta pergunta e minha resposta (até agora) sugerem que os Projetos Compartilhados eram um novo recurso do Visual Studio 2015. De fato, eles fizeram sua estréia no Visual Studio 2013 Update 2


1
Digamos que dois projetos façam referência ao mesmo projeto compartilhado. Se um deles adicionar uma referência ao outro, você recebe erros de declaração de tipo duplicados?
Asad Saeeduddin

3
@ Asad - eu não verifiquei, mas eu espero que não. Você pode ter dois tipos distintos, com os mesmos nomes, e declarados dentro dos mesmos espaços para nome, mas existentes em diferentes assemblies. Isso não é um erro, por si só.
Damien_The_Unbeliever

Eu tinha exatamente a mesma pergunta do OP em 2017, mas desde que temos o .net padrão 2.0 agora. Os projetos compartilhados agora não estão obsoletos? Se você criar um novo aplicativo da Web ou uwp hoje?
JP Hellemons

1
@JPHellemons - .net padrão é bom - mas se você precisar ir além disso por qualquer motivo (por exemplo, se houver funcionalidade disponível apenas em plataformas específicas ), um Projeto Compartilhado ainda poderá ser uma abordagem decente.
Damien_The_Unbeliever

1
Dizemos que em um projeto compartilhado podemos compartilhar arquivos Javascript. Como usamos isso em um bundleConfig?
Leth

34

Encontrei mais algumas informações deste blog .

  • Em uma biblioteca de classes, quando o código é compilado, os assemblies (dlls) são gerados para cada biblioteca. Porém, com o Projeto compartilhado, ele não conterá nenhuma informação de cabeçalho; portanto, quando você tiver uma referência ao Projeto compartilhado, ele será compilado como parte do aplicativo pai. Não haverá dlls separadas criadas.
  • Na biblioteca de classes, você só pode escrever código C # enquanto o projeto compartilhado pode ter algo como arquivos de código C #, arquivos XAML ou JavaScript, etc.

7
uma biblioteca de classes também pode ter .xaml (User Controls)
Default

21

Diferenças breves são

1) O PCL não terá acesso total ao .NET Framework, onde o SharedProject possui.

2) #ifdef para código específico da plataforma - você não pode escrever em PCL (a opção #ifdef não está disponível em uma PCL porque é compilada separadamente, como sua própria DLL, portanto, em tempo de compilação (quando o #ifdef é avaliado) ele não sabe de que plataforma fará parte. ) onde, como projeto compartilhado, você pode.

3) O código específico da plataforma é obtido usando Inversion Of Control em PCL, onde, usando as instruções #ifdef, você pode obter o mesmo no Projeto Compartilhado.

Um excelente artigo que ilustra as diferenças entre PCL x Projeto Compartilhado pode ser encontrado no seguinte link

http://hotkrossbits.com/2015/05/03/xamarin-forms-pcl-vs-shared-project/


18

Como outros já escreveram, em suma:


reutilização compartilhada do projeto no nível do código (arquivo), permitindo a estrutura e os recursos da pasta também


reutilização de pcl no nível de montagem

O que mais faltava nas respostas aqui para mim é a informação sobre funcionalidade reduzida disponível em uma PCL: como exemplo, você limitou as operações de arquivo (estava faltando muita funcionalidade do File.IO em um projeto de plataforma cruzada Xamarin).


Projeto compartilhado com mais detalhes :
+ Pode usar #if ao direcionar várias plataformas (por exemplo, Xamarin iOS, Android, WinPhone)
+ Toda a funcionalidade da estrutura disponível para cada projeto de destino (embora precise ser compilado condicionalmente)
o Integra em tempo de compilação
- tamanho ligeiramente maior de montagens resultantes
- Precisa do Visual Studio 2013 Update 2 ou superior

pcl :
+ gera um assembly compartilhado
+ utilizável com versões mais antigas do Visual Studio (atualização 2 anterior a 2013)
o
- funcionalidade vinculada dinamicamente vinculada - (subconjunto de todos os projetos pelos quais está sendo referenciado)

Se você tiver a opção, eu recomendaria um projeto compartilhado, geralmente é mais flexível e mais poderoso. Se você conhece seus requisitos com antecedência e um PCL pode atendê-los, você pode seguir esse caminho também. O PCL também impõe uma separação mais clara ao não permitir que você escreva código específico da plataforma (o que pode não ser uma boa opção para ser colocado em um assembly compartilhado em primeiro lugar).

O foco principal de ambos é quando você direciona várias plataformas, caso contrário, normalmente você usaria apenas um projeto comum de biblioteca / dll.


9

Do livro VS 2015 sucintamente

Projetos compartilhados permite compartilhar código, ativos e recursos em vários tipos de projetos. Mais especificamente, os seguintes tipos de projeto podem fazer referência e consumir projetos compartilhados:

  • Console, Windows Forms e Windows Presentation Foundation.
  • Aplicativos da Windows Store 8.1 e aplicativos do Windows Phone 8.1.
  • Aplicativos Windows Phone 8.0 / 8.1 Silverlight.
  • Bibliotecas de classes portáteis.

Nota: - Os projetos compartilhados e as bibliotecas de classes portáteis (PCL) permitem o compartilhamento de código, recursos XAML e ativos, mas é claro que existem algumas diferenças que podem ser resumidas a seguir.

  • Um projeto compartilhado não produz uma montagem reutilizável, portanto, pode ser consumido apenas de dentro da solução.
  • Um projeto compartilhado tem suporte para código específico da plataforma, porque suporta variáveis ​​de ambiente como WINDOWS_PHONE_APP e WINDOWS_APP que você pode usar para detectar em qual plataforma seu código está sendo executado.
  • Por fim, projetos compartilhados não podem ter dependências de bibliotecas de terceiros.
  • Por comparação, uma PCL produz uma biblioteca .dll reutilizável e pode ter dependências em bibliotecas de terceiros, mas não suporta variáveis ​​de ambiente da plataforma

7

Biblioteca de classes é um código compilado compartilhado.

Projeto compartilhado é um código-fonte compartilhado.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.