DEV Community: Bea Tavernaro

NuGet and what's behind your dependencies

Bea Tavernaro — Thu, 15 Oct 2026 20:21:39 +0000

🇧🇷 Prefere ler em português? Leia aqui.

Over the last three days of my 30 Days of .NET, we saw what happens when we run dotnet run, explored the structure of a .NET project, and learned how to use the CLI without relying on Visual Studio.

But there's something that shows up in pretty much every real-world project and that we tend to handle on autopilot: NuGet packages.

When we need some functionality, we look for a library that solves our problem, install the package, and keep developing. I've done this countless times myself without thinking too much about what was happening behind that installation, especially when the package is well-known and used by thousands of other developers. By the way, be careful with that.

The thing is, installing a package doesn't necessarily mean adding just one library to our project. Sometimes we're bringing in several other dependencies along with it, and we don't always know what they are or where they came from.

So today, we're going to take a closer look at how NuGet works, where these dependencies come from, and how we can check whether the packages we're using are up to date and secure.

What is NuGet?

NuGet is the package manager for the .NET ecosystem. It allows developers to distribute, share, and reuse libraries across different projects, making dependency management easier. If you've worked with JavaScript or Python, you can think of it as the equivalent of npm or pip. These packages can be made available through different sources, with NuGet.org being the most well-known public repository.

If we open the Dapper page on NuGet.org, for example, we can find information about the package, its available versions, the frameworks it's compatible with, its dependencies, and links to its repository and documentation. It's worth taking a look at this information before installing a library, especially to check whether it meets our project's needs and to better understand what we're adding.

On Day 02, we saw that we can add Dapper to our project using the terminal. After installation, the package appears in our .csproj through a PackageReference, which tells .NET which dependency we're using and which version was declared for the project.

So far, it seems pretty simple, but there's an important part of this process that isn't always visible when we only look at the .csproj.

Dependencies That Bring Other Dependencies

When we install a NuGet package, we might be adding much more than the library we chose. A package can also depend on other packages to work properly, and those packages can have their own dependencies, and so on.

This is where we need to understand the difference between direct and transitive dependencies.

A direct dependency is one that we explicitly add to our project, like we did with Dapper. A transitive dependency, on the other hand, is one that becomes part of the project because another package needs it to work.

We can view these dependencies using the command:

dotnet package list --include-transitive

The result shows the top-level packages, which are the direct dependencies, and the transitive packages used by the project. Depending on the libraries installed, this list can be huge.

And why does this matter so much?

Because when we add a dependency to our project, we're also trusting, to some extent, the packages it depends on. This doesn't mean transitive dependencies are bad. After all, they're a normal part of how package managers work, but we need to understand that they're also part of our application.

An example of how this can become a problem happened in March 2026, involving Axios, a package widely used to make HTTP requests in JavaScript applications.

In this case, an attacker managed to publish compromised versions of Axios on npm. These versions included a new dependency called plain-crypto-js, which contained malicious code. So anyone installing one of the affected versions could end up bringing in and executing that code without ever choosing to install the malicious package directly.

The incident was documented by the Google Threat Intelligence Group and is an example of a software supply chain attack.

Although it happened in the npm ecosystem, this example helps us understand a risk that also exists in NuGet and other package managers.

It's not enough to know just the library we're installing. We also need to consider the dependencies that come along with it.

`dotnet restore` — Where Do Packages Come From?

Now that we know a package can depend on several others, another question comes up: how does .NET find all these dependencies and get our project running? We can use the dotnet restore command.

dotnet restore

When we run this command, .NET analyzes the dependencies declared in the project, resolves which versions need to be used, and checks the configured package sources to find what's needed.

NuGet also uses a global packages cache, which is usually stored in the .nuget/packages folder inside the user's directory. This means that if a package version has already been downloaded, it can be reused by other projects without needing to download it again.

That's why we don't need to commit all the libraries used by our application to Git. When someone else clones our repository, .NET can read the declared dependencies and restore the required packages, as long as it has access to the sources where they're available.

How Can We Tell if Our Dependencies Are Up to Date and Secure?

Installing a library and never looking at it again might seem harmless, especially when everything keeps working, but the packages we use also receive updates, bug fixes, and security vulnerability fixes.

Using the .NET CLI, we can identify packages that need these updates without having to visit each package's NuGet page. The dotnet package list --outdated command shows which packages have newer versions available:

This command compares the packages used by the project with the versions available from the configured sources and shows which ones can be updated.

But there's an important difference between a package being outdated and a package being vulnerable.

Not every older version has a security issue, and not every update needs to be applied immediately, since some updates can introduce changes that are incompatible with our code.

dotnet package list --vulnerable --include-transitive

The command above checks vulnerability information available from audit sources and shows the affected packages, allowing us to identify issues that need attention.

And this is where it's worth remembering the Axios case we saw earlier. These checks are important, but they don't mean we're completely protected against every malicious package. They depend on vulnerabilities that have already been identified and recorded, so a recently compromised package might not show up in any of these checks yet.

That's why keeping our dependencies secure doesn't simply mean updating everything to the latest version or running a command every once in a while.

We need to evaluate which libraries we're using, keep track of important updates, and understand the impact these dependencies can have on our application.

Wrapping Up

In the rush of development, it's very easy to install a package to solve a problem and never think about it again. If the library works, the project builds, and the feature is done, we usually move on to the next task without paying much attention to what was added.

But today we saw that there's quite a lot happening behind a simple installation. NuGet needs to resolve dependencies, find the required packages, restore their files, and make sure everything is available for the build process. And as Uncle Ben would say, "With great power comes great responsibility." That convenience of having ready-made code comes with the responsibility of keeping track of the libraries we use.

We don't need to be suspicious of every package we install, but understanding where our dependencies come from and how we can check their status is already an important step toward keeping our projects safer and easier to maintain.

Oh, and it's worth checking out the NuGet statistics page!

See you tomorrow!

References

NuGet e o que existe por trás das dependências

Bea Tavernaro — Thu, 15 Oct 2026 20:18:16 +0000

🇺🇸 Prefer reading in English? Read the English version here.

Nos últimos três dias dos meus 30 dias de .NET, vimos o que acontece quando executamos um dotnet run, exploramos a estrutura de um projeto .NET e aprendemos a utilizar a CLI sem depender do Visual Studio.

Mas tem uma coisa que aparece em praticamente qualquer projeto real e que costuma ir no automático: os pacotes NuGet.

Quando precisamos de alguma funcionalidade, procuramos uma biblioteca que resolva nosso problema, instalamos o pacote e seguimos desenvolvendo. Eu mesma já fiz isso inúmeras vezes sem pensar muito no que estava acontecendo por trás daquela instalação, principalmente quando o pacote é conhecido e utilizado por milhares de outros desenvolvedores. Aliás, cuidado com isso.

Só que instalar um pacote não significa necessariamente adicionar uma única biblioteca ao nosso projeto. Às vezes, estamos trazendo várias outras dependências junto com ele, e nem sempre sabemos quais são ou de onde vieram.

Então, hoje vamos entender melhor como funciona o NuGet, de onde vêm essas dependências e como podemos verificar se os pacotes que utilizamos estão atualizados e seguros.

O que é o NuGet?

O NuGet é o gerenciador de pacotes do ecossistema .NET. Ele permite que desenvolvedores distribuam, compartilhem e reutilizem bibliotecas em diferentes projetos, facilitando o gerenciamento de dependências. Se você já trabalhou com JavaScript ou Python, pode pensar nele como o equivalente ao npm ou ao pip. Esses pacotes podem ser disponibilizados em diferentes fontes, sendo o NuGet.org o repositório público mais conhecido.

Se abrirmos a página do Dapper no NuGet.org, por exemplo, podemos encontrar informações sobre o pacote, suas versões disponíveis, os frameworks com os quais é compatível, suas dependências e os links para o repositório e a documentação. É interessante dar uma olhada nessas informações antes de instalar uma biblioteca, principalmente para verificar se ela atende às necessidades do nosso projeto e conhecer melhor o que estamos adicionando.

No Dia 02, vimos que podemos adicionar o Dapper ao nosso projeto utilizando o terminal. Depois da instalação, o pacote aparece no nosso .csproj através de um PackageReference, que informa ao .NET qual dependência estamos utilizando e qual versão foi declarada para o projeto.

Até aqui parece bastante simples, mas tem uma parte importante desse processo que nem sempre fica visível quando olhamos apenas para o .csproj.

Dependências que trazem outras dependências

Quando instalamos um pacote NuGet, podemos estar adicionando muito mais do que aquela biblioteca que escolhemos. Um pacote também pode depender de outros pacotes para funcionar corretamente, e esses outros pacotes podem ter suas próprias dependências e assim por diante.

É aqui que precisamos entender a diferença entre dependências diretas e transitivas.

Uma dependência direta é aquela que adicionamos explicitamente ao nosso projeto, como fizemos com o Dapper. Já uma dependência transitiva é aquela que chega ao projeto porque outro pacote precisa dela para funcionar.

Podemos visualizar essas dependências utilizando o comando:

dotnet package list --include-transitive

O resultado apresenta os pacotes de nível superior (top-level), que são as dependências diretas, e os pacotes transitivos utilizados pelo projeto. Dependendo das bibliotecas instaladas, essa lista pode ser enorme.

E por que isso importa tanto?

Porque, quando adicionamos uma dependência ao nosso projeto, também estamos confiando, em certa medida, nos pacotes dos quais ela depende. Isso não significa que dependências transitivas sejam ruins, afinal, elas fazem parte do funcionamento normal dos gerenciadores de pacotes, mas precisamos entender que elas também fazem parte da nossa aplicação.

Um exemplo de como isso pode se tornar um problema aconteceu em março de 2026, envolvendo o pacote Axios, bastante utilizado para realizar requisições HTTP em aplicações JavaScript.

Nesse caso, um invasor conseguiu publicar versões comprometidas do Axios no npm. Essas versões incluíam uma nova dependência chamada plain-crypto-js, que continha código malicioso. Assim, quem instalasse uma das versões afetadas poderia acabar trazendo e executando esse código sem ter escolhido instalar diretamente o pacote malicioso.

O caso foi documentado pelo Google Threat Intelligence Group e é um exemplo de ataque à cadeia de suprimentos de software, também conhecido como supply chain attack.

