.NET Core - Guia rápido

.NET Core é a plataforma de desenvolvimento de propósito geral mais recente mantida pela Microsoft. Ele funciona em diferentes plataformas e foi reprojetado de uma forma que torna o .NET rápido, flexível e moderno. Essa é uma das principais contribuições da Microsoft. Os desenvolvedores agora podem construir aplicativos Android, iOS, Linux, Mac e Windows com .NET, tudo em código aberto.

Neste tutorial, vamos cobrir o .NET Core e algumas inovações, incluindo as atualizações do .NET Framework, .NET Standard e atualizações da Plataforma Universal do Windows, etc.

Características do .NET Core

A seguir estão as principais características do .NET Core -

Código aberto

  • .NET Core é uma implementação de código aberto, usando licenças MIT e Apache 2.

  • .NET Core é um projeto .NET Foundation e está disponível no GitHub.

  • Como um projeto de código aberto, ele promove um processo de desenvolvimento mais transparente e promove uma comunidade ativa e engajada.

Plataforma cruzada

  • O aplicativo implementado no .NET Core pode ser executado e seu código pode ser reutilizado, independentemente do destino da plataforma.

  • Atualmente, oferece suporte a três sistemas operacionais (SO) principais

    • Windows

    • Linux

    • MacOS

  • Os sistemas operacionais (SO), CPUs e cenários de aplicativos suportados crescerão com o tempo, fornecidos pela Microsoft, outras empresas e indivíduos.

Implementação flexível

  • Pode haver dois tipos de implantações para aplicativos .NET Core -

    • Implantação dependente da estrutura

    • Implantação independente

  • Com a implantação dependente de estrutura, seu aplicativo depende de uma versão do .NET Core para todo o sistema, na qual seu aplicativo e as dependências de terceiros estão instaladas.

  • Com a implantação autocontida, a versão do .NET Core usada para construir seu aplicativo também é implantada junto com seu aplicativo e dependências de terceiros e pode ser executada lado a lado com outras versões.

Ferramentas de linha de comando

  • Todos os cenários do produto podem ser exercitados na linha de comando.

Compatível

  • .NET Core é compatível com .NET Framework, Xamarin e Mono, por meio da Biblioteca .NET Standard

Modular

  • O .NET Core é lançado por meio do NuGet em pacotes de montagem menores.

  • .NET Framework é um grande conjunto que contém a maioria das funcionalidades principais.

  • O .NET Core é disponibilizado como pacotes menores centrados em recursos.

  • Essa abordagem modular permite que os desenvolvedores otimizem seus aplicativos, incluindo apenas os pacotes NuGet de que precisam em seus aplicativos.

  • Os benefícios de uma área de superfície menor do aplicativo incluem segurança mais rígida, manutenção reduzida, desempenho aprimorado e custos reduzidos em um modelo pague pelo que usar.

A plataforma .NET Core

A plataforma .NET Core contém as seguintes partes principais -

  • .NET Runtime - Fornece um sistema de tipos, carregamento de montagem, coletor de lixo, interoperabilidade nativa e outros serviços básicos.

  • Fundamental Libraries - Um conjunto de bibliotecas de estrutura, que fornecem tipos de dados primitivos, tipos de composição de aplicativos e utilitários fundamentais.

  • SDK & Compiler - Um conjunto de ferramentas SDK e compiladores de linguagem que permitem a experiência básica do desenvolvedor, disponível no .NET Core SDK.

  • ‘dotnet’ app host- É usado para iniciar aplicativos .NET Core. Ele seleciona o tempo de execução e hospeda o tempo de execução, fornece uma política de carregamento de montagem e inicia o aplicativo. O mesmo host também é usado para iniciar ferramentas SDK da mesma maneira.

Neste capítulo, discutiremos as várias dependências que você precisa para implantar e executar. Isso inclui os aplicativos .NET Core em máquinas Windows que são desenvolvidos com o Visual Studio.

Versões do Windows com suporte

O .NET Core é compatível com as seguintes versões do Windows -

  • Windows 7 SP1
  • Windows 8.1
  • Windows 10
  • Windows Server 2008 R2 SP1 (servidor completo ou núcleo do servidor)
  • Windows Server 2012 SP1 (Full Server ou Server Core)
  • Windows Server 2012 R2 SP1 (servidor completo ou núcleo do servidor)
  • Windows Server 2016 (Full Server, Server Core ou Nano Server)

Dependências

  • Se você estiver executando seu aplicativo .NET Core em versões do Windows anteriores ao Windows 10 e Windows Server 2016, ele também exigirá o Visual C ++ Redistributable.

  • Essa dependência é instalada automaticamente se você usar o instalador do .NET Core.

  • Você precisa instalar manualmente o Visual C ++ Redistributable para Visual Studio 2015 se estiver instalando o .NET Core por meio do script do instalador ou implantando um aplicativo .NET Core autocontido.

  • Para máquinas com Windows 7 e Windows Server 2008, você precisa se certificar de que a instalação do Windows está atualizada e também inclui o hotfix KB2533623 instalado por meio do Windows Update.

Pré-requisitos com Visual Studio

  • Para desenvolver aplicativos .NET Core usando o .NET Core SDK, você pode usar qualquer editor de sua escolha.

  • No entanto, se você deseja desenvolver aplicativos .NET Core no Windows usando o Visual Studio, pode usar as duas versões a seguir -

    • Visual Studio 2015

    • Visual Studio 2017 RC

  • Projetos criados com Visual Studio 2015 serão baseados em project.json por padrão, enquanto projetos criados com Visual Studio 2017 RC sempre serão baseados em MSBuild.

Neste capítulo, discutiremos a configuração do ambiente do .NET Core. É uma reformulação significativa do .NET Framework. Para usar o .NET Core em seu aplicativo, existem duas versões que você pode usar -

  • Visual Studio 2015
  • Visual Studio 2017 RC

Visual Studio 2015

Para usar o Visual Studio 2015, você deve ter instalado o seguinte -

  • Atualização 3 do Microsoft Visual Studio 2015
  • Microsoft .NET Core 1.0.1 - VS 2015 Tooling Preview 2

A Microsoft fornece uma versão gratuita do Visual Studio que também contém o SQL Server e pode ser baixado em https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx e Microsoft .NET Core 1.0.1 - VS 2015 Tooling Preview 2 pode ser baixado de https://www.visualstudio.com/downloads/

Você também pode seguir as diretrizes de instalação no seguinte Url https://www.microsoft.com/net/core/#windowsvs2017

Instalação do Visual Studio 2015

Siga estas etapas para instalar o Visual Studio 2015 -

Step 1- Quando o download for concluído, execute o instalador. A seguinte caixa de diálogo será exibida.

Step 2 - Clique Install para iniciar o processo de instalação.

Step 3 - Assim que a instalação for concluída, você verá a seguinte caixa de diálogo.

Step 4 - Feche esta caixa de diálogo e reinicie o computador, se necessário.

Step 5- Abra o Visual Studio a partir do menu Iniciar; você receberá a seguinte caixa de diálogo. Pode demorar alguns minutos para carregar e finalmente ser usado pela primeira vez.

Step 6 - Depois de carregado, você verá a tela a seguir.

Step 7 - Quando a instalação do Visual Studio for concluída, feche o Visual Studio e inicie o Microsoft .NET Core - VS 2015 Tooling Preview 2.

Step 8 - Marque a caixa de seleção e clique em Instalar.

Step 9 - Assim que a instalação for concluída, você verá a seguinte caixa de diálogo.

Agora você está pronto para iniciar seu aplicativo usando o .NET Core.

Visual Studio 2017

Neste tutorial, usaremos o Visual Studio 2015, mas se você quiser usar o Visual Studio 2017, uma versão experimental das ferramentas .NET Core para Visual Studio está incluída no Visual Studio 2017 RC e você pode ver as diretrizes de instalação aqui https://www.microsoft.com/net/core/#windowsvs2017

O Visual Studio 2015 oferece um ambiente de desenvolvimento completo para o desenvolvimento de aplicativos .NET Core. Neste capítulo, estaremos criando um novo projeto dentro do Visual Studio. Depois de instalar as ferramentas do Visual Studio 2015, você pode começar a construir um novo aplicativo .NET Core.

No New Project caixa de diálogo, na lista Modelos, expanda o nó Visual C # e selecione .NET Core e você deverá ver os três novos modelos de projeto a seguir

  • Biblioteca de classes (.NET Core)
  • Aplicativo de console (.NET Core)
  • Aplicativo da Web ASP.NET Core (.NET Core)

No painel do meio da caixa de diálogo Novo projeto, selecione Aplicativo de console (.NET Core), nomeie-o como "FirstApp" e clique em OK.

O Visual Studio abrirá o projeto recém-criado e você verá na janela Solution Explorer todos os arquivos que estão neste projeto.

Para testar se o aplicativo de console .NET core está funcionando, vamos adicionar a seguinte linha.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace FirstApp { 
   public class Program { 
      public static void Main(string[] args) { 
         Console.WriteLine("Hello guys, welcome to .NET Core world!"); 
      } 
   } 
}

Agora, execute o aplicativo. Você deve ver a seguinte saída.

O .NET Core oferece suporte às primitivas numéricas integrais e de ponto flutuante padrão. Ele também suporta os seguintes tipos -

  • System.Numerics.BigInteger que é um tipo integral sem limite superior ou inferior.

  • System.Numerics.Complex é um tipo que representa números complexos.

  • Um conjunto de tipos de vetor habilitados para Single Instruction Multiple Data (SIMD) no namespace System.Numerics.

Tipos integrais

O .NET Core oferece suporte a inteiros assinados e não assinados de diferentes intervalos de um byte a oito bytes de comprimento. Todos os inteiros são tipos de valor.

A tabela a seguir representa os tipos integrais e seus tamanhos;

Tipo Assinado / Não Assinado Tamanho (bytes) Valor mínimo Valor máximo
Byte Sem sinal 1 0 255
Int16 Assinado 2 -32.768 32.767
Int32 Assinado 4 -2.147.483.648 2.147.483.647
Int64 Assinado 8 −9.223.372.036.854.775.808 9.223.372.036.854.775.807
SByte Assinado 1 -128 127
UInt16 Sem sinal 2 0 65.535
UInt32 Sem sinal 4 0 4.294.967.295
UInt64 Sem sinal 8 0 18.446.744.073.709.551.615

