DEV Community: Tiago Henrique

Me tornando um desenvolvedor .NET #1

Tiago Henrique — Thu, 13 Oct 2022 10:54:44 +0000

Introdução

Neste segundo artigo, minha intenção é explorar os recursos iniciais de desenvolvimento .NET com a linguagem C#, uma linguagem moderna, orientada a objetos e fortemente tipada. Se você ainda não está completamente familiarizado com esta linguagem, não se preocupe, iremos nos aprofundar nos estudos cada vez mais.

No artigo anterior, abordei alguns conceitos introdutórios sobre a plataforma, seus componentes e recursos. Eu recomendo que você o leia para poder compreender melhor, se for o caso, alguns pontos que irei abordar mais para frente. Vou considerar que já conhecemos basicamente o que é e para que serve o .NET, e que já temos o SDK (Software Development Kit) instalado.

Eu estudo em um Arch Linux. Isso é importante destacar por duas razões: Primeiro: porque o IDE (Integrated Development Environment) Visual Studio, indicado para desenvolvimento .NET, não tem suporte para Linux. Apesar de um IDE possuir diversos recursos que facilitam o desenvolvimento, o Visual Studio Code dá conta do recado neste momento de aprendizado. Particularmente, eu uso Neovim com Language Server Protocol configurado. Segundo: eu começarei estudando a CLI (Command Line Interface) do dotnet, algo que um usuário do IDE usará poucas vezes no dia a dia. Portanto, alguns podem considerar irrelevante parte desse conteúdo e podem pular para o que achar mais relevante.

Tópicos

Visão geral da CLI (Command Line Interface)
Estrutura de comandos da CLI
Estudando um aplicativo de console
Fluxo de compilação
Namespaces
Arquivos de projeto e Entry Point
Resumo
Referências

Visão Geral da CLI

A Interface de Linha de Comando do .NET é uma ferramenta multiplataforma para desenvolvimento, criação, execução e publicação de aplicações .NET e vem como parte do conjunto de recursos do SDK.

Como a maioria das CLIs, a do .NET consiste no driver – um arquivo executável – opções e argumentos de comando. O driver (dotnet) tem basicamente as seguintes responsabilidades:

Executar programas: abrange o fluxo de desenvolvimento, isto é, execução de testes, compilação do código e comandos de migração para atualizar projetos.

Gerenciar dependências: abrange instalação, remoção, limpeza após a instalação de pacotes e atualização dos pacotes.

Criar e publicar pacotes: abrange tarefas como criar um pacote compactado e efetuar um push do pacote para um registro, por exemplo (aos poucos veremos cada uma dessas coisas).

Voltar aos tópicos

Estrutura de comando

$ dotnet <COMANDO> [opções-do-comando] [argumentos]

Quando passamos um comando para o executável (dotnet) inicia-se a execução daquele comando, por exemplo:

$ dotnet build

Esse comando constrói um projeto com suas dependências (também veremos como isso acontece mais para frente.)

$ dotnet new --list

Lista uma séries de opções de modelos pré preparados que você pode criar.

Cada comando define suas próprias opções e argumentos e também possuem uma opção --help muito útil quando se sentir perdido.

Portanto, temos:

Comando:

Executa uma ação: compila o código, adiciona pacotes, referências ou publica o código (veremos mais para frente).

Argumentos:

Argumentos que você passa na linha de comando são aqueles do comando invocado. Por exemplo, quando você executa dotnet publish my_app.csproj, o argumento my_app.csproj indica que o projeto a ser publicado é passado para o comando publish.

Opções:

As opções são aquelas do comando invocado. Por exemplo:
dotnet publish --output /build_output, é a opção que indica o caminho da saída do aplicativo a ser publicado e esse valor é passado para o comando publish.

Uma lista completa dos comandos do CLI .NET e seus detalhes pode ser consultados aqui, mas lembre-se sempre da opção --help.

Voltar aos tópicos

Estudando um aplicativo de console

Antes de iniciar um projeto, é importante saber que, ao instalar o SDK do .NET, recebemos dezenas de modelos pré preparados como aplicativos de console, bibliotecas de classes, projetos de testes unitários, aplicativos ASP.NET, etc. Para listar esses modelos disponíveis, como vimos acima, executamos o comando dotnet new com a opção -l ou --list.

Para iniciar um aplicativo de console, você pode executar:
$ dotnet new console. Contudo, você pode usar a opção --help tanto após new quanto após console para verificar as opções disponíveis para cada. Se fizer isso após o comando new, verá que existem duas opções (-n e -o) ambas direcionam a saída gerada em um diretório nomeado por você. Portanto, se executar:

$ dotnet new console -o HelloWorld

Verá que um diretório será criado com o valor passado para opção -o , no caso, HelloWorld. O mesmo o corre com a opção n. Crie um projeto console chamado HelloWorld e dê uma espiada no que existe dentro dele:


$ tree HelloWorld
HelloWorld
├── HelloWorld.csproj
├── obj
│   ├── HelloWorld.csproj.nuget.dgspec.json
│   ├── HelloWorld.csproj.nuget.g.props
│   ├── HelloWorld.csproj.nuget.g.targets
│   ├── project.assets.json
│   └── project.nuget.cache
└── Program.cs