Apesar de ter acontecido no ecossistema npm, o exemplo ajuda a entender um risco que também existe no NuGet e em outros gerenciadores de pacotes.

Não basta conhecer apenas a biblioteca que instalamos, precisamos considerar também as dependências que vêm junto com ela.

`dotnet restore` — de onde vêm os pacotes?

Sabendo agora que um pacote pode depender de vários outros, surge outra questão: como o .NET encontra todas essas dependências e consegue fazer nosso projeto funcionar? Podemos utilizar o comando dotnet restore .

dotnet restore

Quando executamos esse comando, o .NET analisa as dependências declaradas no projeto, resolve quais versões precisam ser utilizadas e verifica as fontes de pacotes configuradas para encontrar o que for necessário.

O NuGet também utiliza um cache global de pacotes, que normalmente fica armazenado na pasta .nuget/packages do diretório do usuário. Isso significa que, se uma versão de um pacote já foi baixada anteriormente, ela pode ser reutilizada por outros projetos sem precisar ser baixada novamente.

É por isso que não precisamos enviar todas as bibliotecas utilizadas pela aplicação para o Git. Quando outra pessoa clona nosso repositório, o .NET consegue ler as dependências declaradas e restaurar os pacotes necessários, desde que tenha acesso às fontes onde eles estão disponíveis.

Como saber se nossas dependências estão atualizadas e seguras?

Instalar uma biblioteca e nunca mais olhar para ela pode parecer inofensivo, principalmente quando tudo continua funcionando, mas os pacotes que utilizamos também recebem atualizações, correções de bugs e correções de vulnerabilidades de segurança.

Através da .NET CLI, conseguimos identificar os pacotes que precisam dessas atualizações sem precisar acessar a página NuGet de cada um. O comando dotnet package list --outdated mostra quais pacotes possuem versões mais recentes disponíveis:

Esse comando compara os pacotes utilizados pelo projeto com as versões disponíveis nas fontes configuradas e apresenta aqueles que podem ser atualizados.

Mas existe uma diferença importante entre um pacote estar desatualizado e um pacote estar vulnerável.

Nem toda versão antiga apresenta um problema de segurança e nem toda atualização precisa ser aplicada imediatamente, já que algumas podem introduzir mudanças incompatíveis com o nosso código.

dotnet package list --vulnerable --include-transitive

O comando acima consulta informações de vulnerabilidades disponíveis nas fontes de auditoria e apresenta os pacotes afetados, permitindo que identifiquemos problemas que precisam de atenção.

E aqui vale lembrar do caso do Axios que vimos anteriormente. Essas verificações são importantes, mas não significam que estamos completamente protegidos contra qualquer pacote malicioso. Elas dependem de vulnerabilidades que já foram identificadas e registradas, então um pacote recém-comprometido pode ainda não aparecer em nenhuma dessas consultas.

Por isso, manter nossas dependências seguras não significa simplesmente atualizar tudo para a versão mais recente ou executar um comando de vez em quando.
Precisamos avaliar quais bibliotecas estamos utilizando, acompanhar atualizações importantes e entender o impacto que essas dependências podem ter na aplicação.

Concluindo

Na correria do desenvolvimento, é muito fácil instalar um pacote para resolver algum problema e nunca mais pensar nele. Se a biblioteca funciona, o projeto compila e a funcionalidade está pronta, normalmente seguimos para a próxima task sem olhar muito para o que foi adicionado.

Mas hoje vimos que existe bastante coisa acontecendo por trás de uma simples instalação. O NuGet precisa resolver dependências, encontrar os pacotes necessários, restaurar seus arquivos e garantir que tudo esteja disponível para o processo de build. E, como já diria o Tio Ben: "Com grandes poderes vêm grandes responsabilidades". Essa facilidade de contar com código pronto vem com a responsabilidade de acompanhar as bibliotecas que utilizamos.

Não precisamos desconfiar de cada pacote que instalamos, mas entender de onde vêm nossas dependências e como podemos verificar sua situação já é um passo importante para manter nossos projetos mais seguros e fáceis de manter.

Ah, vale a pena dar uma olhada na página de estatísticas do NuGet!

Até amanhã!

Referências

A Day Without Visual Studio, Using Only the .NET CLI

Bea Tavernaro — Thu, 15 Oct 2026 13:02:03 +0000

🇧🇷 Prefer reading in Portuguese? Read the Brazilian Portuguese version.

Today, Visual Studio is staying closed.

On Day 01 of my 30 Days of .NET challenge, we explored what happens behind a dotnet run and got to know the .NET CLI. On Day 02, we opened up a .NET project to better understand Program.cs, .csproj, bin, obj, and some of the configurations that make our project work.

So today I decided to put those two things together and take on a little challenge that reminded me of the days before AI: create, build, run, test, and publish a .NET application using only the terminal.

No play button, no right-clicking the Solution, no Build menu, and no Visual Studio doing things for me.

Just me, the terminal, and the .NET CLI. Just like Neo from The Matrix.

Before we start, what can we create?

On Day 01, we learned that the .NET CLI (Command-Line Interface) is a tool that allows us to interact with .NET through written commands and that it comes with the .NET SDK.

One of the first commands we encountered was dotnet new. But before creating anything, we can find out which templates are available on our machine using the dotnet new list command.

The result shows a HUGE list of templates we can use to create different types of .NET projects and files. Among them, we can find Console applications, Class Libraries, test projects, web applications, and many others. We'll explore the differences between them in the not-too-distant future.

So when we type dotnet new console, console isn't just some random word the CLI understands. It's the short name of a template that's installed and available to dotnet new.

For our challenge, we're going to create a Console application called Dia03 using the familiar command dotnet new console -n Dia03.

The -n option is short for --name and defines the name of what we're creating. After running the command, we can navigate into the folder. And that's it, our project was created without opening an IDE.

`dotnet build` — let's see if this compiles

Now we have code, but we need to transform it into something .NET can execute. That's where our dotnet build from Day 01 comes in.

When we execute this command, .NET uses MSBuild to build the project and its dependencies. The C# code goes through the compilation process we saw on Day 01, and the resulting files start appearing in that bin and obj structure we explored on Day 02.

By default, the build uses the Debug configuration, so we can find our files in a structure similar to this:

But we can also choose another configuration by using Release: dotnet build -c Release.

The -c option is short for --configuration, and in this case, we're requesting a build using the Release configuration.

In simple terms, Debug is the configuration designed for application development and debugging, while Release is the configuration used when we want a build optimized for distribution. Look how it adds folders to obj and bin.

So dotnet build isn't running our application. It's building our project and checking whether the code can be successfully compiled. If there's a lovely compilation error somewhere along the way, it'll let us know.

`dotnet run` — we already know this one

After three days of talking about .NET, dotnet run is practically becoming part of the family and joining us for Sunday lunch.

This command runs our application and, when necessary, performs the build process beforehand. If you want to know more about this build process, you can also read Day 01.

`dotnet test` — now let's make QA happy

We have an application that we can create, build, and run, but we're still missing something important: ~~90% test coverage~~ tests.

If we try to explore dotnet test in our Console project, we don't have any tests to execute. So let's use the CLI itself to create a test project.

Going back to the folder where our Dia03 project is located, we can execute dotnet new xunit -n Dia03.Tests to create this project. I won't go into the details of this command today.

Now we have two projects:

The xunit template creates a test project using xUnit, a testing framework for .NET. It provides the tools and conventions we use to write automated tests in C#, especially unit tests.

Since we want our tests to be able to access the project we're testing, we add a reference between them:

dotnet reference add ../Dia03/Dia03.csproj --project Dia03.Tests

The reference is registered in the test project's .csproj through a ProjectReference, very similar to what we saw yesterday when we added a NuGet package.

Now we can run our tests and see the result.

The command builds the necessary projects and executes the tests found in the test project. At the end, we get the results directly in the terminal, showing how many tests passed, failed, or were skipped.

I'm not going to dive into xUnit and test structure right now because that deserves its own day. What's important here is that we managed to create the test project and run it without opening Visual Studio's Test Explorer.

`dotnet publish` — we're done, now we need to deliver

So far, we've created our project, built it, run it, and executed the tests. Now we need to prepare our application to leave our machine using dotnet publish.

One question I've had before is: if dotnet build already compiled my application, why does dotnet publish exist? Both commands do go through the build process, but they serve different purposes.

dotnet build focuses on building the project, generating the binaries needed for development and code validation. On the other hand, dotnet publish prepares the application and its dependencies so it can be deployed to another environment.

We can publish our application in Release using the command dotnet publish -c Release and see a folder similar to this:

The publish folder contains the files that are part of our application's published output. So a simple way to think about it is that build answers something like "Can I build this project?", while publish answers "Which files do I need to prepare to distribute this application?"

It sounds like a lot ~~and it is~~, but the CLI itself can help us when we're desperate.

Don't memorize everything, ask the CLI itself

So far, we've used several command options that look like random letters: -n, -c. And the list gets much longer as we start exploring the CLI. Eventually, we end up typing things without even knowing why. That's not what we're aiming for anymore, right? The good news is that we don't need to memorize all these commands and options.

We can ask for help directly in the terminal using dotnet --help or, even better, ask for help with a specific command:

dotnet new --help
dotnet build --help
dotnet run --help
dotnet test --help
dotnet publish --help

This shows the command's description, its arguments, and the available options. For me, knowing that an option exists and knowing where to find it is much more useful than trying to memorize fifty parameters I might use twice a year.

From zero to publish without Visual Studio

We started the day without opening Visual Studio and went through practically the entire basic lifecycle of our application using only the .NET CLI. That doesn't mean I'm going to uninstall Visual Studio tomorrow and start developing everything through CMD (God forbid). The IDE exists precisely to make our lives easier and automate many of these tasks. Thank you, Microsoft.

But there's a huge difference between letting a tool do something for us and not knowing what it's doing for us. We could spend hours philosophizing about this and the use of AI, but let's save that conversation for a coffee.

When we click Build, run tests through Test Explorer, or publish an application using the Visual Studio interface, there are .NET tools and commands working behind all those conveniences. Knowing the CLI helps us better understand this process and also makes a big difference when we leave our own machines and encounter environments where there isn't a pretty button to click, such as CI/CD pipelines, containers, and servers.

Visual Studio got some rest today, but it can open again tomorrow.

References

.NET CLI overview — Microsoft Learn and its command-specific subpages