Cada tipo integral oferece suporte a um conjunto padrão de operadores de aritmética, comparação, igualdade, conversão explícita e conversão implícita.

Você também pode trabalhar com os bits individuais em um valor inteiro usando a classe System.BitConverter.

Tipos de ponto flutuante

O .NET Core inclui três tipos primitivos de ponto flutuante, que são mostrados na tabela a seguir.

Tipo Tamanho (bytes) Valor mínimo Valor máximo
em dobro 8 −1,79769313486232e308 1.79769313486232e308
solteiro 4 -3,402823e38 3.402823e38
Decimal 16 −79.228.162.514.264.337.593,5 43.950.335 79.228.162.514.264.337.593.543,9 50.335
  • Cada tipo de ponto flutuante oferece suporte a um conjunto padrão de operadores de aritmética, comparação, igualdade, conversão explícita e conversão implícita.

  • Você também pode trabalhar com os bits individuais em valores Double e Single usando a classe BitConverter.

  • A estrutura Decimal possui seus próprios métodos, Decimal.GetBits e Decimal.Decimal (Int32 ()), para trabalhar com bits individuais de um valor decimal, bem como seu próprio conjunto de métodos para realizar algumas operações matemáticas adicionais.

BigInteger

  • System.Numerics.BigInteger é um tipo imutável que representa um número inteiro arbitrariamente grande cujo valor em teoria não tem limites superior ou inferior.

  • Os métodos do tipo BigInteger são estreitamente paralelos aos dos outros tipos integrais.

Complexo

  • O tipo System.Numerics.Complex representa um número complexo, ou seja, um número com uma parte de número real e uma parte de número imaginário

  • Ele oferece suporte a um conjunto padrão de operadores aritméticos, de comparação, igualdade, conversão explícita e conversão implícita, bem como métodos matemáticos, algébricos e trigonométricos.

SIMD

  • O namespace Numerics inclui um conjunto de tipos de vetores habilitados para SIMD para .NET Core.

  • O SIMD permite que algumas operações sejam paralelizadas no nível do hardware, o que resulta em grandes melhorias de desempenho em aplicativos matemáticos, científicos e gráficos que realizam cálculos sobre vetores.

  • Os tipos de vetor habilitados para SIMD no .NET Core incluem o seguinte -

    • Tipos System.Numerics.Vector2, System.Numerics.Vector3 e System.Numerics.Vector4, que são vetores de 2, 3 e 4 dimensões do tipo Único.

    • A estrutura Vector <T> que permite criar um vetor de qualquer tipo numérico primitivo. Os tipos numéricos primitivos incluem todos os tipos numéricos no namespace System, exceto Decimal.

    • Dois tipos de matriz, System.Numerics.Matrix3 × 2, que representa uma matriz 3 × 2; e System.Numerics.Matrix4 × 4, que representa uma matriz 4 × 4.

    • O tipo System.Numerics.Plane, que representa um plano tridimensional, e o tipo System.Numerics.Quaternion, que representa um vetor usado para codificar rotações físicas tridimensionais.

Neste capítulo, abordaremos o conceito de Coleta de lixo, um dos recursos mais importantes da plataforma de código gerenciado .NET. O coletor de lixo (GC) gerencia a alocação e liberação de memória. O coletor de lixo funciona como um gerenciador automático de memória.

  • Você não precisa saber como alocar e liberar memória ou gerenciar o tempo de vida dos objetos que usam essa memória

  • Uma alocação é feita sempre que você declara um objeto com uma palavra-chave “nova” ou um tipo de valor está dentro de uma caixa. As alocações são normalmente muito rápidas

  • Quando não há memória suficiente para alocar um objeto, o GC deve coletar e descartar a memória de lixo para disponibilizar memória para novas alocações.

  • Este processo é conhecido como garbage collection.

Vantagens da coleta de lixo

A coleta de lixo oferece os seguintes benefícios -

  • Você não precisa liberar memória manualmente ao desenvolver seu aplicativo.

  • Ele também aloca objetos no heap gerenciado com eficiência.

  • Quando os objetos não são mais usados, ele os recupera limpando sua memória e mantém a memória disponível para futuras alocações.

  • Os objetos gerenciados obtêm conteúdo limpo para começar, de forma que seus construtores não tenham que inicializar todos os campos de dados.

  • Ele também fornece segurança de memória, garantindo que um objeto não possa usar o conteúdo de outro objeto.

Condições para coleta de lixo

A coleta de lixo ocorre quando uma das seguintes condições for verdadeira.

  • O sistema está com pouca memória física.

  • A memória usada por objetos alocados no heap gerenciado ultrapassa um limite aceitável. Este limite é continuamente ajustado conforme o processo é executado.

  • o GC.Collectmétodo é chamado e, em quase todos os casos, você não precisa chamar esse método, porque o coletor de lixo é executado continuamente. Este método é usado principalmente para situações e testes únicos.

Gerações

O .NET Garbage Collector tem 3 gerações e cada geração possui seu próprio heap que é usado para o armazenamento de objetos alocados. Existe um princípio básico de que a maioria dos objetos tem vida curta ou longa.

Primeira geração (0)

  • Na Geração 0, os objetos são alocados primeiro.

  • Nesta geração, os objetos geralmente não vivem além da primeira geração, uma vez que eles não estão mais em uso (fora do escopo) no momento em que ocorre a próxima coleta de lixo.

  • A geração 0 é rápida para coletar porque seu heap associado é pequeno.

Segunda geração (1)

  • Na Geração 1, os objetos têm um espaço de segunda chance.

  • Objetos que têm vida curta, mas sobrevivem à coleção da geração 0 (muitas vezes com base no tempo coincidente) vão para a geração 1.

  • As coleções da geração 1 também são rápidas porque seu heap associado também é pequeno.

  • Os dois primeiros heaps permanecem pequenos porque os objetos são coletados ou promovidos para o heap da próxima geração.

Terceira geração (2)

  • Na geração 2, todos os objetos longos são vividos e seu heap pode crescer muito.

  • Os objetos nesta geração podem sobreviver por muito tempo e não há heap da próxima geração para promover ainda mais os objetos.

  • O Garbage Collector possui um heap adicional para objetos grandes, conhecido como Large Object Heap (LOH).

  • É reservado para objetos com 85.000 bytes ou mais.

  • Objetos grandes não são alocados para os heaps de geração, mas são alocados diretamente para o LOH

  • As coleções da Geração 2 e LOH podem levar um tempo perceptível para programas que foram executados por muito tempo ou operam com grandes quantidades de dados.

  • Sabe-se que programas de servidor grandes têm pilhas na casa dos 10 GBs.

  • O GC emprega uma variedade de técnicas para reduzir a quantidade de tempo que bloqueia a execução do programa.

  • A abordagem principal é fazer o máximo possível de trabalho de coleta de lixo em um thread de segundo plano de uma maneira que não interfira na execução do programa.

  • O GC também expõe algumas maneiras para os desenvolvedores influenciarem seu comportamento, o que pode ser bastante útil para melhorar o desempenho.

Neste capítulo, vamos entender o processo de execução do .NET Core e compará-lo com o .NET Framework. O processo de execução gerenciado inclui as seguintes etapas.

  • Escolha de um compilador
  • Compilando seu código para MSIL
  • Compilando MSIL para código nativo
  • Código em execução

Escolhendo um compilador

  • É um ambiente de execução multilíngue, o tempo de execução suporta uma ampla variedade de tipos de dados e recursos de linguagem.

  • Para obter os benefícios fornecidos pelo common language runtime, você deve usar um ou mais compiladores de linguagem direcionados ao runtime.

Compilando seu código para MSIL

  • A compilação traduz seu código-fonte em Microsoft Intermediate Language (MSIL) e gera os metadados necessários.

  • Metadados descrevem os tipos em seu código, incluindo a definição de cada tipo, as assinaturas dos membros de cada tipo, os membros que seu código faz referência e outros dados que o tempo de execução usa no tempo de execução.

  • O tempo de execução localiza e extrai os metadados do arquivo, bem como das bibliotecas de classe de estrutura (FCL) conforme necessário durante a execução.

Compilando MSIL para código nativo

  • Em tempo de execução, um compilador just-in-time (JIT) converte o MSIL em código nativo.

  • Durante esta compilação, o código deve passar por um processo de verificação que examina o MSIL e os metadados para descobrir se o código pode ser determinado como seguro de tipo.

Código de Execução

  • O common language runtime fornece a infraestrutura que permite que a execução ocorra e os serviços que podem ser usados ​​durante a execução.

  • Durante a execução, o código gerenciado recebe serviços como coleta de lixo, segurança, interoperabilidade com código não gerenciado, suporte para depuração entre linguagens e implantação aprimorada e suporte para controle de versão.

Processo de execução de código .NET Core

Agora, vamos relacionar como o código é executado com o .NET Core em comparação com o .NET Framework. No .NET Core, há muitas substituições desses componentes que fazem parte do .NET Framework.

  • No .NET Core agora temos uma nova série de compiladores, como Roslyn para C # e VB.

  • Você também pode usar o novo compilador F # 4.1 se quiser usar o F # com .NET Core.

  • Na verdade, essas ferramentas são diferentes e podemos usar Roslyn com .NET Framework também se estivermos usando C # 6 ou posterior, porque o compilador C # só pode suportar até C # 5.

  • No .NET Core, não temos uma biblioteca de classes de framework (FCL), então um conjunto diferente de bibliotecas é usado e agora temos CoreFx.

  • CoreFx é a reimplementação das bibliotecas de classes para .NET Core.

  • Também temos um novo tempo de execução com o .NET Core conhecido como CoreCLR e aproveita um compilador JIT.

  • Agora a questão é por que temos a reimplementação de todos esses componentes que já temos no .NET framework.

  • Portanto, a resposta é a mesma porque a Microsoft implementou o .NET Core.