1 directory, 7 files

Essa é a estrutura básica do projeto e, durante o artigo, veremos o que são todos esses arquivos. Se abrirmos o arquivo Program.cs, teremos a instrução clássica Hello, World. Não é nenhuma novidade que, se executarmos esse código, a mensagem será impressa no console. Para fugir um pouco desse padrão, vamos começar tentando algo diferente.

A maioria dos programas processa alguma entrada para produzir uma saída; basicamente essa é a definição de computação. Um programa obtêm dados de entrada de maneiras diversas, mas, com frequência, a entrada vem de uma fonte externa: um arquivo, uma conexão de rede, os dados da saída de outro programa ou de um usuário em um teclado. No arquivo Program.cs, você pode apagar o que estiver escrito e colar o seguinte código:

namespace HelloWorld;

class Program
{
    static void Main(string[] args)
    {
        string path = @"./message.txt";
        if (!File.Exists(path))
        {
            // Crie um arquivo e grave uma mensagem nele.
            using StreamWriter message = File.CreateText(path);
            message.WriteLine("Olá, Mundo");
        }
        // Leia o conteúdo do arquivo criado.
        using (StreamReader message = File.OpenText(path))
        {
            string content;
            while ((content = message.ReadLine()) != null)
            {
                Console.WriteLine(content);
            }
        }
    }
}

Não precisamos nos preocupar com a sintaxe do C#, nesse momento. Entretanto, o que este código faz é criar um arquivo no diretório atual chamado message.txt e gravar nele a mensagem “Olá, Mundo!”, depois, enquanto existirem bytes para serem lidos, ele imprime no console o conteúdo desse arquivo. Quando isso se torna falso, o programa encerra.

Muita coisa pode ser dita a respeito deste código. Por exemplo, no primeiro artigo conhecemos os conceitos de código gerenciado e não gerenciado e como o .NET trabalha com esses conceitos. File, aqui, é um exemplo de tipo gerenciado que acessa recursos não gerenciados pelo CLR (no caso, cria um arquivo e o acessa no contexto do dispositivo). Note que o arquivo .txt foi criado na pasta atual.

$ tree -L 1
.
├── bin
├── message.txt
├── obj
├── Program.cs
└── HelloWorld.csproj

Há muitos outros tipos de recursos não gerenciados e tipos de biblioteca de classes que os encapsula.

File, StreamWriter e StreamReader, são tipos que lidam com fluxos de dados permitindo leitura e gravação em arquivos definidos na biblioteca IO (Input/Output) no namespace System.IO que fornece suporte básico a arquivos e diretórios do sistema operacional. O Console.WriteLine() também é um tipo definido no namespace System, ou seja, System.Console.WriteLine. Mas, não se preocupe pois, na próxima seção, veremos mais sobre namespaces.

Se você estiver se perguntando o motivo de não ver nada relacionado a declaração de bibliotecas no código, eu te digo que nem sempre foi assim. Antes da versão 10 do C#, era necessário declarar namespaces individuais usando a diretiva using no topo de cada arquivo, por exemplo:

using System;
using System.Io;

