domingo, 2 de agosto de 2026

VISUAL STUDIO - ARQUIVO CSPROJ

O arquivo `.csproj` (C# Project) é um dos arquivos mais importantes de um projeto .NET. Ele descreve como o projeto deve ser compilado, quais dependências ele possui, qual versão do .NET utiliza, quais arquivos devem ser incluídos e diversas configurações do projeto.


Pense nele como a "receita de montagem" da sua aplicação.


## Estrutura de um projeto


Um projeto ASP.NET Core pode ter esta estrutura:


```text

MinhaApi

├── Controllers

├── Models

├── Services

├── Repositories

├── appsettings.json

├── Program.cs

├── MinhaApi.csproj

├── bin

└── obj

```


Observe que existe apenas um arquivo `.csproj` por projeto (normalmente). Já a solução (`.sln`) pode conter vários projetos, cada um com seu próprio `.csproj`.


---


# Exemplo de um arquivo `.csproj`


```xml

<Project Sdk="Microsoft.NET.Sdk.Web">


  <PropertyGroup>

    <TargetFramework>net8.0</TargetFramework>

    <Nullable>enable</Nullable>

    <ImplicitUsings>enable</ImplicitUsings>

  </PropertyGroup>


</Project>

```


Vamos entender cada parte.


---


## 1. SDK


```xml

<Project Sdk="Microsoft.NET.Sdk.Web">

```


Define qual tipo de projeto será criado.


Alguns exemplos:


| SDK                               | Tipo                          |

| ---------------------------- | ------------------------ |

| Microsoft.NET.Sdk            | Biblioteca ou Console |

| Microsoft.NET.Sdk.Web     | ASP.NET Core            |

| Microsoft.NET.Sdk.Worker | Worker Service          |

| Microsoft.NET.Sdk.Razor   | Razor Class Library     |


---VOU DESLIGAR A LUZ TA CAINDO

PODE


## 2. TargetFramework


```xml

<TargetFramework>net8.0</TargetFramework>

```


Informa qual versão do .NET será utilizada.


Exemplos:


```xml

<TargetFramework>net6.0</TargetFramework>

```


```xml

<TargetFramework>net7.0</TargetFramework>

```


```xml

<TargetFramework>net8.0</TargetFramework>

```


```xml

<TargetFramework>net9.0</TargetFramework>

```


---


## 3. Nullable


```xml

<Nullable>enable</Nullable>

```


Ativa as **Referências Anuláveis (Nullable Reference Types)**.


Sem isso:


```csharp

string nome = null;

```


Não gera aviso.


Com isso ativado:


```csharp

string nome = null;

```


O compilador gera um aviso, incentivando um código mais seguro.


---


## 4. Implicit Usings


```xml

<ImplicitUsings>enable</ImplicitUsings>

```


Evita que você precise escrever vários `using` comuns em todos os arquivos.


Sem:


```csharp

using System;

using System.Collections.Generic;

using System.Linq;

```


Com `ImplicitUsings`, muitos desses namespaces são adicionados automaticamente.


---


# Adicionando pacotes NuGet


Quando você instala um pacote, o `.csproj` é atualizado.


Exemplo:


```xml

<ItemGroup>


    <PackageReference Include="Dapper" Version="2.1.35" />


    <PackageReference Include="Oracle.ManagedDataAccess.Core" Version="23.6.0" />


</ItemGroup>

```


Esses pacotes serão restaurados automaticamente durante o build.


---


# Referência entre projetos


Imagine a solução:


```text

MinhaSolucao

├── API

├── Core

├── Infrastructure

└── Tests

```


A API depende do projeto Core.


No `.csproj` da API:


```xml

<ItemGroup>


    <ProjectReference Include="..\Core\Core.csproj" />


</ItemGroup>

```


Assim, não é necessário copiar DLLs manualmente.


---


# Arquivos incluídos no projeto


Você pode incluir arquivos específicos:


```xml

<ItemGroup>


    <None Include="README.md" />


</ItemGroup>

```


Ou copiar arquivos para a saída:


```xml

<ItemGroup>


    <None Update="appsettings.json">

        <CopyToOutputDirectory>Always</CopyToOutputDirectory>

    </None>


</ItemGroup>

```


---


# Múltiplos frameworks


É possível compilar para mais de uma versão do .NET:


```xml

<PropertyGroup>


    <TargetFrameworks>

        net8.0;

        net9.0

    </TargetFrameworks>


</PropertyGroup>

```


Nesse caso, o build gera saídas para ambas as versões.


---


# Configurações de compilação


Você pode definir propriedades como:


```xml

<PropertyGroup>


    <LangVersion>latest</LangVersion>


    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>


    <GenerateDocumentationFile>true</GenerateDocumentationFile>


</PropertyGroup>

```


Isso permite, por exemplo:


* usar a versão mais recente da linguagem C#;

* tratar avisos como erros;

* gerar documentação XML para IntelliSense.


---


# Como ele participa da compilação?


Quando você executa:


```text

dotnet build

```


ou usa **Build Solution** no Visual Studio, o processo é, em linhas gerais:


```text

.csproj

      │

      ▼

MSBuild

      │

      ▼

Restaura pacotes NuGet

      │

      ▼

Compila os arquivos .cs

      │

      ▼

Gera a pasta obj

      │

      ▼

Gera a pasta bin

```


O MSBuild lê o `.csproj` para saber exatamente **o que** compilar e **como** compilar.


---


# Relação entre `.sln` e `.csproj`


Muitas pessoas confundem esses dois arquivos.


| `.sln`                                      | `.csproj`                                    |

| ----------------------------------- | -------------------------------------- |

| Representa a solução                | Representa um projeto                 |

| Pode conter vários projetos       | Representa apenas um projeto      |

| Usado pelo Visual Studio para    |                                                   |

organizar a solução                   | Usado pelo MSBuild para compilar |

| Não contém regras de               |                                                   |

compilação                               | Contém todas as configurações de |                                                build                                           |     


Exemplo:


```text

SistemaFinanceiro.sln

├── API

│   └── API.csproj

├── Core

│   └── Core.csproj

├── Infrastructure

│   └── Infrastructure.csproj

└── Tests

    └── Tests.csproj

```

Em soluções com múltiplos projetos (API, Domain, Infrastructure e Tests), ele é responsável por definir as dependências entre projetos, os pacotes NuGet utilizados e as configurações de compilação, tornando-se um dos principais arquivos de configuração da aplicação.


quarta-feira, 29 de julho de 2026

VISUAL STUDIO - PASTAS BIN E OBJ

As pastas bin e obj são geradas automaticamente pelo Visual Studio e pelo .NET durante a compilação do projeto. Todo desenvolvedor C# precisa entender bem essas duas pastas, principalmente quando começa a trabalhar com projetos grandes.


## 📁 Pasta bin (Binary)


A pasta bin contém o resultado final da compilação, ou seja, os arquivos que serão executados.


Exemplo:


```

MeuProjeto

├── bin

│   └── Debug

│       └── net8.0

│           ├── MeuProjeto.exe

│           ├── MeuProjeto.dll

│           ├── MeuProjeto.pdb

│           ├── appsettings.json

│           └── outras DLLs...

```


### O que existe dentro dela?


* `.exe` → Programa executável (quando é aplicação desktop ou console)

* `.dll` → Biblioteca da aplicação

* `.pdb` → Informações para depuração (Debug)

* Arquivos `.json`

* Dependências (DLLs de bibliotecas)

* Recursos da aplicação


### Exemplo


Imagine este projeto:


```

Calculadora.sln

└── Calculadora

```


Ao clicar em **Build**, o Visual Studio cria:


```

Calculadora

├── bin

│   └── Debug

│       └── net8.0

│           ├── Calculadora.exe

│           ├── Calculadora.dll

│           ├── Newtonsoft.Json.dll

│           └── ...

```


É daqui que o Windows executa sua aplicação.


---


## 📁 Pasta obj (Object)


Esta pasta é usada apenas durante a compilação.


Ela guarda arquivos intermediários necessários para que o compilador consiga gerar o conteúdo da pasta bin.


Exemplo:


```

MeuProjeto

├── obj

│   └── Debug

│       └── net8.0

│           ├── MeuProjeto.dll

│           ├── project.assets.json

│           ├── project.nuget.cache

│           ├── MeuProjeto.AssemblyInfo.cs

│           └── ...

```


### O que existe nela?


* Código gerado automaticamente

* Cache do compilador

* Informações do NuGet

* Recursos compilados

* Arquivos temporários

* Arquivos utilizados pelo MSBuild


Ela serve para acelerar as próximas compilações.


---


# Como funciona a compilação


Quando você aperta Ctrl + Shift + B, ocorre aproximadamente isto:


```

Seu Código C#

        │

        ▼

   Compilador C#

        │

        ▼

    Pasta obj

        │

        ▼

    Geração Final

        │

        ▼

    Pasta bin

```


Fluxo resumido:


```

.cs

   │

   ▼

obj

   │

   ▼

bin

```


---


# Diferença entre elas


| bin                          | obj                                          |

| -----------------------| -----------------------------------  |

| Resultado final         | Arquivos temporários                 |

| Executável               | Arquivos intermediários             |

| DLLs                        | Cache do compilador                 |

| EXE                         | Código gerado automaticamente |

| Pode ser distribuída  | Não é distribuída                        |


---


# Posso apagar?


Sim.


Você pode apagar tranquilamente as duas pastas.


Na próxima compilação o Visual Studio irá recriá-las.


É comum fazer isso quando aparecem erros estranhos.


```

Apagar

bin/

obj/

Build Solution

Tudo será recriado.

```


---


# O que faz o Clean Solution?


Quando você executa:


```

Build

    ↓

Clean Solution

```


O Visual Studio remove praticamente todo o conteúdo gerado em bin e obj.


Depois:

```

Rebuild Solution

```


faz:


```

Clean

Compila tudo novamente

Cria bin

Cria obj

```


---


# Por que às vezes apagar `bin` e `obj` resolve problemas?


Imagine que você alterou:


```

ClasseA.cs

```


Mas a DLL antiga ainda está sendo utilizada.


O Visual Studio pode acabar usando um cache da pasta `obj`.


Resultado:


* DLL antiga

* cache antigo

* referências antigas


Ao apagar:


```

bin

obj

```


o compilador é obrigado a reconstruir tudo do zero.


---


# Em projetos ASP.NET Core


É comum encontrar algo como:


```

MinhaAPI

├── Controllers

├── Models

├── Services

├── appsettings.json

├── bin

│   └── Debug

│       └── net8.0

└── obj

    └── Debug

        └── net8.0

```


Após publicar a aplicação, a pasta bin conterá todos os arquivos necessários para execução no servidor, enquanto a pasta obj continua sendo usada apenas durante o processo de build.


---


# Essas pastas devem ir para o Git?


Não.


Elas devem ser ignoradas no controle de versão, pois são geradas automaticamente em qualquer máquina.


Um arquivo `.gitignore` típico inclui:


```gitignore

bin/

obj/

```



domingo, 12 de julho de 2026

O que é QR Code?


 

QR Code significa Quick Response Code ("Código de Resposta Rápida"). É aquele quadrado com vários pontinhos pretos que você vê em pagamentos PIX, cardápios digitais, ingressos e sites.

O QR Code foi criado em 1994 por um engenheiro japonês chamado Masahiro Hara, que trabalhava na empresa japonesa Denso Wave.

 

Por que ele foi criado?

Na época, a indústria automobilística japonesa precisava rastrear peças nas fábricas com mais rapidez.

Os códigos de barras tradicionais tinham limitações:

    • Armazenavam pouca informação.
    • Precisavam ser lidos em uma posição específica.
    • Eram mais lentos.

Então Masahiro Hara desenvolveu o QR Code para:

    • Armazenar mais dados.
    • Ser lido de qualquer ângulo.
    • Ser mais rápido.

 

Curiosidade interessante

A Denso Wave decidiu não cobrar royalties pelo uso do QR Code. Isso permitiu que a tecnologia se espalhasse pelo mundo inteiro.

Hoje ele é usado em:

    • PIX
    • WhatsApp Web
    • Ingressos de eventos
    • Cardápios digitais
    • Controle de estoque
    • Pagamentos em geral

Ou seja, uma tecnologia criada para identificar peças de carros em 1994 acabou se tornando uma das formas mais usadas de pagamento e compartilhamento de informações no mundo.

Existem dois tipos principais:

    • QR Code Estático: sempre o mesmo código. 
    • QR Code Dinâmico: cada pagamento gera um código diferente

Um exemplo simples:

Quando você vê este texto:

PIX: 21999999999
Nome: Wellington
Banco: XYZ

Uma pessoa consegue ler, mas precisa digitar tudo manualmente.

O QR Code pega essas informações e as transforma em um desenho cheio de quadradinhos:

⬛⬛⬜⬜⬛⬛
⬜⬛⬜⬛⬜⬛
⬛⬜⬛⬛⬜⬜
⬛⬛⬜⬛⬛⬜
Para nós parece um monte de quadrados aleatórios, mas para o celular é como um texto codificado.
Uma analogia

Pense no código de barras do supermercado:

    • O código de barras guarda um número.
    • O leitor lê esse número rapidamente.

O QR Code é uma evolução do código de barras:

    • Guarda muito mais informação.
    • Pode armazenar textos, links, telefones, localização e dados de PIX.
    • Pode ser lido pela câmera do celular.

O que existe dentro de um QR Code PIX?

Quando alguém escaneia o QR Code do seu blog, o celular pode ler algo parecido com:

Chave PIX: seuemail@gmail.com
Nome: Wellington Pereira
Cidade: Rio de Janeiro

Ou até mais informações. O aplicativo do banco interpreta esses dados e já monta a transferência.

Como o celular lê?

    • A câmera fotografa o QR Code.
    • O aplicativo identifica os quadradinhos.
    • Converte os quadradinhos em números.
    • Converte os números em texto.
    • Mostra a informação para o usuário.

É parecido com alguém traduzindo um código secreto.


Curiosidade

Um QR Code pode armazenar:

    • Links de sites
    • Telefones
    • Senhas de Wi-Fi
    • Textos
    • Dados de pagamento PIX
    • Coordenadas de GPS




sexta-feira, 27 de março de 2026

ORACLE PL/SQL- Tipos de JOIN (Explicação Simples)

 ## Tipos de JOIN


Vou explicar usando duas tabelas como exemplo:

- **CLIENTES** (id, nome)

- **PEDIDOS** (id, cliente_id, valor)


### 1. **INNER JOIN** (ou só JOIN)

**Retorna apenas os registros que têm correspondência em AMBAS as tabelas.**

```sql

SELECT * FROM CLIENTES c

INNER JOIN PEDIDOS p ON c.id = p.cliente_id;

**Resultado:** Só clientes que fizeram pedidos. Clientes sem pedido NÃO aparecem.

Cliente com pedido   → aparece

Cliente sem pedido   → não aparece


### 2. **LEFT JOIN** (ou LEFT OUTER JOIN)

**Retorna TODOS os registros da tabela da ESQUERDA + correspondências da direita.**

```sql

SELECT * FROM CLIENTES c

LEFT JOIN PEDIDOS p ON c.id = p.cliente_id;

**Resultado:** Todos os clientes. Quem não tem pedido fica com NULL nos campos de pedido.

Cliente com pedido   → aparece com dados do pedido

Cliente sem pedido   → aparece com NULL nos campos do pedido


### 3. **RIGHT JOIN** (ou RIGHT OUTER JOIN)

**Retorna TODOS os registros da tabela da DIREITA + correspondências da esquerda.**

```sql

SELECT * FROM CLIENTES c

RIGHT JOIN PEDIDOS p ON c.id = p.cliente_id;

**Resultado:** Todos os pedidos. Pedidos sem cliente (raro) aparecem com NULL nos campos de cliente.

Pedido com cliente   → aparece com dados do cliente

Pedido sem cliente   → aparece com NULL nos campos do cliente


### 4. **FULL JOIN** (ou FULL OUTER JOIN)

**Retorna TODOS os registros de AMBAS as tabelas.**

```sql

SELECT * FROM CLIENTES c

FULL JOIN PEDIDOS p ON c.id = p.cliente_id;

**Resultado:** Tudo. Clientes sem pedido e pedidos sem cliente aparecem com NULLs.

Clientes com e sem pedido → todos aparecem

Pedidos com e sem cliente → todos aparecem


### 5. **CROSS JOIN**

**Produto cartesiano: cada linha da primeira combina com TODAS da segunda.**

```sql

SELECT * FROM CLIENTES

CROSS JOIN PEDIDOS;

**Resultado:** Se 10 clientes e 100 pedidos → 1.000 registros (cada cliente com cada pedido)


### 6. **SELF JOIN**

**JOIN da tabela com ela mesma.** Útil para relações hierárquicas.

```sql

SELECT e.nome AS empregado, g.nome AS gerente

FROM FUNCIONARIOS e

LEFT JOIN FUNCIONARIOS g ON e.gerente_id = g.id;


## Resumo Visual

| Tipo                    | Esquerda                                       | Direita |

| **INNER**       | ✅ só correspondentes                 | ✅ só correspondentes |

| **LEFT**          | ✅ todos                                      | ✅ só correspondentes |

| **RIGHT**       | ✅ só correspondentes                 | ✅ todos |

| **FULL**         | ✅ todos                                       | ✅ todos |


## Exemplo com diagrama mental

Tabela A          Tabela B

┌─────┐          ┌─────┐

│ 1           │          │ 2           │

│ 2           │          │ 3           │

│ 3           │          │ 4           │

│ 5           │          │             │

└─────┘          └─────┘


INNER JOIN: [2, 3]        (o que tem nos dois)

LEFT JOIN:  [1, 2, 3, 5]  (tudo de A)

RIGHT JOIN: [2, 3, 4]     (tudo de B)

FULL JOIN:  [1, 2, 3, 4, 5] (tudo de ambos)

```


## Dica prática

- **INNER JOIN**: quando só importam registros relacionados

- **LEFT JOIN**: quando não quer perder os registros da tabela principal (mais comum)

- **FULL JOIN**: quando precisa ver tudo de ambos os lados

- **RIGHT JOIN**: raro, dá pra substituir por LEFT trocando ordem das tabelas