É outra consideração do .NET Core construir e implementar aplicativos que sejam modulares. Em vez de instalar todo o .NET Framework, seu aplicativo agora pode apenas instalar o que é necessário. Vamos ao estúdio visual e vejamos a modularidade.

Aqui está nosso aplicativo .NET Core simples, no Gerenciador de Soluções. Vamos expandir as referências e você verá a referência a .NETCoreApp

Dentro do .NETCoreApp, você verá a referência do pacote ao NuGet; vamos expandi-lo.

Você verá toda a série de referências do pacote NuGet. Se você trabalhou no .NET Framework, muitos desses namespaces parecerão familiares, porque você está acostumado com isso usando o .NET Framework.

O .NET Framework é dividido em muitas partes diferentes e reimplementado com CoreFx; essas peças são posteriormente distribuídas como pacotes individuais.

  • Agora, se você expandir NETStandard.Library, verá referências adicionais. Você até notará System.Console que estamos usando neste aplicativo.

  • Agora você não precisa trazer tudo dentro do .NET Framework, mas apenas o que você precisa para o seu aplicativo.

  • Existem alguns outros benefícios também; por exemplo, esses módulos podem ser atualizados individualmente, se desejado.

A modularidade leva a benefícios de desempenho e seu aplicativo pode ser executado com mais rapidez, especialmente o aplicativo ASP.NET Core.

Neste capítulo, discutiremos os arquivos de projeto do .NET Core e como você pode adicionar arquivos existentes em seu projeto.

Vamos entender um exemplo simples no qual temos alguns arquivos que já foram criados; temos que adicionar esses arquivos em nosso projeto FirstApp.

Aqui está a implementação do Student.cs Arquivo

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace FirstApp { 
   public class Student { 
      public int ID { get; set; } 
      public string LastName { get; set; } 
      public string FirstMidName { get; set; } 
      public DateTime EnrollmentDate { get; set; } 
   } 
}

Aqui está a implementação do Course.cs Arquivo.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace FirstApp { 
   public class Course { 
      public int CourseID { get; set; } 
      public string Title { get; set; } 
      public int Credits { get; set; } 
   } 
}

Vamos agora salvar esses três arquivos no seu disco e na pasta de origem do seu projeto.

  • Agora, se você está familiarizado com o .NET e este era um aplicativo de console tradicional do .NET Framework, é importante entender como adicionar esses arquivos em seu projeto no Visual Studio.

  • Primeiro, você precisa arrastar os arquivos para o explorador de soluções para copiá-los na pasta do projeto, porque o projeto precisa fazer referência a esses arquivos.

  • Um dos benefícios do .NET Core é a abordagem feita com o arquivo de projeto (project.json); podemos simplesmente soltar os arquivos na raiz do nosso projeto e, em seguida, eles serão incluídos automaticamente em nosso projeto.

  • Não precisamos referenciar arquivos manualmente como fazíamos no passado para o aplicativo .NET Framework tradicional no Visual Studio.

Vamos agora abrir a raiz do seu projeto.

Vamos agora copiar todos os três arquivos na raiz do seu projeto.

Agora você pode ver todos os arquivos copiados para a pasta raiz.

Vamos agora para o Visual Studio; você receberá a seguinte caixa de diálogo.

Clique Yes to All para recarregar seu projeto.

Você saberá agora que os arquivos são incluídos automaticamente em seu projeto.

Neste capítulo, discutiremos como adicionar pacotes em seu aplicativo .NET Core e como encontrar um pacote específico. Podemos ir diretamente ao NuGet e adicionar o pacote, mas aqui veremos alguns outros lugares.

Vamos agora ao código-fonte do .NET Core, que está localizado aqui - https://github.com/dotnet/corefx

No repositório CoreFx, abra o src pasta -

E você verá toda a lista de pastas que correspondem aos diferentes pacotes. Vamos agora pesquisar Json -

Existe outra maneira de encontrar seu pacote. Você provavelmente conhece vários tipos se estiver familiarizado com o .NET Framework, mas a montagem de pacotes no .NET Core é totalmente diferente e você não saberá onde estão esses pacotes.

Se você souber o tipo, pode pesquisar para reverter a pesquisa de pacotes usando https://packagesearch.azurewebsites.net/

Aqui você pode inserir qualquer tipo de pacote que deseja encontrar. Em seguida, este site examinará o NuGet e encontrará os pacotes relevantes para você.

Vamos agora procurar por DataContractJson.

Você verá agora que recebemos o mesmo pacote; vamos clicar no pacote.

Agora você verá a página NuGet; você precisa confirmar que você precisa deste pacote. Você pode adicionar isso em seu aplicativo usando alguns métodos.

Vamos abrir o arquivo project.json.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      } 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "imports": "dnxcore50" 
      } 
   } 
}

Este é o novo formato do projeto e dentro deste arquivo você verá a seção de dependências. Vamos adicionar uma nova dependência conforme mostrado abaixo.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      }, 
      "System.Runtime.Serialization.Json": "4.0.2" 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "imports": "dnxcore50" 
      } 
   } 
}

Agora, se você olhar suas referências, verá que System.Runtime.Serialization.Json pacote é adicionado ao seu projeto.

Outra maneira é ir para o NuGet Manager e navegar pelo pacote que deseja adicionar.

Neste capítulo, discutiremos como criar um aplicativo UWP usando o .NET Core. O UWP também é conhecido como aplicativo UWP do Windows 10. Este aplicativo não é executado em versões anteriores do Windows, mas só será executado em versões futuras do Windows.

A seguir estão algumas exceções em que o UWP será executado sem problemas.

  • Se você deseja executá-lo localmente, você deve ter o Windows 10, você também pode desenvolver no Windows 8 e então você precisará executá-lo no emulador, mas é recomendável usar o Windows 10.

  • Para o aplicativo UWP, você também precisará do Windows 10 SDK. Vamos abrir a configuração do Visual Studio 2015 e, em seguida, modificar o Visual Studio.

  • Na página de seleção de recursos, role para baixo e você verá Ferramentas Universais de Desenvolvimento de Aplicativos do Windows, marque essa opção conforme mostrado abaixo.

Aqui você pode ver as diferentes versões do SDK e também a atualização mais recente das ferramentas. Clique em Avançar.

Agora, clique no Install botão.

Assim que a instalação for concluída, você precisará reiniciar o sistema.

Vamos agora implementar o UWP seguindo estas etapas.

  • Primeiro, inicie o Visual Studio 2015.

  • Clique no menu Arquivo e selecione Novo → Projeto; uma caixa de diálogo Novo projeto aparecerá. Você pode ver os diferentes tipos de modelos no painel esquerdo da caixa de diálogo.

  • No painel esquerdo, você pode ver a visualização em árvore, agora selecione Modelo universal em Modelos → Visual C # → Windows.

  • No painel central, selecione o modelo Aplicativo em branco (Windows universal).

  • Dê um nome ao projeto digitando UWPFirstApp no campo Nome e clique em OK.

  • A caixa de diálogo de versão de destino / versão mínima é exibida. As configurações padrão são adequadas para este tutorial, então selecione OK para criar o projeto.

  • Aqui, temos um único projeto que pode ser direcionado a todos os dispositivos Windows 10, e você notará que tanto o .NET Core quanto o UWP são uma simplificação da segmentação múltipla.

  • Quando um novo projeto é aberto, seus arquivos são exibidos no lado direito do painel Solution Explorer. Pode ser necessário escolher a guia Solution Explorer em vez da guia Propriedades para ver seus arquivos.

  • Embora o aplicativo em branco (janela universal) seja um modelo mínimo, ele ainda contém muitos arquivos. Esses arquivos são essenciais para todos os aplicativos UWP que usam C #. Cada projeto que você cria no Visual Studio contém os arquivos.

  • Para ver o exemplo em execução, vamos abrir MainPage.XAML e adicionar o código a seguir.

<Page 
   x:Class = "UWPFirstApp.MainPage" 
   xmlns = "http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   xmlns:x = "http://schemas.microsoft.com/winfx/2006/xaml" 
   xmlns:local = "using:UWPFirstApp" 
   xmlns:d = "http://schemas.microsoft.com/expression/blend/2008" 
   xmlns:mc = "http://schemas.openxmlformats.org/markup-compatibility/2006" 
   mc:Ignorable = "d">  
   
   <Grid Background = "{ThemeResource ApplicationPageBackgroundThemeBrush}"> 
      <StackPanel HorizontalAlignment = "Center"> 
         <TextBlock Text = "Hello, world!"  
            Margin = "20" 
            Width = "200" 
            HorizontalAlignment = "Left"/> 
         <TextBlock Text = "Write your name." 
            Margin = "20" 
            Width = "200" 
            HorizontalAlignment = "Left"/> 
         <TextBox x:Name = "txtbox"  
            Width = "280" 
            Margin = "20" 
            HorizontalAlignment = "Left"/> 
         <Button x:Name = "button" Content = "Click Me" 
            Margin = "20" 
            Click = "button_Click"/> 
         <TextBlock x:Name = "txtblock"  
            HorizontalAlignment = "Left" 
            Margin = "20"/> 
      </StackPanel> 
   </Grid> 

</Page>

Abaixo está o evento de clique do botão em C #.

using System; 
using System.Collections.Generic; 
using System.IO; 
using System.Linq; 
using System.Runtime.InteropServices.WindowsRuntime; 

using Windows.Foundation; 
using Windows.Foundation.Collections; 

using Windows.UI.Xaml; 
using Windows.UI.Xaml.Controls; 
using Windows.UI.Xaml.Controls.Primitives; 
using Windows.UI.Xaml.Data; 
using Windows.UI.Xaml.Input; 
using Windows.UI.Xaml.Media; 
using Windows.UI.Xaml.Navigation;  

// The Blank Page item template is documented at 
// http://go.microsoft.com/fwlink/?LinkId=402352&clcid=0x409  

namespace UWPHellowWorld { 
   /// <summary> 
   /// An empty page that can be used on its own or navigated to within a Frame. 
   /// </summary> 
   public sealed partial class MainPage : Page { 
      public MainPage() { 
         this.InitializeComponent(); 
      }  
      private void button_Click(object sender, RoutedEventArgs e) { 
         if (txtbox.Text != "") 
            txtblock.Text = "Hello: " + txtbox.Text; 
         else 
            txtblock.Text = "You have not write your name"; 
      } 
   } 
}