class Program
{
 ...

Mas o uso de alguns namespaces eram (e ainda são) muitos comuns, portanto, com a versão 10 do C# foi estabelecido as diretivas globais de uso, que, entre outros detalhes, permitem ao compilador considerar certos namespaces para todo o projeto. Isso quer dizer que o SDK importa implicitamente os seguintes namespaces:

Contudo, a diretiva using, que veremos mais para frente, ainda é necessária para casos que fogem desse padrão.

Mas, a ideia é entender o que vai acontecer agora: Execute dotnet build e note que um novo diretório foi adicionado a raiz do projeto: /bin.

bin
└── Debug
    └── net6.0
        ├── HelloWorld
        ├── HelloWorld.deps.json
        ├── HelloWorld.dll
        ├── HelloWorld.pdb
        ├── HelloWorld.runtimeconfig.json
        └── ref
            └── HelloWorld.dll

Este é o produto resultante da construção do aplicativo. Aqui, temos o diretório Debug que armazena um conjunto de arquivos binários, ou: Os assemblies de saída do programa. Esse diretório inclui: o código do projeto em IL (Intermediate Language) – vimos um pouco sobre isso no artigo anterior – com extensão .dll.

arquivos de símbolo de depuração, com uma extensão .pdb (veremos logo, logo).
um arquivo .deps.json, que lista as dependências do aplicativo (ou biblioteca, se fosse o caso).
um arquivo .runtimeconfig.json, que especifica o tempo de execução compartilhado e sua versão.
pode conter também outras bibliotecas das quais o projeto depende (por meio de referências de projeto ou referências de pacote do NuGet que veremos no próximo artigo da série).

Vamos ver esse programa funcionando:

$ dotnet run

Olá, Mundo

Nesse ponto, você deve estar se perguntando sobre o diretório obj. Se você reparou, um diretório Debug também foi gerado lá e, entre outras coisas, também se encontram os assemblies de saída do programa. A próxima pergunta que pode surgir é: Por que dois diretórios para a mesma coisa?

Na verdade, não são necessariamente a mesma coisa. Os dois diretórios armazenam o código em IL, mas seus propósitos são distintos. E para deixar isso mais claro, precisamos entender o processo de compilação.

Voltar aos tópicos

Fluxo de compilação

Acontece que o uso coloquial da palavra “compilação” pode gerar certa confusão, pelo menos para mim que sou meio lento. Muitas vezes, nos referimos a compilação quando, na verdade, estamos nos referindo a build (construção). Compilação não necessariamente é o mesmo que apenas gerar um arquivo executável. Em vez disso, é um processo de vários estágios que, de maneira geral, pode ser dividido em dois componentes: compilação e linking.

Compilação se refere ao processamento do código-fonte e a criação de arquivos “objeto”, que são unidades compiladas individuais. É no processo de compilação que também ocorre a análise sintática e léxica do código. Nesse ponto, se algo não estiver em conformidade com as pecificações do CLS ou CTS (que vimos no artigo anterior), o processo é interrompido e um manipulador de erros integrado ao compilador envia uma notificação apontando o local do erro. Cada um desses arquivos objeto contém uma tradução do seu código-fonte em IL e são armazenados no diretório obj – mas você não pode executá-los! Porque ainda é preciso transformá-los em executáveis que seu sistema operacional possa usar. É aí que entra o Linker.

Linking (ou vinculação) refere-se à criação de um único arquivo executável a partir de vários arquivos objeto. Isso significa que todos esses arquivos de código são compilados em uma unidade assembly armazenada em /bin e, que, posteriormente, em tempo de execução, será interpretado pelo compilador JIT, fornecido pelo CLR, da melhor maneira para se comunicar com as APIs do sistema operacional, como estudamos no artigo anterior.

Por isso, esses arquivos de saída são divididos em /obj e /bin, mas também possuem um diretório chamado Debug, pois, esse processo de compilação é feito de forma a facilitar a depuração.

As informações de depuração, que facilitam o debug, são mapeadas naquele arquivo com extensão .pdb. PDB significa Program Database, ele é gerado pelo Linker e consiste em uma estrutura de dados empregada pelo compilador onde cada identificador no código-fonte do programa é conectado com informações sobre sua declaração, seu tipo, nível de escopo e, em alguns casos, a sua posição.

Os estágios de análise e síntese da compilação empregam informações a essa estrutura (também chamada de tabela de símbolos) para verificar se os identificadores usados foram especificados, para validar se as expressões e atribuições são semanticamente precisas e para construir o IL de destino. Em outras palavras, o arquivo .pdb mapeia vários componentes e instruções no código-fonte para que o seu depurador possa usá-lo para localizar o arquivo de origem e o local do executável no qual ele deve interromper um processo de depuração. Sendo assim, seu programa é compilado com informações de depuração junto com os assemblies e sem otimização. Porque a otimização complica a depuração, afinal de contas, a relação entre o código-fonte e as instruções de otimização geradas são bem mais complexas. Essa otimização, portanto, se faz necessária apenas quando queremos distribuir nossa aplicação, um processo chamado release. Mas, estudaremos isso em outro momento.

Com base no que acabamos de saber e no que estudamos no primeiro artigo, podemos fazer um desenho do processo de compilação que pode ser mais ou menos como este:

Entendendo basicamente o processo de compilação e build, podemos entender melhor os namespaces.

Voltar aos tópicos

Namespaces

Você pode ter notado que ao criar o modelo HelloWorld a única linha de código era Console.WriteLine("Hello, World");. Mas o código da nossa implementação tem uma estrutura diferente, com algumas coisas a mais.

Se olharmos apenas a estrutura do programa, em Program.cs, veremos:


namespace HelloWorld;

class Program
{
    public static void Main(string[] args)
    {
        // code
    }
}

Como vimos na seção anterior, um programa C# consiste em uma ou mais unidades de compilação, Certamente, eles dependerão uns dos outros para que o seu programa rode e, além disso, seu programa também dependerá de código de de bibliotecas que possuem suas próprias funcionalidades e que também geram suas próprias unidades de compilação. Como organizar isso e evitar ambiguidade? Como garantir que uma classe ou método não conflite com outra classe ou método que possui o mesmo nome, por exemplo? É por isso que existem os namespaces.

Um namespace é um agrupamento de tipos semanticamente relacionados contidos em um assembly ou, possivelmente, espalhados em vários assemblies relacionados. Por exemplo, o namespace System.IO, que usamos em nosso exemplo, contém tipos relacionados a E/S de arquivo, o namespace System.Console define tipos básicos que lidam com fluxos de E/S e erro padrão para aplicativos de console e assim por diante.

É importante ressaltar que um único assembly pode conter n namespaces, cada um dos quais pode conter n tipos. A principal diferença entre essa abordagem e uma biblioteca de uma linguagem específica, como nodeJs, por exemplo, é que para qualquer uma das linguagem de destino suportada pelo .NET, o tempo de execução usa os mesmos namespaces e os mesmos tipos, como vimos no artigo anterior quando falamos sobre o CTS e BCL. Contudo, para ficar mais claro, vamos ver um Hello World em C# e VB:

//  C#.
using System;

public class MyApp
{
    static void Main()
    {
        Console.WriteLine("Hello C# World");
    }
}

//  VB.
Imports System
Public Module MyApp
  Sub Main()
    Console.WriteLine("Hi VB World")
  End Sub
End Module

Você pode observar que cada idioma está usando a classe Console definida no namespace System. Além das variações sintáticas óbvias, esses códigos são muito parecidos, tanto física quanto logicamente.

Para resumir: A palavra-chave namespace é usada para declarar um escopo que contém um conjunto de códigos que se relacionam semanticamente entre si. Isso mantém a organização lógica do projeto e evita erros de compilação. Usar namespaces é uma boa prática e em C# é intensamente usado para duas coisas principalmente:

Organização das inúmeras classes;
Para controlar o escopo dos nomes de classe e de método em projetos maiores.

Conforme evoluirmos nos exemplos práticos ficará ainda mais claro.

Caminhando para o final do nosso estudo, chegou a vez de olharmos para o arquivo de projeto: aquele com extensão .csproj.

Voltar ao tópicos

Arquivos de projeto e Entry Point

O arquivo csproj também é chamado na documentação de arquivo de projeto MSBuild e está no centro do processo de build e implantação de um software .NET.

O MSBuild, ou Microsoft Build Engine, é o mecanismo que controla como a plataforma de compilação processa e compila um software. Tanto a CLI do .NET quanto a IDE Visual Studio, usam o MSBuild para criar os aplicativos incluindo um arquivo que reflete a natureza do projeto, digamos assim. No caso do C#, o .csproj, mas um projeto do Visual Basic será .vbproj, um projeto de banco de dados, .dbproj.

Trata-se de um documento XML que contém todas as informações e instruções necessárias para construção do projeto, como os requisitos da plataforma, as informações de controle de versão, as configurações do servidor Web ou do servidor de banco de dados e as tarefas que devem ser executadas.

Como desenvolvedores .NET, podemos criar nossos próprios arquivos de projeto msbuild, usando o esquema XML do MSBuild, para impor um controle sofisticado e refinado sobre como nossos projetos são criados e implantados. Contudo, um estudo mais aprofundado sobre isso ficará para um próximo artigo.

O que precisamos compreender é que comando dotnet build usa esse mecanismo para compilar o projeto e dá suporte para compilações paralelas e incrementais. Isso é interessante para estudarmos mais detalhadamente o fluxo de compilação dos nossos projetos conforme eles se tornarem mais complexos.

Em tempo, este conceito inicial é suficiente para entendermos porque é de onde vem o arquivo .csproj. Se você quiser se aprofundar mais, pode acessar os links para os conteúdos usados como referência para esse artigo.

Por fim, mas não menos importante, a dúvida: Como o Runtime sabe por ondecomeçar a executar o programa? A resposta objetiva está no método Main(). Este é o primeiro método invocado quando seu projeto é executado. Ou seja, um programa deve ter apenas um método Main – também chamado de Entry Point do programa. No entanto, é até possível que uma aplicação tenha mais de um, só que antes de executá-lo, será necessário informar o compilador por qual começar.

No próximo artigo vamos começar a praticar começando desenvolver exemplos com C# e .NET 6 e ver muito mais de todos esses conceitos na prática.

Resumo

Este artigo complementou muitos dos conceitos estudados no artigo anterior, como CRL, CTS, BCL. Tivemos o primeiro contato com a CLI do .NET, estudamos a estrutura dos seus comandos. Também analisamos a estrutura de arquivos de um projeto e pudemos compreender, além dos seus significados, como estes arquivos interagem uns com os outros. Entramos em detalhes do fluxo de compilação e também tivemos um primeiro contato com a linguagem C#.

Espero que este resumo te ajude de alguma forma. Não hesite em deixar seu feedback para melhorias ou correções.

Até a próxima.

Referências

Compiler Design Tutorial for Beginners – Complete Guide
Symbol Table in Compiler
What Is a PDB File?
Introduction to the Common Language Runtime (CLR)
A Anatomia de um Arquivo de Projeto
Noções básicas sobre o arquivo de projeto
MSBuild
Main() e argumentos de linha de comando
CLI do .NET
Visão geral da publicação de aplicativos .NET
Livro: "Pro C# 10 With .NET 6
- Understanding the Common Type System - (part I, pág 13)
- Distinguishing Between Assembly, Namespace, and Type - (part I, pág 19)

AGRADECIMENTO:

Marcelo Castelo Branco

Voltar ao topo

Me tornando um desenvolvedor .NET - #0

Tiago Henrique — Thu, 08 Sep 2022 02:13:59 +0000

No começo do mês de Agosto, iniciei meus estudos do ecossistema .NET, o ambiente de desenvolvimento da Microsoft. Este e os próximos artigos representam meus esforços de aprendizado e a vontade de compartilhar conhecimento com quem também está começando.

Este artigo, abrange conceitos que ainda estou compreendendo, portanto, está sujeito a falhas de interpretação ou nomenclatura. Contudo, há um grande esforço de checagem e validação das informações. Caso você encontre erros e/ou algo não tenha ficado claro o suficiente, por favor, não hesite em me procurar para que eu possa melhorar.

Quero ressaltar que os conteúdos que serão publicados não possuem o objetivo de serem tutoriais, mas resumos dos meus estudos. Este disclaimer se faz necessário, pois é possível que eu pule etapas consideradas mais básicas por já ter consolidado o conhecimento ou por não estarem no escopo. Por outro lado, como se trata de algo novo para mim, alguns temas de base serão abordados.

Dito isso, gostaria de pedir, tanto para programadores iniciantes, como eu, quanto para aqueles com mais experiência, que se sintam a vontade par entrar em contato, tirar dúvidas, dar feedback ou contribuir para a melhoria do conteúdo. Só assim poderemos evoluir juntos.

Introdução

Há muito material online sobre a estrutura do ambiente de desenvolvimento da Microsoft. Neste artigo irei abordar o que considero mais relevante para compreensão desse ecossistema raro. Uso a palavra “raro” porque realmente existem poucos frameworks no mercado que oferecem tantas ferramentas integradas para desenvolvimento de software.

Tem me ajudado conhecer a plataforma mais afundo. Seus conceitos e funcionamento trazem um conhecimento rico que me esforço para resumir abordando os seguintes tópicos:

Visão geral
- Histórico do .NET - Importante para sabermos com o que estamos lidando.
- Componentes do ecossistema .NET
- CLR - COMMON LANGUAGE RUNTIME
- CLS - COMMON LANGUAGE SPECIFICATION
- CTS - COMMON TYPE SPECIFICATION
- BCL - BASE CLASS LIBRARY
- Processo de Execução Gerenciado

Visão Geral: Histórico do .NET

Como muitos sabem, .NET Framework foi criado na década de 1990, com o nome de NGWS (Next Generation Windows Services) para desenvolver aplicações da Microsoft. No fim de 2001, as primeiras versões beta do .NET foram lançadas e, em 2002, foi lançada a versão 1.0 trazendo o código gerenciado (veremos o que é isso mais pra frente) para o Windows NT 4.0, 98, 2000, ME, XP.

Um longo caminho foi percorrido e a plataforma teve diversas versões, todas side-by-side (isto é, você pode ter várias versões instaladas trabalhando lado a lado). Até que, em 2014, a Microsoft passou por uma transição profunda no modelo de atuação que influenciou (e influencia até hoje) seus produtos: a saída de Steve Ballmer e a entrada de Satya Nadella como novo CEO da empresa.

Podemos dizer que Satya Nadella entendeu que a cultura monolítica, fechada e extremamente competitiva da Microsoft não era mais a adequada ao mercado cada vez mais volátil, mais focado em serviços e definitivamente integrado com soluções concorrentes. De uma grande caixa-preta, “ame-a ou deixe-a”, a Microsoft passou a vender a imagem de uma empresa que colabora com a comunidade de desenvolvimento, respeita seus adversários e permite que o consumidor misture produtos sem ficar preso ao seu ecossistema.

Obviamente essa reestruturação iria se refletir na plataforma de desenvolvimento que já sofria com características limitadas de desenvolvimento multiplataforma, baixa performance e baixo suporte a arquitetura de microsserviços. Então, todo o esforço futuro do .NET Framework passou a ser endereçado ao projeto que ficou conhecido como .NET Core, um novo framework que seria desenvolvido do zero para dar suporte multiplataforma (Linux, MacOs) com a mesma ideia e recursos do irmão mais velho.

Esse projeto começou em 2015 e até 2019 a empresa tinha 2 Frameworks no mercado, o .NET Framework, que era mais completo, mas rodava apenas em ambientes Windows e o .NET Core, que ainda estava em desenvolvimento, mas tinha suporte a outros sistemas operacionais.
Com o lançamento do .NET Core 3, em 2019, o framework passou a suportar desenvolvimento de aplicações desktop, IA/Machine Learning e apps IoT. Era, então, apenas uma questão de tempo para uma nova grande mudança. E ela veio em 2020.

Após o .NET Core 3.1, que já possuía quase todas as funcionalidades do .NET Framework e suporte multiplataforma, digamos que a Microsoft não viu mais sentido em manter dois frameworks e anunciou o .NET 5. O .NET Framework foi descontinuado (então não, não é uma versão posterior ao .NET Framework 4.x), e o .NET 5 se tornou o único a ser atualizado, justificando a remoção do nome “CORE” da marca. Portanto, o .NET 5 é a “unificação” do .NET Framework com o .NET Core.

Com atualizações anuais, no mês de novembro, e versões pares com suporte LTS, já foram anunciadas as atualizações para .NET 7, esse ano (2022) e .NET 8 LTS (2023).

Para nós, programadores, essa história significa o seguinte: Apesar das versões mais antigas não receberem mais atualizações, apenas correções de segurança e bugs, elas existem e algumas empresas ainda trabalham com código legado. Por isso a importância de saber com qual versão se está trabalhando e suas particularidades. Contudo, não faz o menor sentido iniciar novos projetos com versões anteriores ao .NET 5.
Mas, ao que se dá o sucesso da plataforma de um ponto de vista operacional? Vamos entender melhor a arquitetura e seus componentes.

Componentes .NET

Ok, somos novos no ramo. Talvez nem tudo fique claro logo de cara. Mas imagine comigo: A primeira suposição que fazemos é que um programa é escrito em uma linguagem de programação específica. Logo descobrimos que todos os programas precisam de alguma biblioteca de tempo de execução que lhes permita interagir com os outros recursos da máquina (como entrada do usuário, arquivos de disco, comunicações de rede, etc).

Para isso acontecer, o programa também precisa ser convertido de alguma forma (por interpretação ou compilação) para um formato que o hardware nativo possa executar diretamente.

Então, esse programa direcionado para um formato específico de hardware, agora tem que se integrar com outros programas escritos em outras linguagens que devem interagir, de alguma forma, com os mesmos ou com outros recursos de hardware… Um processador vai fazer o trabalho, mas cada CPU tem sua própria arquitetura.

Bom, é aqui que a imaginação acaba, porque essas dependências são tão numerosas, interdependentes e diversas que os implementadores de linguagens de programação quase sempre direcionam seus esforços a uma arquitetura de hardware específica (por exemplo, X86) e a um ambiente de sistema operacional (por exemplo, Windows, Linux ou Mac OS), que possui uma especificação que descreve o formato do arquivo executável e especifica como ele será carregado. No fim das contas, os programadores não fazem um "executável C++", mas sim um "executável Windows X86" ou um "executável Power PC Mac OS".

Haja abstração. Porém elas existem, ou você não estaria em um computador agora. Na verdade, a grande maioria dessas abstrações razoavelmente completas foi construída para linguagens únicas. Por exemplo, o tempo de execução Java, o interpretador Perl são exemplos.

No começo do artigo, eu mencionei a palavra “raro” para me referir ao ambiente .NET, acho que agora, por contraste, vai ficar mais claro o que quis dizer:

Não precisa de muito esforço para entender que especificar e implementar todos esses detalhes que imaginamos seja uma tarefa enorme. É aqui que entra o COMMON LANGUAGE RUNTIME e o motivo de ser muito raro.

O CLR é a base onde os aplicativos .NET são construídos. É ele que gerencia tudo o que acontece por trás dos panos enquanto programamos. Uma definição seria:

O Common Language Runtime (CLR) é uma máquina virtual completa e de alto nível projetada para suportar uma ampla variedade de linguagens de programação e interoperação entre elas.

Isso pode não ser muito esclarecedor quanto a sua raridade ou seu sucesso, por outro lado é um primeiro passo para agrupar seus recursos de maneira compreensível. É o que vou tentar fazer a seguir.

CLR - COMMON LANGUAGE RUNTIME

Para começar, o CLR não é bem-sucedido devido a qualquer recurso específico que ele suporta – como coleta de lixo, independência de plataforma, programação orientada a objetos ou suporte a versões (coisas que serão abordadas futuramente). O CLR é bem-sucedido porque todos esses recursos, assim como vários outros, se combinam para tornar a programação significativamente mais fácil, permitindo que diferentes linguagens se comuniquem entre si com construções de alto nível que reduzem drasticamente o trabalho de interoperação.

Fácil aqui significa o seguinte:

Linguagens simplificadas (por exemplo, C# e Visual Basic são significativamente mais simples que C++, linguagem geralmente usada na implementação de APIs dos sistemas operacionais)
Uma dedicação à simplicidade na biblioteca de classes (por exemplo, temos apenas um tipo de string e é imutável; isso simplifica muito qualquer API que use strings)
Forte consistência na nomenclatura na biblioteca de classes (por exemplo, exigindo que as APIs usem convenções de nomenclatura consistentes)
Ótimo suporte na cadeia de ferramentas necessária para criar um aplicativo (por exemplo, o Visual Studio torna a criação de aplicativos CLR muito simples e o Intellisense facilita muito a localização dos tipos e métodos corretos para criar o aplicativo).

A partir desse conhecimento, podemos fazer um primeiro desenho dos componentes básicos gerenciados pelo CLR da seguinte forma:

Na primeira camada (de cima para baixo) temos as linguagens de programação cujos compiladores são suportadas pelo runtime. Logo abaixo temos as especificações de tipo e de linguagem.

CTS - COMMON TYPES SPECIFICATION

O CTS descreve um conjunto de tipos de dados que podem ser usados por diferentes linguagens comuns ao .Net (ou seja, na prática, o CTS garante que eu possa escrever uma classe em Python, por exemplo, e derivar dela em C#).

Para comunicação entre programas escritos em qualquer linguagem suportada pelo .NET (mais de 50 linguagens) os tipos têm que ser compatíveis no nível básico, isto é, o sistema deve suportar duas categorias:

Tipos de valor:

Onde os objetos são representados por seus valores. Se você atribuir um tipo de valor a uma variável, estará essencialmente copiando um valor do objeto.

Tipos de referência:

Os tipos de referência são representados por uma referência ao valor real do objeto. Ele simplesmente se refere a um local de memória onde estão os valores dos objetos. Isso tem um impacto profundo em como esses tipos são usados. Se você atribuir um tipo de referência a uma variável e, em seguida, passar essa variável para um método, por exemplo, quaisquer alterações no objeto serão refletidas no objeto principal; não há cópia.

O CTS também define todas as outras propriedades dos tipos, como modificadores de acesso, quais são os membros de tipo válidos, como a herança e a sobrecarga funcionam e assim por diante. Infelizmente, meu conhecimento ainda não vai muito além disso, então falarei mais profundamente em um outro artigo.

CLS - COMMON LANGUAGE SPECIFICATION

O CLS é um subconjunto do CTS. Isso significa que todas as regras do CTS também se aplicam ao CLS, a menos que as regras do CLS sejam mais rígidas. Entretanto, é o CLS que fornece uma espécie de receita semântica para qualquer linguagem que seja implementada. Em outras palavras, o CLS define uma série de regras semânticas que são compartilhadas entre as linguagens com o objetivo de garantir interoperabilidade completa entre elas.

Frameworks de Desenvolvimento

Na próxima camada, temos os frameworks de desenvolvimento .Net. Eu não entrarei no detalhes de todos. Eu tenho me dedicado a entender mais profundamente o ASP.NET. É dele que falarei mais em artigos futuros, no entanto a definição de cada plataforma pode ser:

WinForms – uma estrutura para criação de interface do usuário que cria aplicativos cliente de desktop avançados para Windows. A plataforma de desenvolvimento do Windows Forms oferece suporte a um amplo conjunto de recursos de desenvolvimento de aplicativos, incluindo controles, gráficos e vinculação de dados e entrada do usuário.

ASP.NET – É usado para desenvolver aplicativos baseados na web, desde sites usando HTML, CSS e Javascript até APIs Web, além de facilitar o uso de tecnologias em tempo real como Web Sockets.

ADO.NET – é um conjunto de classes que expõe serviços de acesso a dados para programadores do .NET Framework. O ADO.NET fornece um rico conjunto de componentes para a criação de aplicativos distribuídos de compartilhamento de dados.

BCL - BASE CLASS LIBRARY

Por fim, mas não menos importante, a BCL. Uma coleção de métodos e funções que podem ser usados para o propósito da aplicação. A estrutura .NET fornece um conjunto de bibliotecas de classes básicas com diversos recursos que podem ser usados por qualquer linguagem de programação que implemente .NET.

Por exemplo, existe uma biblioteca de classes com métodos para lidar com todas as operações em nível de arquivo. Portanto, existe um método que pode ser usado para ler o texto de um arquivo. Da mesma forma, existe um método para escrever texto em um arquivo.

A maioria dos métodos é dividida nos namespaces System.* ou Microsoft.*. (o asterisco significa apenas uma referência a todos os métodos que se enquadram no namespace System ou Microsoft).

Um namespace é uma separação lógica de métodos. Veremos mais detalhes sobre namespaces em um próximo estudo.

Processo de Execução Gerenciado

Juntando tudo que vimos: o CLR tem a característica matadora de ser multilingue. Cada linguagem/compilador que é suportado pelo ecossistema e que se beneficie do CLR é chamado de código gerenciado (Porque é gerenciado pelo CLR), do contrário é chamado de código não gerenciado.

O código gerenciado, no caso do .NET, permite que objetos escritos em diferentes linguagens possam se comunicar uns com os outros e seus comportamentos podem ser fortemente integrados. Por exemplo: você pode definir uma classe em C# e usar uma linguagem diferente para derivar dessa classe ou chamar um método definido nela, ou pode passar uma instância de uma classe para um método de uma classe escrita em um idioma diferente.

O CLR é capaz disso por possuir especificações de tipagem e semântica que garantem que, no fim das contas, não compilamos um “código C# ” e sim um código que irá implementar as APIs da arquitetura da SO. Veremos agora como isso é possível:

Cada linguagem suportada pelo CLR possui suas ferramentas, entre elas está o seu compilador. O compilador da linguagem que você usa determina quais recursos de tempo de execução estão disponíveis e você projeta seu código usando esses recursos. Seu compilador, não o tempo de execução, estabelece a sintaxe que seu código deve usar (conforme as especificações de tipo e linguagem).

Quando seu código é compilado, é gerado um arquivo chamado de Assembly. Os assemblies são usados para os próprios programas, bem como para quaisquer bibliotecas dependentes. É um formato de arquivo binário totalmente especificado e padronizado pela ECMA 335. Todos os compiladores de linguagem suportados pelo .NET usam esse formato.

Entretanto, na prática, um assembly é o produto da compilação do seu código escrito em C#, VB, F#, etc. em uma linguagem intermediária chamada de MSIL (Microsoft Intermediate Language). Uma linguagem intermediária independente do CPU, isto é, ainda não é a linguagem de máquina (código nativo ou não gerenciado), mas uma linguagem desenvolvida para se comunicar da melhor maneira com as APIs fornecidas pela arquitetura do sistema operacional.

O MSIL inclui instruções para carregar, armazenar, inicializar e chamar métodos em objetos, bem como instruções para operações aritméticas e lógicas, fluxo de controle, acesso direto à memória, tratamento de exceção e outras operações.

Quando esse binário é executado, ele passa por uma outra compilação, dessa vez, por um dos compiladores JIT (Just-in-Time) que também são fornecidos pelo CLR. Esse tipo de compilador traduz, em tempo de execução, o código intermediário em código nativo específico para aquele CPU.

Ser traduzido em tempo de execução significa o seguinte: O compilador JIT converte o código intermediário em código nativo durante a execução do programa sob-demanda.

Isso, por sua vez, quer dizer que a compilação JIT leva em consideração a possibilidade de que algum código nunca seja chamado durante a execução. Logo, em vez de usar tempo e memória para converter todo o MSIL em código nativo, ele o converte conforme necessário durante a execução e armazena o código nativo resultante na memória para que seja acessível para chamadas subsequentes no contexto desse processo.

Outros processos ocorrem nesse momento, por exemplo, um compilador JIT também otimiza o código a cada execução.. Ou seja, toda vez que o IL é executado, o compilador o torna mais eficaz. É possível que você ouça de um desenvolvedor mais experiente uma expressão do tipo: “Vamos esperar o código esquentar”. Agora você sabe que ele está fazendo referência à otimização do código a cada execução ;)

Também existem diferentes tipos de compilação JIT, no entanto, fogem um pouco do escopo deste artigo e serão abordados com mais detalhes nos próximos que desejo publicar sobre o assunto.

Para concluirmos esse conteúdo introdutório, o CRL, além de gerenciar todos esses componentes, possui muitos outros recursos, por isso é útil categorizá-los da seguinte forma:

Recursos fundamentais – Recursos que têm amplo impacto no design de outros recursos. Esses incluem:
1. Coleta de lixo
2. Segurança de memória e segurança de tipo
3. Suporte de alto nível para linguagens de programação.
Recursos secundários – Recursos habilitados pelos recursos fundamentais que podem não ser exigidos:
1. Isolamento de programa com AppDomains
2. Segurança do programa e sandboxing
Outros recursos – recursos que todos os ambientes de tempo de execução precisam, mas que não aproveitam os recursos fundamentais do CLR. Em vez disso, eles são o resultado do desejo de criar um ambiente de programação completo. Entre eles estão:
1. Controle de versão
2. Depuração/Perfil
3. Interoperação

Para os próximos artigos eu irei me aprofundar um pouco mais em alguns desses recursos. Por agora, podemos resumir o Runtime do .NET como uma especificação completa dos bits exatos que se deve colocar em um arquivo para criar e executar um programa. É uma máquina virtual que executa esses arquivos e está em um alto nível de abstração apropriado para implementar uma ampla classe de linguagens de programação. Essa máquina virtual, juntamente com um corpo cada vez maior de bibliotecas de classes, é o que define o COMMON LANGUAGE RUNTIME.

FONTES:

AGRADECIMENTO:
Marcelo Castelo Branco, Engenheiro de Software Sênior na XP.inc. primeiro pela paciência, depois pela didática: sempre trazendo exemplos das minhas experiências passadas para essa nova empreitada. E por se dispor a me mentorear e se comprometer com minha evolução! Valeu, cara!

Estude e pesquise melhor com essas extensões

Tiago Henrique — Mon, 23 May 2022 01:41:26 +0000

Uma das coisas mais importantes - talvez a mais importante - na vida de uma pessoa é saber aprender. Se você está no início da carreira de pessoa desenvolvedora de software, como eu, imagino que já deve ter percebido que aprender é algo que você nunca mais vai parar de fazer. Imagino também que isso não deve ser problema para você. Talvez o problema esteja em torno da busca pelo melhor método (se é que existe), das prioridades, do tempo e, muito provavelmente, das melhores ferramentas. Estamos no mesmo barco.

Eu venho do jornalismo e, guardadas as proporções, uma das coisas que aprendi é que é extremamente difícil lidar com quantidades grandes de informação sem método e sem ajuda. Parece óbvio, mas o fato é que, de vez em quando, esquecemos disso. Então resolvi começar esse blog: para compartilhar com a comunidade um pouco das minhas experiências com o estudo e gerenciamento da informação expondo meu aprendizado na área de tecnologia buscando feedbacks construtivos.

Para chutar essa bola para frente, esse post traz uma lista de extensões interessantes para Google Chrome que uso no meu dia-a-dia no curso. Algumas eu conheci recentemente e outras eu já conhecia desde que trabalhava apurando e escrevendo histórias.

Eu não vou entrar no detalhe de todas, você pode acessar a página de cada uma delas, testar e tirar suas conclusões.

Talvez você conheça algumas (ou todas!), mas se souber de outras que possa compartilhar, todos e todas irão agradecer!

DEV Community: Tiago Henrique

Me tornando um desenvolvedor .NET #1

Introdução

Tópicos

Visão Geral da CLI

Estrutura de comando

Estudando um aplicativo de console

Fluxo de compilação

Namespaces

Arquivos de projeto e Entry Point

Resumo

Referências

Me tornando um desenvolvedor .NET - #0

Introdução

Visão Geral: Histórico do .NET

Componentes .NET

CLR - COMMON LANGUAGE RUNTIME

CTS - COMMON TYPES SPECIFICATION

CLS - COMMON LANGUAGE SPECIFICATION

Frameworks de Desenvolvimento

BCL - BASE CLASS LIBRARY

Processo de Execução Gerenciado

Estude e pesquise melhor com essas extensões

1. Volume Master

2. BlackBox (essa surpreende!)

3. YouTube Speed Control

4. OneTab

5. GoFullPage

6. Mendeley Web Importer