What does the .csproj file tell you about your .NET project?

Bea Tavernaro — Thu, 15 Oct 2026 12:54:43 +0000

🇧🇷 Prefer reading in Portuguese? Read the Brazilian Portuguese version.

On the first day of 30 Days of .NET, I explored what happens behind a simple dotnet run.

But before dotnet run, there's the project itself.

When we create a .NET application, even the simplest one possible, some files and folders automatically appear. Program.cs, .csproj, obj, then bin, and we just keep coding without worrying about understanding them.

I've opened a .csproj file several times myself to install a package, change a configuration, or check the .NET version, and then closed it without really understanding what I had done.

So today I decided to open up this little box and understand what each of these things is for.

Creating the simplest project possible

Let's start by creating a Console application:

The dotnet new command creates projects and other files from templates. In this case, we're using the console template and naming the project Dia02.

Inside the folder, we have a structure similar to this:

Not much to get started, but we already have quite a few things to understand here.

`Program.cs` — where it all begins

Opening the Program.cs file of a modern Console application, we find something like this:

Console.WriteLine("Hello, World!");

The Program.cs file is where we find the application's entry point. It's where our program starts executing and, in larger applications, it's usually where we configure and initialize the necessary components before the application actually starts doing its work.

If you've seen older C# projects, you might be missing a few things in Program.cs.

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

Since C# 9, we've had top-level statements, which allow us to write the application's entry point code without explicitly declaring a Program class and a Main method, as in the second example. The compiler generates the necessary entry point for us, making Program.cs much less verbose and cleaner.

`.csproj` — the file that describes our project

Now we've reached the most important file in this article.

If we open Dia02.csproj, we'll find something like this:

The .csproj file contains various pieces of information that tell the build system how the project should be handled: which SDK to use, which framework it targets, package references, references to other projects, and several compilation settings. Oh, and it's an XML file.

Looking at our example:

<Project Sdk="Microsoft.NET.Sdk"> : defines the Project SDK used by the project. In this case, we're using the base .NET SDK. In an ASP.NET Core application, for example, it's common to find Microsoft.NET.Sdk.Web.

<PropertyGroup> : groups project properties and settings. It doesn't define a specific configuration on its own, but works as a "group" for the properties inside it.

<OutputType>Exe</OutputType> : defines the type of output generated by the project. Exe indicates that we're building an executable application.

<TargetFramework>net10.0</TargetFramework> : defines which Target Framework the project will be built for. In this example, our target is .NET 10. This doesn't mean "which SDK I have installed", but rather which framework the application targets.

<ImplicitUsings>enable</ImplicitUsings> : makes the SDK automatically add some common using directives to the project. That's why we can use things like Console.WriteLine() without necessarily writing using System; at the beginning of the file.

<Nullable>enable</Nullable> : enables the Nullable Reference Types context, allowing the compiler to warn us about situations where a reference might be null. For example, it starts distinguishing between string name and string? name.

And what happens when we install a NuGet package?

Now let's make a few changes to our project.

We can add a package using the CLI:

dotnet package add Dapper

After that, if we open our .csproj again, something new has appeared:

Let's understand what's new:

<ItemGroup> : while PropertyGroup groups properties and settings, ItemGroup groups items that are part of or used by the project, such as packages, references to other projects, and files.

<PackageReference Include="Dapper" Version="..." /> : declares a dependency on a NuGet package. Include="Dapper" specifies which package we want to use, and Version="..." specifies which version of that package the project uses.

When we install a NuGet package, the dependency is registered in the .csproj file itself, along with the version used by the project. That's also why we don't need to commit the packages themselves to Git. When someone else clones the project, .NET can read the PackageReference entries and restore the necessary dependencies.

And where did `bin` and `obj` come from?

When we execute dotnet build

.NET starts the build process for our project, and during this process, two folders that probably every .NET developer has encountered are created or updated: bin and obj.

Although both are related to the build process, they serve different purposes.

The bin folder contains the main files resulting from our application's compilation. Inside it, .NET organizes these files according to the build configuration and the project's Target Framework.

The obj folder, on the other hand, works as a workspace for the build process. While the output we're interested in goes to bin, during compilation, .NET and MSBuild need to generate and store several intermediate files. That's where obj comes in.

Normally, neither folder is versioned in Git. If we delete bin and obj and run dotnet build again, .NET regenerates whatever is needed.

Wrapping up

With tight deadlines, it's very easy to simply create a project, install packages, run dotnet build, and move on without thinking too much about what's happening behind the scenes. And most of the time, it really will work. But understanding how the project is structured and where .NET gets the information it needs to build our application makes a big difference when something stops working as expected ~~which is almost all the time~~. The more we understand the tools we use every day, the easier it becomes to investigate errors and, consequently, the easier and faster it becomes to complete a task.

See you tomorrow!

References

What Really Happens When You Run `dotnet run`?

Bea Tavernaro — Thu, 15 Oct 2026 12:44:41 +0000

🇧🇷 Prefer reading in Portuguese? Read the Brazilian Portuguese version.

If you work with .NET, you've probably typed this command countless times:

dotnet run

And a few seconds later, your application is running. Simple as that.

But what actually happened between pressing Enter and your application starting to run?

Who found the project? Who compiled the C# code? What gets generated during compilation? Can the processor execute C# directly? And where do the SDK, Runtime, and CLR fit into all of this?

Trying to answer these questions is exactly why I chose this topic for the first day of my 30 Days of .NET challenge.

So let's follow the journey of a dotnet run, from the terminal all the way to application execution.

You type `dotnet run` in the terminal

The first piece we encounter is the .NET CLI (Command-Line Interface).

But what exactly is a CLI?

A CLI is an interface that allows us to interact with a program through written commands. So no, the CLI isn't exactly that "black screen" we call the terminal. The terminal is the program we use to type commands, while the .NET CLI is the tool that receives and interprets commands like dotnet run.

On Windows, for example, we can use the .NET CLI through PowerShell, Command Prompt, or Windows Terminal. On Linux and macOS, we can use it through their respective terminals.

When we install the .NET SDK, we get access to the dotnet command, which serves as the entry point for several tools in the platform:

dotnet new       # creates a new project from a template
dotnet restore   # restores project dependencies
dotnet build     # builds the project
dotnet test      # runs tests
dotnet run       # builds and runs the application
dotnet publish   # prepares the application for distribution

When we execute dotnet run, we're basically saying: find my project, prepare it for execution, and run it.

But the CLI didn't magically appear on our machine. It came along with another important piece: the .NET SDK.

The SDK - Software Development Kit

The SDK brings together the tools we developers need to build our .NET applications. Think of it as a toolbox with a hammer and a screwdriver, except the SDK comes with the CLI, build tools, compilers, libraries, and other components needed to build our applications.

Because of all these tools, when we're developing an application, we need to make sure the SDK is installed. We can check which SDKs are installed using:

dotnet --list-sdks

So, when we execute dotnet run, we're using the tools provided by the SDK to prepare our application.

Our C# code needs to be compiled, right?

Our processor has absolutely no idea what to do with a random line like this:

Console.WriteLine("Help, I don't understand");

After writing our C# code and before executing it, it needs to go through a compilation process.

In simple terms, compiling means transforming the code we write into a representation that can move on to the next stages of execution. In C#, the compiler transforms our code into IL (Intermediate Language) and includes metadata about our code.

IL is an intermediate language. In other words, at this point, we're still not speaking the "machine language" that the processor can execute.

This is where we start moving away from the SDK's territory and into the actual execution process of our application.

.NET Runtime

The .NET Runtime is the set of components required to execute a .NET application after it has been compiled.

It includes components such as the CLR, fundamental .NET libraries, and other files needed to run an application.

That's why the SDK and Runtime have different purposes. If we're developing an application, we need the tools provided by the SDK. But if we only want to run an application, depending on how it was published, we might only need the Runtime.

We can check which runtimes are installed on our machine using:

dotnet --list-runtimes

When our application starts executing, the Runtime provides the environment needed for the IL we generated earlier to finally run.

And one of the most important pieces of this process is the CLR.

CLR - Common Language Runtime

The CLR (Common Language Runtime) is the environment responsible for executing managed .NET code.

But it doesn't just "run the code". During execution, the CLR takes care of several other things for us. When we create objects in our code, for example, we need memory to store them. The CLR participates in memory management, and the Garbage Collector identifies objects that are no longer being used so their memory can be reclaimed.

It also provides other services that we constantly use without having to implement everything manually, such as:

memory management;
exception handling;
thread management;
type safety.

During traditional execution, another important component comes into play: the JIT — Just-In-Time compiler.

It transforms IL (the Intermediate Language we talked about earlier) into machine code that the processor can actually execute.

And here's something really important about .NET: it's cross-platform!

The IL generated during compilation is an intermediate representation and isn't directly tied to the instructions of a specific CPU. When the application runs, the Runtime for that platform handles execution, and the JIT generates machine code appropriate for the processor's architecture.

The same .NET code can run on Windows, Linux, and macOS, as long as .NET supports that operating system and architecture.

Putting it all together

Now we can see the entire journey:

All of this started with a single two-word command, probably one of the most frequently used:

dotnet run

So what's the difference between SDK, CLI, Runtime, and CLR?