Vamos agora executar o código acima na máquina local e você verá a seguinte janela. Agora digite qualquer nome na caixa de texto e pressione oClick Me botão.

Neste capítulo, discutiremos o que é MSBuild e como ele funciona com o .NET Core. MSBuild é a plataforma de construção para Microsoft e Visual Studio. No aplicativo UWP, se você abrir a pasta do projeto, verá os arquivos project.json e * .csproj.

Mas se você abrir nosso aplicativo .NET Core Console anterior, verá os arquivos project.json e * .xproj.

  • O sistema de compilação .NET Core ou o sistema de compilação project.json não é suficiente para as necessidades de UWP; é por isso que a UWP ainda está usando o sistema Build * .csproj (MSBuild).

  • Mas o project.json irá evoluir no que diz respeito ao sistema de compilação.

  • Agora, se você deseja adicionar alguns arquivos existentes ao seu aplicativo UWP, conforme adicionamos no aplicativo Console, você precisa adicionar esses arquivos na pasta do projeto. Além disso, você também precisará incluir em seu projeto no Solution Explorer.

Vamos agora considerar os seguintes arquivos; copie esses arquivos para a pasta do projeto.

Vamos voltar ao Visual Studio e abrir o Gerenciador de Soluções.

  • Agora você pode ver que apenas copiar arquivos não é suficiente no caso de aplicativos UWP, porque no Gerenciador de Soluções, não podemos ver esses arquivos.

  • Agora devemos incluir esses arquivos clicando no Show All Files ícone conforme destacado na captura de tela acima e você verá agora todos os arquivos na pasta do projeto.

Esses dois arquivos ainda não estão incluídos em nosso projeto. Para incluir esses arquivos, selecione-os e clique com o botão direito em qualquer arquivo e selecioneInclude in Project.

Agora, esses arquivos também estão incluídos. Uma coisa boa que pode ser prevista é a abordagem project.json de descartar arquivos para * .csproj na versão futura das ferramentas SKD e também no Visual Studio.

Neste capítulo, discutiremos as referências entre nosso aplicativo de console e nosso aplicativo UWP. Se você olhar as referências no Solution Explorer do seu aplicativo de console, verá o .NETCoreApp conforme mostrado abaixo.

.NETCoreApp é uma nova estrutura voltada para aplicativos .NET Core. Agora, se você olhar em Referências do aplicativo UWP, terá uma aparência um pouco diferente, conforme mostrado abaixo.

  • O principal motivo para isso é porque aqui na UWP temos o * .csproj, portanto, estamos de volta ao antigo estilo de referências e podemos direcionar apenas um framework com este tipo de projeto.

  • As referências são semelhantes. Agora você pode ver que no aplicativo UWP, a referência do Pacote NuGet Miscrosoft.NETCore.UniversalWindowsPlatform é semelhante à referência NuGet Microsoft.NETCore.App no ​​aplicativo Console.

  • Ambos Miscrosoft.NETCore.UniversalWindowsPlatform e Microsoft.NETCore.App são meta-pacotes, o que significa que são compostos de outros pacotes.

  • No aplicativo de console, podemos detalhar e ver outros pacotes dentro do Microsoft.NETCore.App, mas não podemos fazer o mesmo Miscrosoft.NETCore.UniversalWindowsPlatform no Solution Explorer.

  • No entanto, podemos usar outra ferramenta, o NuGet Package Explorer para ver isso. Vamos agora abrir este url no navegador -https://npe.codeplex.com/downloads/get/clickOnce/NuGetPackageExplorer.application e você verá um pequeno utilitário sendo baixado.

  • Assim que o download for concluído, clique duas vezes no arquivo.

  • Clique Install para iniciar a instalação no NuGet Package Explorer.

  • Quando a instalação for concluída, você verá a seguinte caixa de diálogo.

  • Vamos agora clicar no Open a package from online feed opção.

  • Por padrão, ele pesquisará o feed nuget.org. Vamos agora pesquisar por Microsoft.NETCore.UniversalWindowsPlatform na caixa de pesquisa e você verá 1 resultado conforme mostrado abaixo.

  • Clique no open link e abrirá as dependências de nível superior deste metapacote.

  • Vamos agora abrir o meta-pacote .NETCore para o aplicativo .NETCore e o meta-pacote para o aplicativo UWP lado a lado.

  • Agora você pode ver que cada meta-pacote é composto por diferentes conjuntos de pacotes.

  • O .NET Core é um subconjunto das classes disponíveis no .NET Framework, pelo menos neste momento, mas está crescendo e será de acordo com as classes básicas do .NET Framework.

  • O UWP é baseado no .NET Core, é um superconjunto das APIs disponíveis para o desenvolvimento da Windows Store.

Agora temos mais APIs disponíveis para desenvolvimento devido ao .NET Core.

Os componentes do Windows Runtime são objetos autocontidos que você pode instanciar e usar em qualquer linguagem, incluindo C #, Visual Basic, JavaScript e C ++. Além do meta-pacote .NET Core que vimos no capítulo anterior, o aplicativo UWP também tem uma referência por padrão a um SDK Universal do Windows.

Universal Windows é a referência ao Windows Runtime e foi fatorado em uma série de contratos de APIs.

O conjunto de APIs dentro de uma família de dispositivos é dividido em subdivisões conhecidas como contratos de API. Você pode encontrar uma lista de diferentes contratos de API aquihttps://msdn.microsoft.com/en-us/library/windows/apps/dn706135.aspx

A maioria dessas APIs dentro do tempo de execução do Windows são fatoradas em um único contrato. Vamos agora pesquisar a palavra-chave Universal na página Contratos de API.

Você pode ver links para várias APIs e também pode ver que a família Universal é tão grande que tem 12 páginas de documentação.

Você também pode pesquisar o contrato de API do telefone nesta página.

Vamos agora clicar no Windows.Phone.PhoneContracte rolar para baixo; agora você verá as informações da bateria do telefone ou do dispositivo móvel.

Se você quiser adicionar essas informações sobre as que você já possui, você deve adicionar as referências manualmente. Vamos agora para o Visual Studio e clique com o botão direito do mouse em References no Solution Explorer.

Selecione Add References…

Agora você pode ver a nova categoria de referência para janelas universais; nesta categoria há Core, que se refere aos principais contratos da API Universal do Windows

  • As extensões nos permitem estender a funcionalidade e você verá diferentes referências para celular, desktop e outras extensões.

  • Existem diferentes extensões SKD e você pode adicionar no topo para obter mais APIs.

  • Você também pode ver versões diferentes. Portanto, certifique-se de obter a versão mais recente para obter as APIs atualizadas e clique em OK.

Agora você pode ver isso Windows Mobile Extensions for the UWP é adicionado como referência.

Uma biblioteca de classes define os tipos e métodos que podem ser chamados de qualquer aplicativo.

  • Uma biblioteca de classes desenvolvida com o .NET Core oferece suporte à Biblioteca .NET Standard, que permite que sua biblioteca seja chamada por qualquer plataforma .NET que ofereça suporte a essa versão da Biblioteca .NET Standard.

  • Quando terminar sua biblioteca de classes, você pode decidir se deseja distribuí-la como um componente de terceiros ou se deseja incluí-la como um componente que vem junto com um ou mais aplicativos.

Vamos começar adicionando um projeto de biblioteca de classes em nosso aplicativo de console; clique com o botão direito nosrc pasta no Solution Explorer e selecione Add → New Project…

No Add New Project caixa de diálogo, escolha o nó .NET Core e escolha o modelo de projeto Class Library (.NET Core).

Na caixa de texto Nome, digite "UtilityLibrary" como o nome do projeto, como mostra a figura a seguir.

Clique em OK para criar o projeto de biblioteca de classes. Assim que o projeto for criado, vamos adicionar uma nova classe. Clique com o botão direito emproject no Solution Explorer e selecione Add → Class...

Selecione a classe no painel do meio e digite StringLib.cs no nome e campo e clique em Add. Depois que a classe for adicionada, substitua o código a seguir no arquivo StringLib.cs.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace UtilityLibrary { 
   public static class StringLib { 
      public static bool StartsWithUpper(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
         return false; 
         Char ch = str[0]; 
         return Char.IsUpper(ch); 
      } 
      public static bool StartsWithLower(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
         return false; 
         Char ch = str[0]; 
         return Char.IsLower(ch); 
      } 
      public static bool StartsWithNumber(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
         return false;  
         Char ch = str[0]; 
         return Char.IsNumber(ch); 
      } 
   } 
}
  • A biblioteca da classe, UtilityLibrary.StringLib, contém alguns métodos como, StartsWithUpper, StartsWithLower, e StartsWithNumber que retorna um valor booleano que indica se a instância da string atual começa com maiúscula, minúscula e número, respectivamente.

  • No .NET Core, o Char.IsUpper o método retorna true se um caractere estiver em maiúsculas, o método Char.IsLower retorna true se um caractere estiver em minúsculas, e da mesma forma o método Char.IsNumber retorna true se um caractere for numérico.

  • Na barra de menus, escolha Build, Build Solution. O projeto deve ser compilado sem erros.

  • Nosso projeto de console do .NET Core não tem acesso à nossa biblioteca de classes.

  • Agora, para consumir essa biblioteca de classes, precisamos adicionar referência a essa biblioteca de classes em nosso projeto de console.

Para fazer isso, expanda FirstApp e clique com o botão direito em References e selecione Add Reference…

Na caixa de diálogo Reference Manager, selecione UtilityLibrary, nosso projeto de biblioteca de classes e clique em OK.

Vamos agora abrir o arquivo Program.cs do projeto do console e substituir todo o código pelo código a seguir.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Threading.Tasks; 
using UtilityLibrary; 

namespace FirstApp { 
   public class Program { 
      public static void Main(string[] args) { 
         int rows = Console.WindowHeight; 
         Console.Clear(); 
         do { 
            if (Console.CursorTop >= rows || Console.CursorTop == 0) { 
               Console.Clear(); 
               Console.WriteLine("\nPress <Enter> only to exit; otherwise, enter a string and press <Enter>:\n"); 
            } 
            string input = Console.ReadLine(); 
            
            if (String.IsNullOrEmpty(input)) break; 
            Console.WriteLine("Input: {0} {1,30}: {2}\n", input, "Begins with uppercase? ", 
            input.StartsWithUpper() ? "Yes" : "No"); 
         } while (true); 
      } 
   } 
}

Vamos agora executar seu aplicativo e você verá a seguinte saída.

Para melhor compreensão, vamos usar os outros métodos de extensão de sua biblioteca de classes em seu projeto.

Neste capítulo, discutiremos o que é PCL (Biblioteca de Classes Portátil) e também por que precisamos de PCL. Para entender esse conceito, vamos abrir a pasta do projeto da biblioteca de classes que criamos no capítulo anterior.

Nesta pasta, você pode ver que, além dos arquivos project.json e CS, também temos o arquivo * .xproj, e isso porque o Visual Studio configurou o tipo de projeto .NET Core como * .xproj em vez de * .csproj.

Conforme mencionado pela Microsoft, * .xproj será removido, mas ainda está aqui nas ferramentas de visualização 2. Como vimos, esse aplicativo UWP usa o * .csproj.

Agora, na verdade, não é viável fazer com que * .csproj faça referência e * .xproj e essa funcionalidade não será implementada porque * .xproj será removido.

Então, em vez disso, precisamos de uma biblioteca de classes que pode ser compartilhada entre o aplicativo de console e o aplicativo UWP e aí vem o PCL.

O que é PCL

Vamos agora entender o que é PCL -

  • O projeto Biblioteca de Classes Portátil permite que você escreva e crie assemblies gerenciados que funcionam em mais de uma plataforma .NET Framework.

  • Você pode criar classes que contenham o código que deseja compartilhar em muitos projetos, como lógica de negócios compartilhada e, em seguida, fazer referência a essas classes de diferentes tipos de projetos.

  • Ele também pode ajudá-lo a criar aplicativos e bibliotecas de plataforma cruzada para plataformas Microsoft de forma rápida e fácil.

  • Bibliotecas de classes portáteis podem ajudar a reduzir o tempo e os custos de desenvolvimento e teste de código.

  • Use este tipo de projeto para escrever e construir assemblies portáteis do .NET Framework e, em seguida, fazer referência a esses assemblies de aplicativos que visam várias plataformas, como Windows e Windows Phone, etc.

Vamos agora remover a biblioteca de classes que criamos do Solution Explorer. Ao mesmo tempo, exclua-o da pasta Solução e adicione um novo item de projeto.

Selecione os Visual C# → Windows modelo no painel esquerdo e selecione Class Library (Portable) no painel do meio.

Insira StringLibrary no campo do nome e clique em OK para criar este projeto.

Agora precisamos selecionar as estruturas de destino para fazer referência. Vamos selecionar Windows Universal e ASP.NET Core por um momento, então vamos redirecioná-lo. CliqueOK.

Você pode ver que foi criado um novo projeto em formato PCF. Vamos agora clicar com o botão direito do mouse no projeto StringLibrary no Gerenciador de Soluções e selecionar Propriedades.

Clique em Target .NET Platform Standard.

Clique em Sim; agora é a mesma biblioteca de classes com uma pequena diferença. A diferença é que ele também pode ser usado pela UWP, pois contém o arquivo * .csproj em vez de * .xproj.

Vamos agora adicionar uma nova classe; para isso, você precisa clicar com o botão direito no projeto no Solution Explorer e selecionarAdd → Class...

Selecione a classe no painel do meio e digite StringLib.cs no campo do nome e clique em Add. Depois que a classe for adicionada, substitua o código a seguir no arquivo StringLib.cs.

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using System.Threading.Tasks; 
  
namespace StringLibrary { 
   public static class StringLib { 
      public static bool StartsWithUpper(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
            return false; 
         Char ch = str[0]; 
         return Char.IsUpper(ch); 
      } 
      public static bool StartsWithLower(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
            return false; 
         Char ch = str[0]; 
         return Char.IsLower(ch); 
      } 
      public static bool StartsWithNumber(this String str) { 
         if (String.IsNullOrWhiteSpace(str)) 
            return false; 
         Char ch = str[0]; 
         return Char.IsNumber(ch); 
      } 
   } 
}

Vamos construir este projeto de biblioteca de classes portátil e ele deve ser compilado sem erros. Agora precisamos adicionar referência a esta biblioteca de classes portátil em nosso projeto de console. Portanto, expanda FirstApp e clique com o botão direito em References e selecioneAdd Reference…

Na caixa de diálogo Reference Manager, selecione StringLibrary, que é o nosso projeto de biblioteca de classes portátil, e clique em OK.

Você pode ver que a referência StringLibrary é adicionada ao projeto do console e também pode ser vista no arquivo project.json.

Agora você pode executar o aplicativo novamente e verá a mesma saída.

Vamos agora usar os outros métodos de extensão de sua biblioteca de classes portátil em seu projeto. A mesma biblioteca portátil também será consumida em seu aplicativo UWP.

Neste capítulo, discutiremos como adicionar referências à sua biblioteca. Adicionar referências à biblioteca é como adicionar referências a outros projetos, como projeto de console e projeto UWP.

Agora você pode ver que o projeto PCL tem algumas referências por padrão. Você também pode adicionar outras referências de acordo com a necessidade do aplicativo.

Na biblioteca PCL, você também pode ver o arquivo project.json.

{ 
   "supports": {}, 
   "dependencies": { 
      "NETStandard.Library": "1.6.0", 
      "Microsoft.NETCore.Portable.Compatibility": "1.0.1" 
   }, 
   "frameworks": { 
      "netstandard1.3": {} 
   } 
}

Um método de adicionar referências à sua biblioteca é digitá-las diretamente no arquivo project.json. Como você pode ver, adicionamos algumas referências na seção de dependências, conforme mostrado no código a seguir.

{ 
   "supports": {}, 
   "dependencies": { 
      "NETStandard.Library": "1.6.0", 
      "Microsoft.NETCore.Portable.Compatibility": "1.0.1", 
      "System.Runtime.Serialization.Json": "4.0.3", 
      "Microsoft.EntityFrameworkCore": "1.1.0" 
   }, 
   "frameworks": { 
      "netstandard1.3": {} 
   } 
}

Vamos agora salvar este arquivo e você verá que as referências foram adicionadas à sua biblioteca agora.

O outro método de adicionar referências à sua biblioteca é o Gerenciador de Pacotes NuGet. Vamos agora clicar com o botão direito noStringLibrary (Portable) projetar e selecionar Mange NuGet Packages…

Na guia Procurar, você pode pesquisar qualquer pacote NuGet; digamos que queremos adicionar o pacote “System.Runtime.Serialization.Primitives”.

Clique no Install botão, que exibirá a tela a seguir.

Agora, clique no OK botão.

Finalmente, clique no I Acceptbotão para iniciar a instalação deste pacote NuGet. Quando a instalação for concluída, você verá que o pacote NuGet “System.Runtime.Serialization.Primitives” foi adicionado à sua biblioteca.

Neste capítulo, discutiremos como compartilhar sua biblioteca como NuGet Packagepara que possa ser consumido em outro projeto. A criação de um pacote começa com o código que você deseja empacotar e compartilhar com outras pessoas, seja por meio da galeria pública nuget.org ou de uma galeria privada em sua organização. O pacote também pode incluir arquivos adicionais, como umreadme que é exibido quando o pacote é instalado e pode incluir transformações em determinados arquivos de projeto.

Vamos agora considerar um exemplo simples no qual criaremos um pacote NuGet de nossa biblioteca. Para isso, abra o prompt de comando e vá até a pasta onde está localizado o arquivo project.json de seu projeto de biblioteca.

Vamos agora executar o seguinte comando.

dotnet help

No final, você pode ver diferentes comandos como novo, restaurar e construir, etc.

O último comando é pack;isso criará um pacote NuGet. Vamos agora executar o seguinte comando.

dotnet pack

Agora você pode ver que os pacotes NuGet são produzidos na pasta bin; vamos abrir a pasta bin \ Debug.

Agora a questão é o que está dentro dos pacotes NuGet, para ver que podemos usar o NuGet Package Explorer. Vamos agora abrir o NuGet Package Explorer.

Selecione a primeira opção Open a local package.

Selecione os StringLibrary.1.0.0.nupkg e clique Open.

Você pode ver que na seção Conteúdo do pacote, temos apenas StringLibrary.dll. Na seção de metadados do pacote, você verá um pouco de informação sobre esta biblioteca como Id, Versões e todas as dependências.

Vamos agora abrir o StringLibrary.1.0.0.symbols.nupkg.

Neste pacote NuGet, você verá os arquivos de origem e o *.pdbarquivo também. Se você clicar duas vezes noStringLib.cs arquivo, você vê o código-fonte também.

Aqui a questão é: como configurar os metadados como versão, autores e descrição, etc.

O arquivo project.json é usado em projetos .NET Core para definir metadados de projeto, informações de compilação e dependências. Vamos agora abrir o arquivo project.json e adicionar as seguintes informações adicionais.

{ 
   "authors": [ "Mark Junior" ], 
   "description": "String Library API", 
   "version" : "1.0.1-*", 
   "supports": {}, 
   
   "dependencies": { 
      "Microsoft.EntityFrameworkCore": "1.1.0", 
      "Microsoft.NETCore.Portable.Compatibility": "1.0.1", 
      "NETStandard.Library": "1.6.0", 
      "System.Runtime.Serialization.Json": "4.0.3", 
      "System.Runtime.Serialization.Primitives": "4.3.0" 
   }, 
   "frameworks": { 
      "netstandard1.3": {} 
   } 
}

Agora você pode ver informações adicionais como nome do autor, descrição e versão adicionadas aqui. Vamos salvar este arquivo, construir o projeto da biblioteca e, em seguida, executar o comando “dotnet pack” novamente.

Dentro da pasta bin \ Debug, você pode ver que os pacotes StringLibrary NuGet são produzidos com a versão 1.0.1; vamos abri-lo no NuGet Package Explorer.