After following the command's journey, these definitions become much less abstract. Here's a quick summary to keep in your memory (yours, not your computer's).

Term	In a tweet
SDK	A set of tools we use to develop .NET applications.
CLI	A command-line interface that gives us access to various .NET tools.
Runtime	A set of components required to execute a .NET application.
CLR	The execution environment for managed code.
IL	The intermediate language generated when C# code is compiled.
JIT	A compiler that transforms IL into machine code.

So instead of memorizing four separate definitions, we can think of them as pieces that come into play at different stages of our application's lifecycle.

And the next time I type dotnet run, I'll know just how much is happening behind that simple command.

References

Um dia sem Visual Studio usando só a .NET CLI

Bea Tavernaro — Sat, 03 Oct 2026 21:02:46 +0000

🇺🇸 Prefer reading in English? Read the English version here.

Hoje o Visual Studio não vai abrir.

No Dia 01 dos meus 30 dias de .NET nós vimos o que acontece por trás de um dotnet run e conhecemos a .NET CLI. No Dia 02 abrimos a caixinha de um projeto .NET para entender melhor o Program.cs, .csproj, bin, obj e algumas das configurações que fazem nosso projeto funcionar.

Então hoje resolvi juntar as duas coisas e fazer um pequeno desafio que me lembrou dos tempos sem IA: criar, compilar, executar, testar e publicar uma aplicação .NET usando somente o terminal.

Sem botão de play, sem clicar com o botão direito na Solution, sem menu de Build e sem Visual Studio fazendo as coisas por mim.

Só eu, o terminal e a .NET CLI. Tal qual NEO do Matrix.

Antes de começar, o que podemos criar?

No Dia 01 vimos que a .NET CLI (Command-Line Interface) é uma ferramenta que permite interagir com o .NET através de comandos escritos e que ela vem junto com o .NET SDK.

Um dos primeiros comandos que encontramos foi dotnet new. Mas, antes de criar qualquer coisa, podemos descobrir quais templates estão disponíveis na nossa máquina usando o comando dotnet new list

O resultado mostra uma lista ENORME de templates que podemos utilizar para criar diferentes tipos de projetos e arquivos .NET. Entre eles encontramos aplicações Console, Class Libraries, projetos de testes, aplicações web e vários outros. A diferença entre cada um vêm num futuro não muito distante.

Então quando escrevemos dotnet new console o console não é só uma palavra aleatória que a CLI entende. Ele é o short name de um template que está instalado e disponível para o dotnet new.

Para o nosso desafio vamos criar uma aplicação Console chamada Dia03 usando o comando conhecido dotnet new console -n Dia03

A opção -n é a forma curta de --name e define o nome do que estamos criando. Depois do comando, podemos entrar na pasta. E pronto, nosso projeto foi criado sem abrir nenhuma IDE.

`dotnet build` — vamos ver se isso compila

Agora temos código, mas precisamos transformá-lo em algo que o .NET consiga executar. É aí que entra o nosso dotnet build do Dia 01.

Quando executamos esse comando, o .NET usa o MSBuild para construir o projeto e suas dependências. O código C# passa pelo processo de compilação que vimos no Dia 01 e os arquivos resultantes começam a aparecer naquela estrutura de bin e obj que vimos no Dia 02.

Por padrão, o build utiliza a configuração Debug, então podemos encontrar nossos arquivos em uma estrutura parecida com:

Mas também podemos escolher outra configuração com o uso do Release: dotnet build -c Release

O -c é a forma curta de --configuration e, nesse caso, estamos pedindo um build utilizando a configuração Release.

De forma simplificada, Debug é a configuração pensada para o desenvolvimento e depuração da aplicação, enquanto Release é a configuração utilizada quando queremos um build otimizado para distribuição. Olha como adiciona pastas ao obj e bin

Então o dotnet build não está executando nossa aplicação. Ele está construindo nosso projeto e verificando se aquele código consegue ser compilado com sucesso. Se tiver um belo erro de compilação no meio do caminho, ele vai nos contar.

`dotnet run` — esse aqui a gente já conhece

Depois de três dias falando sobre .NET, o dotnet run já está quase virando membro da família e almoçando no domingo com a gente

Esse comando executa nossa aplicação e, quando necessário, realiza o processo de build antes disso. Se quiser saber mais sobre esse processo de build você pode ler o Dia 01 também.

`dotnet test` — agora vamos deixar o QA feliz

Temos uma aplicação que cria, compila e executa, mas ainda falta uma coisa importante: ~~90% de cobertura de~~ testes.

Se tentarmos explorar o dotnet test no nosso projeto Console, não temos nenhum teste para executar. Então vamos aproveitar a própria CLI para criar um projeto de testes.

Voltando para a pasta onde está nosso projeto Dia03, podemos executar dotnet new xunit -n Dia03.Tests pra criar esse projeto. Não vou entrar nos detalhes desse comando hoje.

Agora temos dois projetos:

O template xunit cria um projeto de testes utilizando xUnit um framework de testes para o .NET. Ele nos da as ferramentas e convenções que usamos para escrever testes automatizados em C#, principalmente testes unitários.

Como queremos que nossos testes consigam acessar o projeto que estamos testando, adicionamos uma referência entre eles:

dotnet reference add ../Dia03/Dia03.csproj --project Dia03.Tests

A referência fica registrada no .csproj do projeto de testes através de um ProjectReference, bem parecido com o que vimos ontem quando adicionamos um pacote NuGet.

Agora podemos executar nossos testes e ver o resultado

O comando faz o build dos projetos necessários e executa os testes encontrados no projeto de testes. No final recebemos o resultado diretamente no terminal, mostrando quantos testes passaram, falharam ou foram ignorados.

Não vou entrar em xUnit e estrutura de testes agora porque isso merece um dia próprio. O importante aqui é que conseguimos criar o projeto de testes e executá-lo sem precisar abrir o Test Explorer do Visual Studio.

`dotnet publish` — terminou, agora precisamos entregar

Até agora criamos nosso projeto, compilamos, executamos e rodamos os testes. Falta preparar nossa aplicação para sair da nossa máquina com o dotnet publish

Uma dúvida que eu já tive é: se dotnet build já compilou minha aplicação, para que existe o dotnet publish? Os dois realmente passam pelo processo de build, mas têm objetivos diferentes.

O dotnet build está focado em construir o projeto, gerando os binários necessários para desenvolvimento e validação do código. Já o dotnet publish prepara a aplicação e suas dependências para que ela possa ser implantada em outro ambiente.

Podemos publicar nossa aplicação em Release com o comando dotnet publish -c Release e ver uma pasta parecida com essa

Dentro de publish ficam os arquivos que fazem parte da saída publicada da nossa aplicação. Então uma forma simples de pensar é que o build responde algo próximo de " eu consigo construir esse projeto?", enquanto o publish responde "quais arquivos eu preciso preparar para distribuir essa aplicação?"

Parece bastante coisa ~~e é~~ mas a própria CLI pode ajudar a gente nas horas do desespero

Não decore tudo, pergunte para a própria CLI

Até agora usamos várias opções nos comandos que viram letrinhas soltas -n, -c. E a lista fica muito maior conforme começamos a explorar a CLI, no final a gente tá digitando sem nem saber o porquê. Não é mais nosso intuito certo? A boa notícia é que não precisamos decorar todos esses comandos e opções.

Podemos pedir ajuda diretamente no terminal com o dotnet --help ou, melhor ainda, pedir ajuda para um comando específico:

dotnet new --help
dotnet build --help
dotnet run --help
dotnet test --help
dotnet publish --help

Isso mostra a descrição do comando, seus argumentos e as opções disponíveis. Para mim, saber que uma opção existe e saber onde encontrá-la é muito mais útil do que tentar decorar cinquenta parâmetros que eu talvez use duas vezes no ano.

Do zero ao publish sem Visual Studio

Começamos o dia sem abrir o Visual Studio e passamos por praticamente todo o ciclo básico da nossa aplicação usando apenas a .NET CLI. Isso não significa que amanhã vou desinstalar o Visual Studio e começar a desenvolver tudo pelo CMD (Deus me dibre). A IDE existe justamente para facilitar nossa vida e automatizar várias dessas tarefas. Obrigada Microsoft.

Mas existe uma diferença enorme entre deixar uma ferramenta fazer alguma coisa por nós e não saber o que ela está fazendo por nós. Dá pra ficar horas filosofando sobre isso e o uso da IA mas, vamos deixar esse papo pra um café.

Quando clicamos em Build, executamos os testes pelo Test Explorer ou publicamos uma aplicação pela interface do Visual Studio, existem ferramentas e comandos do .NET trabalhando por trás dessas facilidades. Conhecer a CLI ajuda a entender melhor esse processo e também faz bastante diferença quando saímos da nossa máquina e encontramos ambientes onde não existe um botão bonitinho para clicar, como pipelines de CI/CD, containers e servidores.

O Visual Studio descansou hoje mas pode abrir de novo amanhã.

Referências

.NET CLI overview — Microsoft Learn e as subpáginas com os comandos

O que o .csproj conta sobre o seu projeto .NET

Bea Tavernaro — Sat, 03 Oct 2026 00:35:13 +0000

🇺🇸 Prefer reading in English? Read the English version.

No primeiro dia dos 30 dias de .NET eu fui entender o que acontece por trás de um simples dotnet run.

Mas antes do dotnet run existe o projeto em si.

Quando criamos uma aplicação .NET, mesmo a mais simples possível, alguns arquivos e pastas já aparecem automaticamente. Program.cs, .csproj, obj, depois bin e a gente simplesmente segue programando sem se preocupar em entender.

Eu mesma já abri um .csproj várias vezes para instalar um pacote, mudar alguma configuração ou conferir a versão do .NET e depois fechei sem entender direito o que tinha feito.

Então hoje resolvi abrir essa caixinha e entender para que serve cada uma dessas coisas.

Criando o projeto mais simples possível

Vamos começar criando uma aplicação Console:

O dotnet new cria projetos e outros arquivos a partir de templates. Nesse caso estamos usando o template console e dando ao projeto o nome Dia02.

Entrando na pasta temos uma estrutura parecida com essa:

Pouca coisa pra começar, mas já temos bastante coisa para entender aqui.

`Program.cs` — onde tudo começa

Abrindo o Program.cs de uma aplicação Console moderna encontramos algo parecido com:

Console.WriteLine("Hello, World!");

O Program.cs é o arquivo onde encontramos o ponto de entrada da aplicação. É onde a execução do nosso programa começa e, em aplicações maiores, normalmente é onde configuramos e inicializamos os componentes necessários antes da aplicação começar a trabalhar de fato.

Se você já viu projetos C# mais antigos, talvez esteja sentindo falta de algumas coisas no Program.cs

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

Desde o C# 9 temos os Top-level statements, que permitem escrever o código do ponto de entrada da aplicação sem declarar explicitamente uma classe Program e um método Main, como no segundo exemplo. O compilador gera o ponto de entrada necessário para nós, deixando o Program.cs bem menos verboso e mais bonito.

`.csproj` — o arquivo que descreve nosso projeto

Agora chegamos no arquivo mais importante do artigo.

Se abrirmos o Dia02.csproj, vamos encontrar algo parecido com:

É no .csproj que ficam várias informações que dizem ao sistema de build como aquele projeto deve ser tratado: qual SDK utilizar, qual framework ele tem como alvo, referências a pacotes, referências a outros projetos e diversas configurações de compilação. Aah, e é um arquivo XML.

Olhando para o nosso exemplo:

<Project Sdk="Microsoft.NET.Sdk"> : define o Project SDK utilizado pelo projeto. Nesse caso estamos usando o SDK base do .NET. Em uma aplicação ASP.NET Core, por exemplo, é comum encontrarmos Microsoft.NET.Sdk.Web.

<PropertyGroup> : agrupa propriedades e configurações do projeto. Ele não define uma configuração específica sozinho, mas funciona como um "grupo" para as propriedades que estão dentro dele.

<OutputType>Exe</OutputType> : define o tipo de saída que será gerada pelo projeto. Exe indica que estamos construindo uma aplicação executável.

<TargetFramework>net10.0</TargetFramework> : define para qual Target Framework o projeto será construído. No exemplo, nosso alvo é o .NET 10. Isso não quer dizer "qual SDK tenho instalado", mas sim qual framework essa aplicação tem como alvo.

<ImplicitUsings>enable</ImplicitUsings> : faz com que o SDK adicione automaticamente alguns using comuns ao projeto. É por isso que conseguimos usar coisas como Console.WriteLine() sem necessariamente escrever using System; no começo do arquivo.

<Nullable>enable</Nullable> : habilita o contexto de Nullable Reference Types, permitindo que o compilador nos avise sobre situações em que uma referência pode ser null. Por exemplo, ele passa a diferenciar string nome de string? nome.

E quando instalamos um pacote NuGet?

Agora vamos mexer um pouquinho no nosso projeto.

Podemos adicionar um pacote usando a CLI:

dotnet package add Dapper

Depois disso, se abrirmos novamente nosso .csproj, alguma coisa nova apareceu:

Vamos entender o que apareceu de novo:

<ItemGroup> : enquanto o PropertyGroup agrupa propriedades e configurações, o ItemGroup agrupa itens que fazem parte ou são utilizados pelo projeto, como pacotes, referências a outros projetos e arquivos.

<PackageReference Include="Dapper" Version="..." /> : declara uma dependência de um pacote NuGet. O Include="Dapper" informa qual pacote queremos utilizar e o Version="..." informa qual versão desse pacote o projeto utiliza.

Ao instalar um pacote NuGet, a dependência fica registrada no próprio .csproj, junto com a versão que o projeto utiliza. É também por isso que não precisamos enviar os pacotes junto com nosso código para o Git. Quando outra pessoa clona o projeto, o .NET consegue ler os PackageReference e restaurar as dependências necessárias.

E de onde surgiram `bin` e `obj`?

Quando executamos o dotnet build

o .NET inicia o processo de build do nosso projeto e, no meio disso, duas pastas que provavelmente todo desenvolvedor .NET já encontrou são atualizadas ou aparecem: bin e obj.

Apesar de as duas estarem relacionadas ao processo de build, elas têm funções diferentes.

A pasta bin é onde ficam os principais arquivos resultantes da compilação da nossa aplicação. Dentro dela, o .NET organiza esses arquivos de acordo com a configuração utilizada no build e o Target Framework do projeto.

Já a pasta obj funciona como uma área de trabalho do processo de build. Enquanto o resultado que nos interessa vai para bin, durante a compilação o .NET e o MSBuild precisam gerar e armazenar diversos arquivos intermediários. É na obj que essas informações ficam.

Normalmente, nenhuma das duas é versionada no Git. Se apagarmos bin e obj e executarmos novamente o dotnet build, o .NET gera de novo o que for necessário.

Concluindo

Na correria das entregas é muito fácil simplesmente criar o projeto, instalar os pacotes, rodar um dotnet build e seguir a vida sem pensar muito no que está acontecendo por trás de tudo isso. E, na maior parte do tempo, vai funcionar mesmo. Mas entender como o projeto está estruturado e de onde o .NET tira as informações que precisa para construir nossa aplicação faz bastante diferença quando alguma coisa deixa de funcionar como esperado ~~quase o tempo todo~~. Quanto mais entendemos as ferramentas que usamos todos os dias, mais fácil fica investigar um erro e, por consequência, mais fácil e rápido fica entregar a task.

Até amanhã!

Referências

O que realmente acontece quando você digita dotnet run?

Bea Tavernaro — Thu, 01 Oct 2026 21:29:41 +0000

🇺🇸 Prefer reading in English? Read the English version here.

Se você trabalha com .NET, provavelmente já digitou esse comando muitas e muitas vezes:

dotnet run

E alguns segundos depois sua aplicação está rodando. Simples assim.

Mas o que realmente aconteceu entre você apertar Enter e a sua aplicação começar a executar?

Quem encontrou o projeto? Quem compilou o código C#? O que é gerado durante essa compilação? O processador consegue executar C# diretamente? Onde entram o SDK, o Runtime e o CLR nessa história?

Foi justamente tentando responder essa pergunta que escolhi o tema do primeiro dia dos meus 30 dias de .NET.

Então vamos seguir o caminho de um dotnet run, do terminal até a execução da aplicação.

Você digita `dotnet run` no terminal

A primeira peça que encontramos é o .NET CLI (Command-Line Interface).

Mas o que é um CLI?

A CLI é uma interface que permite interagir com um programa através de comandos escritos. Então não, a CLI não é exatamente a "tela preta" do terminal. O terminal é o programa que usamos para digitar os comandos, enquanto a .NET CLI é a ferramenta que recebe e interpreta comandos como o dotnet run.

No Windows, por exemplo, podemos usar a .NET CLI através do PowerShell, Prompt de Comando ou Windows Terminal. No Linux e macOS, podemos utilizá-la através dos seus respectivos terminais.

Quando instalamos o .NET SDK, temos acesso ao comando dotnet, que funciona como o ponto de entrada para várias ferramentas da plataforma:

dotnet new       # cria um novo projeto a partir de um template
dotnet restore   # restaura as dependências do projeto
dotnet build     # compila o projeto
dotnet test      # executa os testes
dotnet run       # compila e executa a aplicação
dotnet publish   # prepara a aplicação para ser distribuída

Quando executamos dotnet run estamos basicamente dizendo: encontre meu projeto, prepare-o para execução e execute-o.

Mas a CLI não apareceu magicamente na nossa máquina. Ela veio junto com outra peça importante: o .NET SDK.

O SDK - Software Development Kit

O SDK reúne as ferramentas necessárias para nós, desenvolvedores, conseguirmos criar nossas aplicações .NET. Quase como uma caixinha de ferramentas que tem martelo e chave de fenda, o SDK tem a CLI, ferramentas de build, compiladores, bibliotecas e outros componentes necessários para essa construção.

Por conta desse conjunto todo, quando vamos desenvolver uma aplicação precisamos verificar se o SDK está instalado. Podemos descobrir quais estão instalados usando o comando:

dotnet --list-sdks

Então, quando executamos o dotnet run, estamos utilizando as ferramentas fornecidas pelo SDK para preparar nossa aplicação.

O código C# precisa ser compilado, certo?

Nosso processador não entende absolutamente nada da frase solta:

Console.WriteLine("Help, não entendo");

Depois de escrito e antes de ser executado, o nosso código C# precisa passar por um processo de compilação, ou seja, ser compilado.

Compilar significa, de forma simplificada, transformar o código que escrevemos em uma representação que possa seguir para as próximas etapas de execução. No caso do C#, o compilador transforma nosso código em IL (Intermediate Language) e adiciona junto metadados sobre o nosso código.

O IL é uma linguagem intermediária. Ou seja, nesse momento ainda não estamos falando a "lingua das máquinas" que será executada pelo processador.

É nessa parte que começamos a sair do território do SDK e entrar no processo de execução da aplicação de fato.

.NET Runtime

O .NET Runtime é o conjunto de componentes necessários para executar uma aplicação .NET depois que ela foi compilada.

Ele inclui componentes como o CLR, bibliotecas fundamentais do .NET e outros arquivos necessários para que uma aplicação consiga rodar.

É por isso que SDK e Runtime têm funções diferentes. Se estamos desenvolvendo, precisamos das ferramentas do SDK. Mas, para apenas executar uma aplicação, dependendo da forma como ela foi publicada, podemos precisar somente do Runtime.

Podemos verificar quais runtimes estão instalados na máquina com:

dotnet --list-runtimes

Quando nossa aplicação começa a ser executada, o Runtime fornece o ambiente necessário para que aquela IL que geramos anteriormente possa finalmente rodar.

E uma das peças mais importantes desse processo é o CLR.

CLR - Common Language Runtime

O CLR (Common Language Runtime) é o ambiente responsável pela execução do código gerenciado do .NET.

Mas ele não simplesmente "roda o código". Durante a execução, o CLR cuida de várias coisas a mais para nós. Quando criamos objetos no nosso código, por exemplo, precisamos de memória para armazenar todos eles. O CLR participa do gerenciamento dessa memória e o Garbage Collector identifica objetos que não estão mais sendo utilizados para liberar espaço.

Ele também fornece outros serviços que usamos constantemente sem precisar implementar tudo manualmente, como:

gerenciamento de memória;
tratamento de exceções;
gerenciamento de threads;
segurança de tipos.

Durante a execução tradicional, entra também o JIT — Just-In-Time compiler.

Ele transforma o IL (Intermediate Language que vimos ali em cima) em código de máquina que o processador daquela máquina consegue executar.

E aqui tem uma coisa muito importante do .NET: o fato dele ser Multiplataforma

O IL gerado na compilação é intermediário e não está diretamente preso às instruções de uma CPU específica. Quando a aplicação é executada, o Runtime apropriado para aquela plataforma participa da execução e o JIT gera código de máquina adequado à arquitetura do processador. O mesmo código .NET pode rodar em Windows, Linux e macOS desde que exista suporte do .NET para aquele sistema operacional e arquitetura.

Juntando tudo

Agora conseguimos enxergar o caminho inteiro:

Tudo isso começou com um único comando de duas palavras, talvez o mais utilizado:

dotnet run

Então qual é a diferença entre SDK, CLI, Runtime e CLR?

Depois de acompanhar o caminho do comando, as definições ficam bem menos abstratas. Segue um resuminho pra guardar na memória (a sua, não do computador)

Termo	Em um tweet
SDK	Conjunto de ferramentas que usamos para desenvolver aplicações .NET.
CLI	Interface de linha de comando através da qual acessamos várias ferramentas do .NET.
Runtime	Conjunto de componentes necessários para executar uma aplicação .NET.
CLR	Ambiente de execução do código gerenciado.
IL	Linguagem intermediária gerada a partir da compilação do código C#.
JIT	Compilador que transforma o IL em código de máquina.

Então, em vez de decorar quatro definições separadas, podemos pensar nelas como peças que participam de momentos diferentes da vida da nossa aplicação.

E da próxima vez que eu digitar dotnet run, vou saber o tanto de coisa que está acontecendo por trás daquele comando.

Referências

Student Benefit Programs in Tech

Bea Tavernaro — Tue, 03 Mar 2026 18:28:36 +0000

The beginning of the year always brings a new wave of students entering college, and there’s no better time to talk about the countless benefits available to students — especially those in technology.

I had written a Twitter thread about this last year, but I decided to organize everything here to make it easier to find and share.

What are these benefits?

They are initiatives that offer free access, credits, or discounts on professional tools, cloud services, and learning platforms. The main goal is to reduce the barrier to entry for students, allowing them to use real-world technologies without having to bear high costs.

For the companies that provide them, the long-term strategy is to develop future professionals who are already familiar with their solutions, encourage continued adoption in the job market, influence technical decisions in the organizations where these students will work, and strengthen their ecosystem with skilled developers — creating a mutually beneficial relationship.

How to get access?

To access most of these benefits, you need to prove enrollment in an educational institution. Platforms usually require a valid academic email address, typically provided by the university, with an institutional domain (such as @institution.edu or similar).

During registration, the company sends a verification request to that email address, and the student must confirm it to validate access. In some cases, proof of enrollment may also be required.

To verify your information and obtain access to your student email, you need to contact your university, as each institution has its own process for creating, activating, and recovering this type of account.

Here’s a tip

You can build an entire portfolio at virtually no cost using these benefits. Some project ideas that can leverage everything you’ll find here include:

Metrics and analytics dashboard – A web application with dynamic charts, filters, authentication, and API consumption simulating a real market product.

REST API structured with Clean Architecture – A complete backend with authentication, versioning, unit tests, Swagger documentation, and cloud deployment.

Mini microservices architecture – Separation of services (users, orders, fake payments) with communication between them and independent deployment.

Public data dashboard with simple ETL – Collecting data from a public API, processing it with Python, and displaying it in an interactive web dashboard.

Documented redesign of a legacy system – A case study including research, persona definition, wireframes, and a navigable prototype in Figma.

And of course, deploying your own personal portfolio on a custom domain!

Now let’s get to what really matters. Here is the list. The GitHub Student Developer Pack appears first because it’s the main gateway to several other benefits and partnerships. The others are organized alphabetically for easier reference.

GitHub Student Developer Pack

Link: GitHub Student Developer Pack – GitHub Education

The largest hub of benefits for student developers. With it, you can earn your first certification for free.

GH-900: GitHub Foundations Certification
GitHub Copilot
Visual Studio
Cloud service credits
Free domain
Database and hosting tools
Course and learning platforms

AWS Educate

Link: AWS Educate

Entry-level AWS cloud program focused on education.

US$75–100 in promotional credits
Courses, hands-on labs, and cloud learning materials
Cloud Career Pathways (guided learning tracks)
Access to the AWS Educate Job Board with cloud-related career opportunities

Azure for Students

Link: Azure for Students | Microsoft Azure

One of the most powerful benefits available. You get access to all Azure resources and can use some for free or spend the $100 in credits you receive upon signing up.

$100 in credits valid for up to 1 year
Free monthly amounts of 20+ popular services for 12 months
All Azure resources, including Azure AI Foundry with the latest AI models

Canva

Link: Canva Education Solutions

Complete visual creation suite.

Premium resources unlocked (templates, images, videos, audio, graphic elements)
Creation of presentations, videos, documents, websites, whiteboards, and visual materials
LMS integrations (Google Classroom, Microsoft Teams, Moodle, Blackboard, Canvas, Schoology, D2L)
Ready-made Teacher Work Kits
Exclusive educator community
Program for educational content creators

Cursor

Link: Cursor · Students

1 free year of the Pro plan for the AI-powered code editor

DataCamp

Link: DataCamp Premium Student Plan

Platform focused on data, Python, and AI.

3 months free
Discount after the free period

DataDog

Link: Free Datadog accounts for students | Datadog

Monitoring and observability tool.

Data storage for 15 months
Team collaboration
Technical support from the DataDog team

.tech Domain

Link: .TECH domains | GitHub Student Developer Pack

Free .tech domain for 1 year

Figma for Education

Link: Figma for Education | Free Tools for the Classroom

Professional design and prototyping tool available to students.

Full Figma for design and prototyping
FigJam included for brainstorming and collaboration
Dev Mode for layout inspection and code generation
Access to the Community with ready-made templates and resources

GitKraken Student Plan

Link: GitKraken’s Git Tools Free For Students | GitKraken

Visual tools for Git and version control.

6 months free
Discount while maintaining a valid student email

Google Cloud for Students

Link: Google Cloud for Students

200 credits on Google Skills Boost
Free hands-on labs

Heroku for Students

Link: Heroku for Students

Monthly credit for application deployment and hosting
US$13/month for 24 months

JetBrains Student Pack

Link: JetBrains Student Pack

One of my favorites. Having access to the most widely used IDEs helps a lot with learning.

Free access to all JetBrains professional IDEs while you are a student, including IntelliJ IDEA, PyCharm, WebStorm, CLion, Rider, DataGrip, and others
40% discount for up to 2 years after graduation

MongoDB

Link: MongoDB Student Pack

Free MongoDB certification
$50 in MongoDB Atlas credits
Learning paths

Notion for Education

Link: Notion for Students

Complete workspace for personal and academic organization.

Free Plus plan for students (individual workspace)
Unlimited pages and blocks
File uploads
More customization and website publishing options
30-day version history

Postman Student Expert

Link: Student Expert | Postman Student Program

Access to exclusive API certifications
Participation in the student API developer community
Student-focused events and workshops
Opportunity to become a Postman Student Leader

Spotify Student

Link: Spotify Student Premium

Okay, this one isn’t exactly tech-related, but we can say it’s for listening to podcasts while working.

Premium plan for R$ 12.90 per month

Conclusion

You can finish the year with at least two certifications, a complete portfolio, and a lot of practical, real-world technology knowledge. These benefits can definitely help you stay one step ahead in an increasingly competitive market.

If you enjoyed it and clicked on at least one link, don’t forget to share it in your university group, with your professors and coordinators. Let’s make tech a more inclusive environment for everyone.

Programas de Benefícios para Estudantes de Tecnologia

Bea Tavernaro — Tue, 03 Mar 2026 17:48:50 +0000

Começo de ano sempre traz uma nova leva de alunos entrando na faculdade e não existe momento melhor pra falar dos inúmeros benefícios disponíveis para estudantes, principalmente os de tecnologia.
Já tinha feito uma thread no Twitter sobre isso no ano passado, mas resolvi organizar tudo aqui pra ficar mais fácil de consultar e compartilhar.

O que são esses benefícios?

São iniciativas que oferecem acesso gratuito, créditos ou descontos em ferramentas profissionais, serviços em nuvem e plataformas de aprendizado. A ideia principal é reduzir a barreira de entrada de quem está se formando, permitindo que estudantes utilizem tecnologias reais sem arcar com custos elevados.

Para as empresas que os concedem, a estratégia de longo prazo é formar futuros profissionais já familiarizados com suas soluções, incentivar a adoção contínua no mercado de trabalho, influenciar decisões técnicas nas organizações onde esses estudantes atuarão e fortalecer seu ecossistema com desenvolvedores capacitados, criando uma relação de benefício mútuo.

Como ter acesso?

Para acessar a maioria desses benefícios, é necessário comprovar vínculo com uma instituição de ensino. Normalmente, as plataformas exigem um e-mail acadêmico válido, geralmente fornecido pela própria universidade, com domínio institucional (como @instituicao.edu.br ou similar).

Durante o cadastro, a empresa envia uma solicitação de verificação para esse endereço, e o estudante precisa confirmar o e-mail para validar o acesso. Em alguns casos, também pode ser solicitado o envio de um comprovante de matrícula.

Para verificar seus dados e obter acesso ao e-mail estudantil, é necessário entrar em contato com a sua faculdade, pois cada instituição possui um processo próprio para criação, liberação e recuperação desse tipo de conta.

Já fica a dica

Dá pra montar um portfólio inteiro praticamente sem custo usando esses benefícios. Alguma ideias que podem usar tudo o que você encontrar aqui são:

Dashboard de métricas e analytics – Aplicação web com gráficos dinâmicos, filtros, autenticação e consumo de API simulando um produto real de mercado.
API REST estruturada com Clean Architecture – Backend completo com autenticação, versionamento, testes unitários, documentação Swagger e deploy em cloud.
Mini arquitetura de microserviços – Separação de serviços (usuários, pedidos, pagamentos fake) com comunicação entre eles e deploy independente.
Dashboard de dados públicos com ETL simples – Coleta de dados de API pública, tratamento com Python e visualização interativa em um painel web.
Redesign documentado de sistema legado – Estudo de caso com pesquisa, definição de personas, wireframes e protótipo navegável no Figma.
E é claro, fazer o deploy do seu próprio portfolio pessoal num dominio próprio!

Vamos ao que interessa então. Aqui está a lista, o GitHub Student Developer Pack aparece em primeiro lugar por ser a principal porta de entrada para diversos outros benefícios e parcerias. Os demais estão organizados em ordem alfabética para facilitar a consulta.

GitHub Student Developer Pack

Link: GitHub Student Developer Pack - GitHub Education

O maior hub de benefícios para devs estudantes. Com ele você pode ter gratuitamente sua primeira certificação.

Certificação GH-900: GitHub Foundations Certification
Github Copilot
Visual Studio
Créditos para serviços em nuvem
Domínio gratuito
Ferramentas de banco de dados e hospedagem
Plataformas de cursos e aprendizado

AWS Educate

Link: AWS Educate

Programa de entrada para cloud AWS com foco educacional.

US$75–100 em créditos promocionais
Cursos, laboratórios práticos e material sobre cloud
Cloud Career Pathways (trilhas de aprendizado guiadas)
Acesso ao AWS Educate Job Board, com vagas e oportunidades de carreira relacionadas à computação em nuvem

Azure For Students

Link: Azure for Students | Microsoft Azure

Esse é um dos benefícios mais poderosos também. Você tem acesso a todos os recursos do azure e pode utilizar alguns deles gratuitamente ou gastar os $ 100 em créditos que ganha ao se inscrever.

$ 100 em créditos para utilizar por até 1 ano
Free monthly amounts of 20+ popular services for 12 months
TODOS os recursos do azure incluindo Azure AI Foundry com os modelos mais recentes de IA

Canva

Link: Canva Education Solutions

Suite completa de criação visual.

Recursos premium liberados (templates, imagens, vídeos, áudios e elementos gráficos)
Criação de apresentações, vídeos, documentos, sites, quadros brancos e materiais visuais
Integração com LMS (Google Classroom, Microsoft Teams, Moodle, Blackboard, Canvas, Schoology, D2L)
Kits de ensino prontos (Teacher Work Kits)
Comunidade exclusiva para educadores
Programa para criadores de conteúdo educacional

Cursor

Link: Cursor · Students

1 ano gratuito do plano Pro para o editor de código com IA integrado

DataCamp

Link: DataCamp Premium Student Plan

Plataforma focada em dados, Python e IA.

3 meses gratuitos
Desconto após o período

DataDog

Link: Free Datadog accounts for students | Datadog

Ferramenta de monitoramento e observabilidade.

Armazenamento de dados por 15 meses
Colaboração em equipe
Suporte técnico da equipe DataDog

Domínio .tech

Link: .TECH domains | GitHub Student Developer Pack

Domínio .tech gratuito por 1 ano

Figma for Education

Link: Figma for Education | Free Tools for the Classroom

Ferramenta profissional de design e prototipação liberada para estudantes.

Figma completo para design e prototipação
FigJam incluso para brainstorm e colaboração
Dev Mode para inspeção de layouts e geração de código
Acesso à Community com templates e recursos prontos

GitKraken Student Plan

Link: GitKraken’s Git Tools Free For Students | GitKraken

Ferramentas visuais para Git e versionamento.

6 meses gratuitos
Desconto enquanto mantiver e-mail de estudante válido

Google Cloud Para Alunos

Link: Google Could For Students

200 créditos no Google Skills Boost
Laboratórios práticos gratuitos

Heroku for Students

Link: Heroku For Students

Crédito mensal para deploy e hospedagem de aplicações.
US$13/mês por 24 meses

JetBrains Student Pack

Link: JetBrains Student Pack

Um dos meus preferidos também. Ter acesso as IDEs mais utilizadas ajuda muito a aprendizagem.

Acesso gratuito a todas as IDEs profissionais da JetBrains enquanto for estudante. Inclui IntelliJ IDEA, PyCharm, WebStorm, CLion, Rider, DataGrip e outros.
40% de desconto por até 2 anos após a graduação

MongoDB

Link: MongoDB Student Pack

Certificação MongoDB Gratuita
$50 em créditos no MongoDB Atlas
Trilhas de aprendizado

Notion for Education

Link: Notion for Students

Workspace completo para organização pessoal e acadêmica.

Plano Plus gratuito para estudantes (workspace individual)
Páginas e blocos ilimitados
Upload de arquivos
Mais opções de personalização e publicação de sites
Histórico de versões por 30 dias

Postman Student Expert

Link: Student Expert | Postman Student Program

Acesso a certificações exclusivas de API
Participação na comunidade estudantil de desenvolvedores de API
Eventos e workshops voltados para estudantes
Oportunidade de se tornar Postman Student Leader

Spotify Universitário

Link: Premium Universitário - Spotify
Tá bom, esse não é lá muito tech, mas a gente pode dizer que usa pra ouvir podcast enquanto trabalha

Plano premium por R$ 12,90 mensais

Conclusão

Dá pra terminar o ano com pelo menos duas certificações, um portfólio completo e muito conhecimento prático e real de tecnologia. Esses benefícios, sem dúvida, podem te ajudar a estar um passo na frente num mercado cada vez mais competitivo.
Se gostou e clicou em pelo menos um link, não deixe de compartilhar no grupo da faculdade, com seus professores e coordenadores. Vamos fazer de tech um ambiente cada vez mais inclusivo para todos.

Como se tornar um Microsoft Learn Student Ambassador

Bea Tavernaro — Mon, 24 Jun 2024 12:28:38 +0000

Desde janeiro de 2024, sou uma Estudante Embaixadora da Microsoft. Adoro títulos baseados em conquistas, e este é um que me orgulha bastante. Escrevi este artigo porque vou dar uma palestra sobre este programa para estudantes no Microsoft Reactor. Eu imaginava que começaria a palestrar bem mais adiante na carreira, mas graças ao programa, me senti encorajada a começar já e, então, surgiu o convite para tal.

Usem este artigo como guia e inspiração para se tornarem parte da comunidade de estudantes empoderados pelas ferramentas da Microsoft.

O que é o programa Microsoft Learn Student Ambassadors?

O Microsoft Learn Student Ambassadors é uma iniciativa global da Microsoft que visa empoderar estudantes universitários apaixonados por tecnologia. O programa oferece uma plataforma para esses estudantes expandirem seus conhecimentos, desenvolverem habilidades técnicas e de liderança, e impactarem positivamente suas comunidades acadêmicas. Os participantes têm a oportunidade de colaborar em projetos, organizar eventos e workshops, e se conectar com profissionais e outros estudantes de todo o mundo.

O que faz um Embaixador da Microsoft?

Nós desempenhamos diversos papéis que ajudam a promover a aprendizagem e a adoção de tecnologias Microsoft em nossas comunidades sejam elas universidades, redes sociais ou no mercado de trabalho. As principais responsabilidades incluem:

Organização de Eventos e Workshops: Embaixadores planejam e conduzem eventos educacionais, como hackathons, workshops, e meetups, para ensinar e compartilhar conhecimentos sobre tecnologias Microsoft, como Azure, Power Platform, GitHub, AI e outras.
Mentoria e Tutoria: Eles atuam como mentores para outros estudantes, oferecendo orientação e suporte em suas jornadas de aprendizado tecnológico. Isso pode incluir ajuda em projetos, tutoriais sobre novas ferramentas, e suporte na preparação para certificações Microsoft.
Desenvolvimento de Conteúdo: Embaixadores criam e compartilham conteúdo técnico, como blogs, tutoriais em vídeo, e artigos, que ajudam a educar e inspirar a comunidade. Esse conteúdo é compartilhado em plataformas como o GitHub, YouTube, e blogs pessoais.
Networking e Colaboração: Participar de comunidades locais e globais, conectando-se com outros embaixadores, profissionais da Microsoft, e membros da comunidade tecnológica. Isso proporciona uma rede valiosa de contatos e oportunidades de colaboração em projetos inovadores.

Como se inscrever?

Até o final de 2023, a inscrição no programa envolvia um processo seletivo que incluía o envio de um vídeo, a resposta a algumas perguntas e, finalmente, a seleção por um time interno da Microsoft. Eu faço parte da última leva de pessoas selecionadas dessa forma.

Porém, a partir de janeiro deste ano, o sistema de inscrição mudou. Agora, ao invés de um modelo baseado em aplicação, adotou-se um modelo baseado em registro, alinhado à missão da Microsoft de empoderar cada pessoa e organização do planeta a atingir mais.

O registro é rápido e fácil e fiz um passo a passo bem organizado para você seguir:

1 - Acesse studentambassadors.com e clique em “Get Started Now”. Lembre-se de que você pode mudar a página para português apenas alterando a URL para pt-br.

2 - Após se registrar, os estudantes são convidados a entrar na comunidade no Discord do Microsoft Learn Student Ambassadors (MLSA).

3 - No Discord, escolha um "program path". Existem três "program paths" alinhados com os interesses de cada estudante:

Influenciadores da Comunidade (Community Influencers): Para pessoas que querem crescer online criando e compartilhando conteúdo da Microsoft.
- Para completar é necessário: Alcançar pelo menos 250 cliques únicos nas páginas da Microsoft usando seu próprio ID.
Construtores de Comunidade (Community Builders): Para aqueles que querem desenvolver habilidades de liderança criando eventos de comunidade para divulgar as ferramentas da Microsoft.
- Para completar é necessário: Alcançar 1000 módulos de Cloud Skills completados usando seu próprio ID. Isso significa que, usando seu ID próprio sua rede precisa completar 1000 modulos no Cloud Skills do Microsoft Learn. Lembre-se que alguns módulos são bem simples e curtos.
Defensores de Startup (Startup Advocates): Para aqueles que querem aumentar seu impacto promovendo soluções em IA e nuvem e a construção de startups.
- Para completar é necessário: Indicar 15 inscrições aceitas para o programa Startups Founders Hub da Microsoft usando seu ID de contribuidor.

4 - Complete o "Technical Onboarding" sobre IA e tecnologias de nuvem da Microsoft. No final desse onboarding você vai ter um projeto incrível para seu portfólio. No meu onboarding desenvolvi meu portfolio pessoal.

5 - Os membros registrados que completarem os requisitos do "program path" e o "Technical Onboarding" serão convidados a se tornarem Estudantes Embaixadores da Microsoft no nível Alpha (explico sobre os níveis já já).

A minha dica maior é: Tenha paciência e trabalhe duro! Se fosse fácil qualquer um seria um embaixador. Eles buscam as pessoas mais engajadas e com muita vontade de serem lideres estudantes.

Níveis e Benefícios

Os estudantes devem completar algumas atividades com o intuito de se desenvolverem e seguirem um caminho mais fácil rumo ao sucesso. Atualmente, existem três níveis: Alpha, Beta e Gold.

Vamos ver cada um deles, o que é necessário para avançar e quais os benefícios de cada etapa.

Alpha: Este é o nível inicial, e ao entrar nele, você conquista:
- Assinatura gratuita do Microsoft 365 (Office)
- Assinatura gratuita do Visual Studio Enterprise
- 150 dólares de créditos mensais no Azure
- LinkedIn Learning
Beta: Para avançar para este nível, é necessário ser host de um evento de tecnologias da Microsoft. Você costuma ver bastante MLSA fazendo esse tipo de evento. Parece complicado mas os que já fizeram estão prontos para te dar diversas dicas. Os benefícios incluem:
- Todos os benefícios do nível Alpha
- A famosa ‘Beta Swag Box’

Gold: Para alcançar este nível, você precisa ser nomeado e ser embaixador por no mínimo um ano e não se formar nos próximos 6 meses. É uma conquista incrível ser Gold. Os escolhidos são anunciados duas vezes no ano em um evento global dos MLSA e se tornam lideres dentro do programa. Os benefícios incluem:
- Gold Swag Box
- Convite para eventos e atividades especiais
- Consideração para ser MVP, com mentorias e nomeação

Onde nos encontrar?

Cada embaixador tem uma página exclusiva dentro do MVP communities onde pode listar os eventos e impactos realizados na comunidade. Você pode encontrar os MLSA do Brasil aqui: Comunidades MVP é só filtrar por país. Somos apenas 38 embaixadores no Brasil. É um número pequeno comparado com outros paises da America Latina.
Instagram: https://www.instagram.com/mlsa.brasil/

Participar do programa Microsoft Learn Student Ambassadors tem sido uma experiência transformadora para mim. Além de expandir meus conhecimentos técnicos, desenvolvi habilidades de liderança e ganhei a confiança para compartilhar meu aprendizado com outros. A oportunidade de palestrar no Microsoft Reactor surgiu justamente por causa desse programa, o que mostra o quanto ele pode abrir portas inesperadas e acelerar o desenvolvimento profissional.

Incentivo todos os estudantes a se inscreverem e se tornarem parte dessa comunidade incrível. Com o suporte e os recursos fornecidos pela Microsoft e pela própria comunidade MLSA, vocês terão a chance de fazer a diferença, não apenas em suas próprias vidas, mas também em suas comunidades. Sigam os passos descritos neste artigo, aproveitem as oportunidades oferecidas, e se tornem agentes de mudança no mundo da tecnologia.

Nota: Este artigo será atualizado após a palestra para incluir insights e histórias de outros MLSA, além dos slides da apresentação.

Tipos de linguagens de programação

Bea Tavernaro — Wed, 20 Mar 2024 16:55:22 +0000

Eu comecei a escrever um artigo que, até então, achava ser simples sobre os Sistemas de Tipos no C#, mas acabei caindo em um buraco negro. Se você não é um estudante avançado de ciência da computação ou um curioso nato, talvez não conheça isso ou não se importe muito. Talvez, inclusive, saber disso não faça diferença no dia a dia, na hora de codificar algum produto (o que você acha sobre isso? Deixe nos comentários).

Dentro da ciência da computação, existe um campo que estuda a teoria das linguagens de programação. Vale a pena dar uma lida sobre isso. Dentro dessa teoria, há uma parte que trata dos sistemas de tipagem em linguagens de programação. Parece confuso, mas vamos com calma. Se eu consegui entender, você também consegue. Na realidade, é mais simples do que parece.

Tempo de compilação x Tempo de execução

A distinção entre uma linguagem ser fortemente tipada ou fracamente tipada está relacionada à rigidez das regras de tipo, não ao momento da verificação de tipo.

Vamos começar, então, falando sobre tempo de execução e tempo de compilação, conceitos importantes para entender o resto do artigo.

Tempo de compilação

É o período em que o código-fonte (o código que você escreveu) é traduzido para código de máquina pelo compilador. Durante o tempo de compilação, o compilador consegue verificar a sintaxe e a semântica do programa e gera o código para que o programa possa ser executado. Durante esse processo, são realizadas algumas etapas como a análise léxica e sintática, a geração de um código intermediário que facilita a otimização do código para que ele seja mais eficiente e livre de erros.

Tempo de execução

É simplesmente o período no qual um programa está sendo executado. Isso significa que o código gerado a partir do código-fonte é carregado na memória e as instruções são executadas pelo processador. Apesar da explicação ser "simples", várias atividades cruciais estão acontecendo nos bastidores, como a alocação de memória para as variáveis e estruturas de dados, a interação com o sistema operacional e a liberação desses recursos quando o programa é encerrado.

Temos, então, linguagens estaticamente e dinamicamente tipadas. Oh, Deus!

Linguagem Estaticamente Tipada

Em uma linguagem estaticamente tipada, os tipos das variáveis são verificados em tempo de compilação. Isso significa que você precisa especificar o tipo de cada variável, e o compilador verifica se as operações realizadas com essas variáveis são válidas para o tipo especificado.

Linguagem Dinamicamente Tipada

Em uma linguagem dinamicamente tipada, os tipos das variáveis são verificados em tempo de execução. Isso significa que você não precisa especificar o tipo de cada variável e pode atribuir valores de diferentes tipos a uma variável ao longo do tempo.

Acima, vimos sobre o momento de verificação de tipo e agora vamos falar sobre a rigidez das regras de tipo, ou seja, o que uma linguagem permite ou não:

Linguagem Fortemente Tipada

É uma linguagem em que os tipos das variáveis (ou seja, se é int ou string, por exemplo) são rigidamente definidos, e a verificação de tipo é feita em tempo de compilação. Isso significa que ao escrever o código, você precisa definir o tipo de cada variável e não pode atribuir valores de outros tipos a essa variável. Por exemplo, você não pode realizar uma operação matemática com um número e uma string sem primeiro converter explicitamente o tipo do dado.
O C# é uma dessas linguagens. Você não pode fazer como na primeira linha do exemplo abaixo, onde eu atribuo uma string "dez" a uma variável do tipo inteiro. Você receberá um erro de compilação "Cannot implicitly convert type 'string' to 'int'". Para esse tipo de linguagem, geralmente você precisará fazer uma conversão explícita, como na segunda linha do exemplo.

int numero = "dez";
int numero = int.Parse("10");

Outras linguagens fortemente tipadas: Java, Kotlin, C++, Rust e Typescript

Linguagem Fracamente Tipada

Em uma linguagem fracamente tipada, as variáveis podem assumir diferentes tipos de dados ao longo do tempo sem a necessidade de conversões explícitas. A verificação de tipo é feita em tempo de execução, o que permite que as operações sejam realizadas entre diferentes tipos de dados sem gerar erros de tipo em tempo de compilação. Isso permite uma maior flexibilidade, mas também pode levar a erros difíceis de detectar.

O JavaScript é uma dessas linguagens. Pyhton e PHP também!

let numero = 10;
let texto = "20";

let resultado = numero + texto;

console.log(resultado); //1020

No exemplo acima, o resultado exibido no console é a concatenação da string com o número inteiro. Para realizar a soma dos dois valores, é necessário então uma conversão de tipo:

let numero = 10;
let texto = "20";

let resultado = numero + parseInt(texto);
console.log(resultado); // 30

Quando me deparo com algum problema de código, entender o tipo da linguagem e quando esse erro foi gerado me ajuda a resolver de forma mais rápida e eficiente. Por isso, gosto de estudar essas partes um pouco mais teóricas da computação. Pesquisar e fazer esse resumo me ajudou a relembrar conceitos importantes. Espero que tenha ajudado você também.

DEV Community: Bea Tavernaro

NuGet and what's behind your dependencies

What is NuGet?

Dependencies That Bring Other Dependencies

dotnet restore — Where Do Packages Come From?

How Can We Tell if Our Dependencies Are Up to Date and Secure?

Wrapping Up

References

NuGet e o que existe por trás das dependências

O que é o NuGet?

Dependências que trazem outras dependências

dotnet restore — de onde vêm os pacotes?

Como saber se nossas dependências estão atualizadas e seguras?

Concluindo

Referências

A Day Without Visual Studio, Using Only the .NET CLI

Before we start, what can we create?

dotnet build — let's see if this compiles

dotnet run — we already know this one

dotnet test — now let's make QA happy

dotnet publish — we're done, now we need to deliver

Don't memorize everything, ask the CLI itself

From zero to publish without Visual Studio

References

What does the .csproj file tell you about your .NET project?

Creating the simplest project possible

Program.cs — where it all begins

.csproj — the file that describes our project

And what happens when we install a NuGet package?

And where did bin and obj come from?

Wrapping up

References

What Really Happens When You Run `dotnet run`?

You type dotnet run in the terminal

The SDK - Software Development Kit

Our C# code needs to be compiled, right?

.NET Runtime

CLR - Common Language Runtime

Putting it all together

So what's the difference between SDK, CLI, Runtime, and CLR?

References

Um dia sem Visual Studio usando só a .NET CLI

Antes de começar, o que podemos criar?

dotnet build — vamos ver se isso compila

dotnet run — esse aqui a gente já conhece

dotnet test — agora vamos deixar o QA feliz

dotnet publish — terminou, agora precisamos entregar

Não decore tudo, pergunte para a própria CLI

Do zero ao publish sem Visual Studio

Referências

O que o .csproj conta sobre o seu projeto .NET

Criando o projeto mais simples possível

Program.cs — onde tudo começa

.csproj — o arquivo que descreve nosso projeto

E quando instalamos um pacote NuGet?

E de onde surgiram bin e obj?

Concluindo

Referências

O que realmente acontece quando você digita dotnet run?

Você digita dotnet run no terminal

O SDK - Software Development Kit

O código C# precisa ser compilado, certo?

.NET Runtime

CLR - Common Language Runtime

Juntando tudo

Então qual é a diferença entre SDK, CLI, Runtime e CLR?

Referências

Student Benefit Programs in Tech

What are these benefits?

How to get access?

Here’s a tip

GitHub Student Developer Pack

AWS Educate

Azure for Students

Canva

Cursor

DataCamp

DataDog

.tech Domain

Figma for Education

`dotnet restore` — Where Do Packages Come From?

`dotnet restore` — de onde vêm os pacotes?

`dotnet build` — let's see if this compiles

`dotnet run` — we already know this one

`dotnet test` — now let's make QA happy

`dotnet publish` — we're done, now we need to deliver

`Program.cs` — where it all begins

`.csproj` — the file that describes our project

And where did `bin` and `obj` come from?

You type `dotnet run` in the terminal

`dotnet build` — vamos ver se isso compila

`dotnet run` — esse aqui a gente já conhece

`dotnet test` — agora vamos deixar o QA feliz

`dotnet publish` — terminou, agora precisamos entregar

`Program.cs` — onde tudo começa

`.csproj` — o arquivo que descreve nosso projeto

E de onde surgiram `bin` e `obj`?

Você digita `dotnet run` no terminal