Você verá os metadados atualizados. A questão agora é: como podemos usá-lo em outro pacote.

Precisamos começar publicando em algum lugar no feed do NuGet e então podemos consumi-lo em outro projeto.

Existem duas opções para publicar os metadados atualizados -

  • Publique em nuget.org
  • Envie os metadados para o feed NuGet privado

Aqui, usaremos o feed NuGet privado porque é muito mais fácil do que configurar uma conta no nuget.org. Para saber como publicar seu pacote no nuget.org, você pode seguir todas as diretrizes especificadas aquihttps://docs.microsoft.com/en-us/nuget/create-packages/publish-a-package.

Siga estas etapas para enviar os metadados atualizados ao feed NuGet privado.

Step 1- Para começar, precisamos do utilitário de linha de comando nuget e temos que instalá-lo. Vamos agora abrir o Gerenciador de pacotes NuGet e pesquisar nuget.commandline.

Step 2 - Selecione Nuget.Commandline e clique em Install.

Step 3 - Clique OKpara instalar o Nuget.Commandline. Você também pode instalá-lo manualmente baixando-o do seguinte URLhttps://dist.nuget.org/index.html e, em seguida, configure a variável de ambiente.

Step 4 - Assim que a instalação for concluída, vamos abrir o prompt de comando novamente e ir para o bin\Debug pasta onde os pacotes NuGet estão localizados e especifique o seguinte comando -

nuget add StringLibrary.1.0.1.nupkg -Source D:\PrivateNugetPackages

Step 5 - No comando acima, adicionamos o pacote StringLibrary.1.0.1.nupkg ao nosso feed privado e a localização é D:\PrivateNugetPackages, -Source especifica a fonte do pacote.

Step 6 - Você pode ver que o StringLibraryestá instalado; aStringLibrary pode ainda ser adicionado ao feed privado.

Step 7 - Vamos para essa pasta.

Step 8 - Dentro do stringlibrary pasta, você verá outra pasta com o nome da versão e aqui é 1.0.1.

O pacote NuGet está localizado aqui.

Neste capítulo, discutiremos como consumir o pacote NuGet que criamos e publicamos em um feed NuGet privado. Então, primeiro iremos criar um projeto Xamarin.Forms. Precisamos primeiro entender o que é Xamarin.Forms.

  • Xamarin.Forms é uma estrutura que permite aos desenvolvedores criar rapidamente interfaces de usuário multiplataforma.

  • Xamarin.Forms é uma abstração de kit de ferramentas de interface do usuário com suporte nativo de plataforma cruzada que permite aos desenvolvedores criar facilmente interfaces de usuário que podem ser compartilhadas entre Android, iOS, Windows e Windows Phone.

  • As interfaces do usuário são renderizadas usando os controles nativos da plataforma de destino, permitindo que os aplicativos Xamarin.Forms retenham a aparência e o comportamento apropriados para cada plataforma.

Para iniciar o Xamarin.Forms, precisamos de alguns recursos adicionais no Visual Studio 2015. Deixe-nos modificar seu Visual Studio 2015 e certifique-se de que a seguinte opção de desenvolvimento móvel multiplataforma esteja selecionada.

Assim que a instalação for concluída, vamos atualizar o Xamarin selecionando Tools → Options…

Role para baixo e expanda Xamarin no painel esquerdo e selecione Other. No canto superior direito da caixa de diálogo, clique emCheck Now para ver se há atualizações disponíveis.

Você pode ver que as atualizações estão disponíveis, vamos clicar no Downloadbotão para iniciar o download. Assim que o download for concluído, você será notificado para instalar as atualizações.

Vamos agora abrir o Visual Studio novamente e selecionar o File → New → Project… opção de menu.

No painel esquerdo, selecione o Visual C# → Cross-Platform modelo e no painel do meio, selecione Blank Xaml App (Xamarin.Forms Portable). Insira o nome no campo Nome e clique em OK.

Selecione a versão de destino e a versão mínima e clique em OK.

Você verá uma série de projetos; no topo temos a biblioteca PCL que será compartilhada entre todas as plataformas como Android, iOS, UWP, Windows 8.1 e Windows Phone 8.1.

Aqui, vamos nos concentrar na biblioteca PCL e trazer alguns códigos aqui. Vamos expandir o código.

Neste modelo Xamarin.Forms, você pode ver o App.xaml genérico e MainPage.xaml, usa a estrutura Xamarin.Forms XAML que funciona nessas plataformas.

Precisamos importar nossos códigos e também precisamos do feed NuGet privado que configuramos no último capítulo.

Vamos agora abrir o Gerenciador de Pacotes NuGet. Clique na roda ao lado da lista suspensa Fonte do pacote.

Precisamos adicionar nosso feed privado aqui, vamos clicar no plus (+) button.

Você verá que outra caixa de seleção é adicionada no Available package sources seção, vamos especificar um nome e caminho de origem e clicar OK.

Vamos agora para a guia Browse e selecione PrivateSource na lista suspensa Package source e você verá o pacote StringLibrary NuGet. Selecione StringLibrary e clique emInstall.

Clique em OK e você verá um erro.

Não podemos usar a biblioteca com o perfil .NETPortable versão 259, corrigiremos esse erro no próximo capítulo.

Neste capítulo, corrigiremos o erro que obtivemos ao instalar o pacote NuGet de nosso feed privado no projeto Xamarin.Forms.

Vamos entender melhor o problema em breve. Para começar, vamos clicar com o botão direito na biblioteca PCL e selecionar Propriedades.

Nesta página, você verá toda a série de frameworks direcionados. Pelo erro, você pode ver que o perfil .NETPortable 259 não é compatível com nossa StringLibrary 1.0.1. No entanto, ele está tentando obter referência da biblioteca .NET Standard 1.1.

Vamos agora ver a Biblioteca .NET Standard e identificar qual plataforma não é compatível com nossa biblioteca.

Você pode ver que o Windows Phone Silverlight 8 é compatível com .NET Standard 1.0. Se você abrir a página da Web a seguir, verá que o Profile259 oferece suporte apenas ao .NET Standard 1.0.

Vamos agora desmarcar o Windows Phone Silverlight 8.

Clique no OK botão.

Agora, para corrigir esse problema, clique em OK e cancele a caixa de diálogo Alterar destinos e, em seguida, abra o console do gerenciador de pacotes e execute o seguinte comando.

PM > Uninstall-Package Xamarin.Forms

Vamos agora para as Propriedades da biblioteca PCL. Clique no botão Alterar.

Desmarque Windows Phone Silverlight 8 e clique em OK.

Agora você pode ver que o Windows Phone Silverlight 8 não está mais disponível na estrutura Targeted. Você também pode ver o perfil que é o alvo agora. Para ver isso, vamos descarregar a biblioteca PCL e editar o arquivo XamarinApp.csproj.

Você pode ver agora que TargetFrameworkProfile agora é Profile111.

Se você abrir a documentação, verá que o Profile111 oferece suporte ao .NET Standard 1.1.

Vamos agora recarregar o PCL novamente e abrir o Gerenciador de Pacotes NuGet e tentar instalar o pacote StringLibrary do feed privado.

Na lista suspensa Comportamento de dependência, selecione Ignorar dependências e clique em Install.

Você pode ver que o pacote StringLibrary agora está instalado a partir do feed privado. Se você expandir as referências de PCL, verá que a referência StringLibrary também é adicionada conforme mostrado abaixo.

Tínhamos desinstalado o Xamarin.Forms para o problema do Windows Phone Silverlight 8. O Xamarin.Forms precisa ser instalado novamente. Recomenda-se que a mesma versão seja instalada.

Assim que a instalação for concluída, vamos usar a funcionalidade StringLibrary em seu aplicativo.

Neste capítulo, discutiremos como criar um projeto de teste usando o .NET Core. O teste de unidade é um processo de desenvolvimento para o software que possui as menores partes testáveis ​​de um aplicativo, que são chamadas de unidades. Eles são examinados individual e independentemente para qualquer operação adequada. O teste de unidade pode ser automatizado ou feito manualmente.

Vamos agora abrir a caixa de diálogo Novo Projeto e selecionar Visual C# → .NET Core modelo.

Nesta caixa de diálogo, você pode ver que não há modelo de projeto para teste de unidade. Para criar um projeto de teste de unidade, devemos usar o utilitário de linha de comando. Vamos para a pasta Solução que criamos; crie uma pasta de teste e dentro da pasta de teste crie outra pasta e chame-aStringLibraryTests.

Vamos agora usar o utilitário de linha de comando dotnet para criar um novo projeto de teste executando o seguinte comando -

dotnet new -t xunittest

Agora você pode ver que um novo projeto C # foi criado; vamos examinar a pasta executando ov comando e você verá project.json e Tests.cs arquivos como mostrado abaixo.

Aqui está o código no arquivo project.json.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "debugType": "portable" 
   }, 
   "dependencies": { 
      "System.Runtime.Serialization.Primitives": "4.1.1", 
      "xunit": "2.1.0", 
      "dotnet-test-xunit": "1.0.0-rc2-192208-24" 
   }, 
   "testRunner": "xunit", 
   "frameworks": { 
      "netcoreapp1.0": { 
         "dependencies": { 
            "Microsoft.NETCore.App": { 
               "type": "platform", 
               "version": "1.0.1" 
            } 
         }, 
         "imports": [ 
            "dotnet5.4", 
            "portable-net451+win8" 
         ] 
      } 
   } 
}

A seguir está o código no arquivo Test.cs.

using System; 
using Xunit; 
namespace Tests { 
   public class Tests { 
      [Fact] 
      public void Test1() { 
         Assert.True(true); 
      } 
   } 
}

Para obter as dependências necessárias do NuGet, vamos executar o seguinte comando -

dotnet restore

Podemos executar o teste quando as dependências necessárias forem restauradas.

Você pode ver que a compilação foi bem-sucedida; conforme você desce, pode ver algumas informações sobre o teste executado.

Atualmente temos 1 teste executado, 0 erro, 0 falhado, 0 ignorado e o tempo gasto pelo processo de execução também mencionado como informação.

Neste capítulo, discutiremos como executar testes no Visual Studio. O .NET Core foi projetado tendo a capacidade de teste em mente, para que a criação de testes de unidade para seus aplicativos seja mais fácil do que nunca. Neste capítulo, iremos executar e executar nosso projeto de teste no Visual Studio.

Vamos abrir a solução FirstApp no ​​Visual Studio.

Você pode ver que ele tem apenas dois projetos e não será capaz de ver o projeto de teste porque não adicionamos esse projeto em nossa solução.

Vamos adicionar uma pasta primeiro e chamá-la test.

Clique com o botão direito no test pasta.

Selecione project.json arquivo e clique Open.

A captura de tela a seguir mostra o código em Tests.cs arquivo como saída.

É a implementação padrão e está apenas testando se True é igual a true. É a estrutura de teste xUnit e você verá o atributo Fact que anota e denota o método de teste.

using System; 
using Xunit; 
  
namespace Tests { 
   public class Tests { 
      [Fact] 
      public void Test1() { 
         Assert.True(true); 
      } 
   } 
}

A seguir está a implementação de project.json Arquivo.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "debugType": "portable" 
   }, 
   "dependencies": { 
      "System.Runtime.Serialization.Primitives": "4.1.1", 
      "xunit": "2.1.0", 
      "dotnet-test-xunit": "1.0.0-rc2-192208-24" 
   }, 
   "testRunner": "xunit", 
   "frameworks": { 
      "netcoreapp1.0": { 
         "dependencies": { 
            "Microsoft.NETCore.App": { 
               "type": "platform", 
               "version": "1.0.1" 
            }
         }, 
         "imports": [ 
            "dotnet5.4", 
            "portable-net451+win8" 
         ] 
      } 
   } 
}

Dentro project.json, a dependência mais importante para a estrutura de teste é o xunit, que traz o atributo Fact. Ele traz a estrutura de teste e APIs para teste com xunit.

Nós também temos o dotnet-test-xunit, este é um adotador para que o xunit possa funcionar com .NET Core, especificamente com dotnet testutilitário de linha de comando. Então você verá otestRunner que irá executar o xunit e você também pode ver o netcoreapp1.0 estrutura.

Você verá a dependência .NETCore.App abaixo.

Para executar o teste no Visual Studio, vamos abrir o Test Explorer do Test → Window → Test Explorer opção de menu.

E você pode ver que o Visual Studio detecta automaticamente o teste. O nome do teste consiste emnamespace.className.TestMethodName. Vamos agora clicar emRun All button in Test Explorer.

Primeiro, ele criará o código e executará o teste, e você verá o tempo total gasto pelo teste. Vamos mudar o método de teste para que possamos ver a saída quando o teste falhar.

using System; 
using Xunit; 
  
namespace Tests { 
   public class Tests { 
      [Fact] 
      public void Test1() { 
         Assert.True(false); 
      } 
   } 
}

Vamos executar o teste novamente clicando no Run All Botão de link.

Agora você pode ver o test fracasso.

Neste capítulo, vamos testar nossa StringLibrary e, para isso, precisamos reorganizar nossos projetos para que possamos seguir a convenção padrão.

Vamos abrir o global.json Arquivo.

{ 
   "projects": [ "src", "test" ], 
   "sdk": { 
      "version": "1.0.0-preview2-003131" 
   } 
}

No topo deste arquivo, você verá as configurações do projeto e ele configura algumas pastas, como src e test por padrão.

Como por convenção, devemos ter projetos nessas pastas, esta é a nova convenção e que será usada como parte do .NET Core.

No Solution Explorer, você pode ver que tanto o projeto do console quanto o projeto da biblioteca estão dentro do src pasta enquanto o projeto de teste está dentro test pasta.

E a estrutura de projetos no Solution Explorer não representa onde os projetos existem fisicamente no disco. Vamos agora abrir a pasta Solução e você verá queStringLibrary projeto não está dentro do src pasta.

Você pode ver que ambos src e test as pastas são mapeadas para a convenção especificada no global.jsonArquivo. No entanto, temos um projeto StringLibrary que está fora da convenção. Vamos agora adicionar oStringLibrary projeto dentro do src pasta.

Na pasta src, temos dois projetos e precisamos corrigir o problema para que possamos usar todos os projetos corretamente. Vamos voltar ao Visual Studio e clicar com o botão direito no projeto StringLibrary e selecionar a opção Remover. Não o excluirá, mas apenas removerá o projeto.

Agora clique com o botão direito na pasta src e selecione Add → Existing Project…

Navegue até o projeto StringLibrary que agora está dentro do src pasta, selecione o StringLibrary.csproj arquivo e clique Open.

Agora temos que remover a referência de StringLibrary de project.json arquivo do aplicativo de console.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      }, 
      "NuGet.CommandLine": "3.5.0", 
      "System.Runtime.Serialization.Json": "4.0.3" 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "dependencies": { }, 
         "imports": "dnxcore50" 
      } 
   } 
}

Salve as alterações e adicione uma referência de StringLibrary novamente em seu projeto de console.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      }, 
   "NuGet.CommandLine": "3.5.0", 
      "System.Runtime.Serialization.Json": "4.0.3" 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "dependencies": { 
            "StringLibrary": { 
               "target": "project" 
            } 
         }, 
         "imports": "dnxcore50" 
      } 
   } 
}

Agora tudo deve estar funcionando novamente e você pode construir StringLibrary e depois FirstApp(projeto do console) sem nenhum erro. Vamos agora testar a funcionalidade StringLibrary usando xunit. Precisamos adicionar referência de StringLibrary em nosso projeto de teste. Clique com o botão direito do mouse no projeto References of StringLibraryTests e selecione Add Reference…

Clique OK que irá adicionar uma referência de StringLibraryao nosso projeto de teste. Vamos agora substituir o seguinte código noTests.cs Arquivo.

using System; 
using Xunit; 
using StringLibrary; 
  
namespace Tests { 
   public class Tests { 
      [Fact] 
      public void StartsWithUpperCaseTest() { 
         string input = "Mark"; 
         Assert.True(input.StartsWithUpper()); 
      } 
      [Fact] 
      public void StartsWithLowerCaseTest() { 
         string input = "mark"; 
         Assert.True(input.StartsWithLower()); 
      } 
      [Fact] 
      public void StartsWithNumberCaseTest() { 
         string input = "123"; 
         Assert.True(input.StartsWithNumber()); 
      } 
   } 
}

Você pode ver que temos três métodos de teste que irão testar a funcionalidade da StringLibrary. Vamos clicar noRun All link e você verá a seguinte saída no Test Explorer.

Você também pode executar os testes na linha de comando. Vamos abrir o prompt de comando e executar odotnet test comando.

Neste capítulo, discutiremos o Managed Extensibility Framework (MEF). MEF pode ser usado para extensibilidade de plug-in de terceiros ou pode trazer os benefícios de uma arquitetura tipo plug-in fracamente acoplada para aplicativos regulares.

  • MEF é uma biblioteca para a criação de aplicativos leves e extensíveis.

  • Ele permite que os desenvolvedores de aplicativos descubram e usem extensões sem a necessidade de configuração.

  • MEF é parte integrante do .NET Framework 4 e está disponível onde quer que o .NET Framework seja usado, o que melhora a flexibilidade, manutenção e testabilidade de grandes aplicativos.

  • Você pode usar o MEF em seus aplicativos cliente, sejam eles Windows Forms, WPF ou qualquer outra tecnologia, ou em aplicativos de servidor que usam ASP.NET.

  • MEF foi portado como Microsoft.Composition para o .NET Core também, mas parcialmente.

  • Somente System.Composition é portado, e System.ComponentModel.Compositionainda não está disponível. Isso significa que não temos os catálogos que podem carregar tipos de assemblies em um diretório.

Neste capítulo, aprenderemos apenas como podemos usar o MEF no aplicativo .NET Core.

Vamos entender um exemplo simples em que usaremos o MEF no aplicativo de console .NET Core. Vamos agora criar um novo projeto de console do .NET Core.

No painel esquerdo, selecione Templates → Visual C# → .NET Core e, em seguida, no painel do meio, selecione Aplicativo de console (.NET Core).

Insira o nome do projeto no campo Nome e clique em OK.

Uma vez que o projeto é criado, precisamos adicionar a referência de Microsoft.Composition para que possamos usar o MEF. Para fazer isso, vamos clicar com o botão direito no projeto no Solution Explorer eManage NuGet Packages…

Procurar por Microsoft.Composition e clique Install.

Clique no OK botão.

Clique no I Accept botão.

Quando a instalação for concluída, você encontrará um erro nas Referências.

Vamos abrir o project.json Arquivo.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
  
   "dependencies": { 
      "Microsoft.Composition": "1.0.30", 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1" 
      } 
   }, 
  
   "frameworks": { 
      "netcoreapp1.0": { 
         "imports": "dnxcore50" 
      } 
   } 
}

Você pode ver que o Microsoft.Composition dependência é adicionada, mas o problema é que este pacote não é compatível com dnxcore50. Então, precisamos importarportablenet45+win8+wp8+wpa81. Vamos agora substituir o seuproject.json arquivo com o seguinte código.

{ 
   "version": "1.0.0-*", 
   "buildOptions": { 
      "emitEntryPoint": true 
   }, 
   "dependencies": { 
      "Microsoft.Composition": "1.0.30", 
      "Microsoft.NETCore.App": { 
         "type": "platform", 
         "version": "1.0.1"
      } 
   }, 
   "frameworks": { 
      "netcoreapp1.0": { 
         "imports": "portable-net45+win8+wp8+wpa81" 
      } 
   } 
}

Salve este arquivo e você verá que o erro foi corrigido.

Se você expandir as referências, verá uma referência de Microsoft.Composition.

Primeiro, precisamos criar uma interface que deve ser exportada e implementar a interface e decorar a classe com o atributo export. Vamos agora adicionar uma nova classe.

Digite o nome da sua turma no campo Nome e clique em Add.

Vamos adicionar o seguinte código no PrintData.cs Arquivo.

using System; 
using System.Collections.Generic; 
using System.Composition; 
using System.Linq; 
using System.Threading.Tasks; 
  
namespace MEFDemo { 
   public interface IPrintData { 
      void Send(string message); 
   } 
   [Export(typeof(IPrintData))] 
   public class PrintData : IPrintData { 
      public void Send(string message) { 
         Console.WriteLine(message); 
      } 
   } 
}

Conforme mencionado acima, Catálogos não estão disponíveis no namespace Microsoft.Composition. Portanto, ele carregará todos os tipos do Assembly com atributo de exportação e anexará ao atributo de importação conforme mostrado no método Compose no arquivo Program.cs.

using System; 
using System.Collections.Generic; 
using System.Composition; 
using System.Composition.Hosting; 
using System.Linq; 
using System.Reflection; 
using System.Threading.Tasks; 
  
namespace MEFDemo { 
   public class Program { 
      public static void Main(string[] args) { 
         Program p = new Program(); 
         p.Run(); 
      } 
      public void Run() { 
         Compose(); 
         PrintData.Send("Hello,this is MEF demo"); 
      } 
      [Import] 
      public IPrintData PrintData { get; set; } 
      
      private void Compose() { 
         var assemblies = new[] { typeof(Program).GetTypeInfo().Assembly }; 
         var configuration = new ContainerConfiguration() 
            .WithAssembly(typeof(Program).GetTypeInfo().Assembly); 
         
         using (var container = configuration.CreateContainer()) { 
            PrintData = container.GetExport<IPrintData>(); 
         } 
      } 
   } 
}

Vamos agora executar o seu aplicativo e você verá que ele está sendo executado instanciando o PrintData classe.

Para saber mais sobre o MEF, visite o seguinte Url https://msdn.microsoft.com/en-us/library/dd460648%28v=vs.110%29.aspx para mais detalhes.

Neste capítulo, entenderemos os próximos recursos do .NET Core. Começaremos com as ferramentas de linha de comando .NET abrindo o seguinte Url no navegadorhttps://github.com/dotnet/cli

Para saber mais sobre o progresso, você pode baixar a versão mais recente do .NET Core SDK rolando para baixo e verá a seção Instalador e Binários.

Você pode ver a versão mais recente das ferramentas de visualização para diferentes sistemas operacionais, deixe-nos selecionar o Instalador de acordo com seu sistema operacional.

Estamos trabalhando na versão 1 do .NET Core 2.0.

Vamos agora dar uma olhada em nossas ferramentas atuais, abrindo o prompt de comando e executando o seguinte comando.

dotnet --info

Você verá informações sobre a versão atualmente instalada das ferramentas de linha de comando .NET em seu sistema, conforme mostrado abaixo.

Você pode ver que atualmente temos 2 ferramentas de visualização. Vamos agora executar o seguinte comando para ver sobre onew comando.

dotnet help new

Para a nova linguagem de comando do projeto, você pode selecionar como C # e F # e o tipo de projeto, etc.

Vamos agora ver as mudanças na versão mais recente do .NET Core. Depois de fazer o download do instalador, clique duas vezes nele para instalá-lo. Clique em Instalar.

A captura de tela a seguir mostra o processo de instalação.

Isso iniciará o processo de instalação. Depois de concluída a instalação, feche esta caixa de diálogo.

Abra o prompt de comando e execute o seguinte comando.

dotnet --info

Você verá informações da versão atualmente instalada das Ferramentas de Linha de Comando .NET em seu sistema, conforme mostrado abaixo.

Agora você pode ver que temos o conjunto de ferramentas preview1 do .NET Core 2. Vamos agora executar o seguinte código no prompt de comando para ver sobre o novo comando no .NET Core 2 preview1.

dotnet help new

O comando também ajuda a baixar pacotes para o cache de pacotes.

O comando abre a seguinte página da Web que contém informações sobre o novo comando no .NET Core 2 preview1.

Vamos rolar para baixo, agora você pode ver que podemos criar o aplicativo .NET Core com mais modelos.

Agora podemos criar mstest, web, mvc e webapi projetos também usando a linha de comando.

O .NET Core decidiu descartar o project.json e voltar para o MSBuild e * .csproj. Isso é algo que já aconteceu no recém-lançado conjunto de ferramentas .Net Core 2.0 preview1. Isso é bastante decepcionante, porque o project.json foi uma lufada de ar fresco. No entanto, é compreensível e tem muitas vantagens.

Vamos agora discutir as vantagens que a mudança traz -

  • Isso tornaria a transição das soluções existentes do Visual Studio para o .NET Core direta.

  • É uma grande mudança e também permitirá alavancar o investimento existente em CI / RM com base no MSBuild.

  • Durante a compilação no MSBuild, podemos pensar em compilação incremental, resolvendo dependências de tempo de compilação, gerenciamento de configuração, etc.

  • É necessário muito trabalho para enviar dotnet cli a tempo, porque não se trata mais apenas do ASP.NET Core, mas também de aplicativos de console, aplicativos UWP, etc.

A seguir estão as alterações no MSBuild e * .csproj -

  • O arquivo Project.json (* .xproj) será substituído por MSBuild (* .csproj).

  • Os recursos em project.json começarão a ser mesclados de volta no * .csproj.

  • Ainda não está claro o que eles farão com a lista de pacotes, mas foi mencionado que eles podem mantê-la como json em nuget.json ou mesclá-lo no *.csproj.

  • Supostamente, essa transição deve ser suave e potencialmente automática se estiver usando o Visual Studio.

Vantagens do MSBuild

  • O MSBuild é open source e está disponível no GitHub e está fadado a se tornar totalmente multiplataforma.

  • O MSBuild simplificará drasticamente e ajustará a estrutura do *.csproj.

  • A Microsoft também está introduzindo um novo sistema de projeto que permitirá muitos cenários sem a necessidade do Visual Studio e os detalhes são fornecidos neste Url https://github.com/dotnet/roslyn-project-system/.

  • O objetivo é que, mesmo com a configuração do MSBuild, trabalhar com compilações e projeto seja tão integrado no IDE do Visual Studio quanto fora dele.

MSBuild vs project.json

Vamos agora criar um novo projeto de console com as ferramentas de preview2 do .NET Core executando o seguinte comando.

dotnet new -t console

Para ver todos os arquivos criados dentro deste projeto, execute o dir comando.

Você pode ver que dois arquivos são criados, Program.cs e project.json Arquivo.

Vamos agora criar um aplicativo de console com as ferramentas de preview1 do .NET Core 2, executando o seguinte comando.

dotnet new console

Para ver todos os arquivos criados dentro deste projeto, execute o dircomando. Você pode ver que três arquivos são criados,Program.cs, NuGet.config e MSBuild.csproj em vez do arquivo project.json.

Vamos agora comparar project.json e MSBuild.csproj arquivos lado a lado.

À esquerda, temos o arquivo no formato json, enquanto à direita, o arquivo está no formato XML. Você pode ver que no arquivo project.json, dentro da seção de dependências, hánetcoreapp1.0, enquanto estiver no arquivo MSBuild.csproj, você verá o netcoreapp2.0.

Neste capítulo, discutiremos como restaurar e construir seu arquivo MSBuild (* .csproj) usando o utilitário de linha de comando. Para ver quais comandos estão disponíveis na visualização 1 do .NET Core 2.0, vamos executar o seguinte comando.

dotnet help

Você verá todos os comandos como novo, restaurar, construir, etc.

A seguir está a implementação padrão em Program.cs Arquivo.

using System;  
namespace MSBuild { 
   class Program { 
      static void Main(string[] args) { 
         Console.WriteLine("Hello World!"); 
      } 
   } 
}

Vamos agora executar o seguinte comando para ver o progresso.

dotnet build

Você verá muitos erros. Esses erros precisam ser corrigidos.

Vamos agora executar o seguinte comando.

dotnet restore

Você pode ver que todos os pacotes foram restaurados. Algumas novas pastas e arquivos também foram gerados.

Para ver a estrutura do diretório, vamos executar o seguinte comando.

tree /f

A seguir está a estrutura do diretório -

Vamos agora reconstruir o projeto executando o seguinte comando novamente.

dotnet build

Agora seu projeto será compilado com êxito sem nenhum erro e o MSBuild.dll também será criado.

Para ver a saída, vamos executar o seguinte comando -

dotnet run

Você pode ver a seguinte saída em seu console.

Neste capítulo, iremos migrar o aplicativo de console que contém o project.json sistema de construção de arquivos em vez de MSBuild (*.csproj). Portanto, temos um projeto antigo que contém os seguintes arquivos.

Agora a questão é: por que precisamos da migração? Este projeto foi criado usando as ferramentas do .NET Core 1.0 preview 2 e agora instalamos as ferramentas do .NET Core 2.0 preview 1. Agora, ao construir este aplicativo usando o utilitário de linha de comando .NET Core 2.0, você verá o seguinte erro.

Isso ocorre porque o project.jsonO sistema de compilação não está mais disponível no .NET Core 2.0, portanto, precisamos da migração para que funcione corretamente. Para ver os comandos disponíveis, vamos executar o seguinte comando.

dotnet help

Na seção de comandos, você pode ver os diferentes comandos e também pode ver o migrate comando que irá migrar um projeto baseado em project.json para um projeto baseado em MSBuild.

Vamos agora executar o seguinte comando.

dotnet migrate

Você verá um resumo do processo de migração e aqui também poderá ver que um projeto foi migrado com sucesso.

Vamos agora ver a estrutura do diretório usando o seguinte comando.

tree /f

Agora você verá o arquivo * .csproj junto com o arquivo Program.cs no diretório raiz do projeto e o project.json é movido para a pasta de backup.

Vamos abrir o console.csprojArquivo. Agora você pode restaurar e construir este projeto usando o sistema MSBuild executando o seguinte comando.

dotnet restore

Agora você pode ver que todos os pacotes foram restaurados.

Agora você pode construir seu projeto com o seguinte comando.

dotnet build

Agora você pode ver que o projeto foi construído com sucesso usando MSBuild e console.dll também é gerado em ..\bin\Debug\netcoreapp1.0 pasta.

A captura de tela a seguir mostra a estrutura de diretório e arquivos.