As aplicações podem obter essas configurações de duas formas:

1. Machine.config – que pode ser acessado por todos as aplicações .NET.
   Caminho do arquivo: %Windir%\Microsoft.NET\Framework\v2.0.50727\Config\Machine.config
2. application-specific.config – pode ser um app.config para desktop application ou web.config para web application.

Pelo fato de impactar em todas as aplicação .NET da máquina, o arquivo Machine.config é dificilmente modificado. A melhor solução é a utilização do application-specific.config, com essa alternativa definimos configurações específicas e unicamente para a aplicação que estamos trabalhando.
A seguir apresentarei as principais funcionalidades do pacote System.Configuration.

Uma das utilizações mais simples do arquivo de configuração é o AppSettings, nela os dados são gravados na estrutura de chave-valor.

AppSettings permite gerenciar uma coleção do tipo NameValueCollection.

Escrevendo Configurações no Application Configuration

Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.AppSettings.Settings.Add("MyKey", "MyValue");
config.Save(ConfigurationSaveMode.Modified);

Após a execução do código o arquivo de configuração será modificado da seguinte forma para conter a chave-valor conforme abaixo:

< ?xml version="1.0" encoding="utf-8"?>
<configuration>
   <appsettings>
      <add key="MyKey" value="MyValue" />
   </appsettings>
</configuration>

Dica: Sempre verifique o arquivo de configuração do executável da aplicação. As alterações não são refletidas no arquivo de configuração do código fonte.

Lendo configurações do Application Configuration

Abaixo o arquivo de configuração contem duas chaves (MyKey e Greeting).

< ?xml version="1.0" encoding="utf-8"?>
<configuration>
   <appsettings>
      <add key="MyKey" value="MyValue" />
      <add key="Greeting" value="Hello, world!" />
   </appsettings>
</configuration>

O código a seguir mostra todas as configurações de chave-valor contido no arquivo de configuração.

for (int i = 0; i < ConfigurationManager.AppSettings.Count; i++)
{
   Console.WriteLine("{0}: {1}",
   ConfigurationManager.AppSettings.AllKeys[i],
   ConfigurationManager.AppSettings[i]);
}

Para acessar uma informação, campo value de uma determinada chave (key), podemos proceder da seguinte forma:

Console.WriteLine(ConfigurationManager.AppSettings["Greeting"]);

Utilizando Connection Strings

Para acessar strings de conexão, use a coleção estática ConfigurationManager.ConnectionStrings, o retorno dessa propriedade é um ConnectionStringSettingsCollection.
As três propriedades mais utilizadas da classe Connection-StringSettings são:

• Name - que define o nome da conexão.
• Provider-Name - que define de tipo da conexão com a base de dados.
• ConnectionString - que define como o cliente se conecta com o servidor.

O elemento connectionStrings agrupa as informações de conexão do sistema. Um arquivo de configuração pode contar diversos definições de conexão.

<connectionstrings>
   <add name="LocalSqlServer" connectionString="data source=.\SQLEXPRESS; Integrated Security=SSPI; AttachDBFilename=|DataDirectory|aspnetdb.mdf; User Instance=true" providerName="System.Data.SqlClient" />
</connectionstrings>

O código a seguir mostra todas as strings de conexão contido no arquivo de configuração.

ConnectionStringSettingsCollection connections = ConfigurationManager.ConnectionStrings;
foreach (ConnectionStringSettings connection in connections)
{
   Console.WriteLine("Name: {0}", connection.Name);
   Console.WriteLine("Connection string: {0}", connection.ConnectionString);
   Console.WriteLine("Provider: {0}", connection.ProviderName);
   Console.WriteLine("Source: {0}", connection.ElementInformation.Source);
}

Para acessar informações de uma conexão especifica, podemos proceder da seguinte forma:

Console.WriteLine(ConfigurationManager.ConnectionStrings["LocalSqlServer"].ConnectionString);

Lendo configurações do Machine Configuration

Como mencionsado, dificilmente iremos manipular um Machine.config. Porem caso se faça necessário, o código a seguir cria o objeto Configuration que representa o arquivo Machine.config.

   Configuration machineSettings = ConfigurationManager.OpenMachineConfiguration();
   ProtectedConfigurationSection pcs = (ProtectedConfigurationSection)machineSettings.GetSection("configProtectedData");
   Console.WriteLine(pcs.DefaultProvider);
   Console.WriteLine(pcs.Providers["DataProtectionConfigurationProvider"].Parameters["description"]);

Seção customizada - Custom Sections

Definições de configurações de aplicação customizados, podem ser criadas de 2 formas. Implementando inteface IConfigurationSectionHandler ou derivando uma classe de ConfigurationSection.
A segunda opção é recomentada para versões 2.0 ou anteriores, pore esse motivo vou apresentar somente como realizar a primeira implementação pois se aplica a versões mais recentes do Framework.NET.

Criando uma seção Customizado utilizando IConfigurationSectionHandler

Devemos criar uma única classe para a seção customizada na aplicação, essa classe deve implementar a interface IConfigurationSectionHandler.
Implementando a interface, devemos criar um construtor vazio e implementar o método Create. Dos três parâmetros requiridos pelo método, normalmente utilizaremos omente o terceiro, um objeto do tipo System.Xml.XmlNode que contem os dados armazenados no arquivo xml contendo os dados da seção customizada.

Demonstração de como estruturar a seção de configuração customizada no arquivo .config.

<configuration>
   <configsections>
      <section name="customSettings" type="ConfigApp.CustomConfigHandler, ConfigApp"/>
   </configsections>
   <appsettings>
      <add key="Greeting" value="Hello, world!" />
      <add key="Another Key" value="Another value" />
   </appsettings>
   <customsettings>
      <lastuser>Tony</lastuser>
      <lastnumber>32</lastnumber>
   </customsettings>
</configuration>
 
Abaixo o código que permite acessar a seção customizada.

public class MySettings
{
   public string lastUser;
   public int lastNumber;
   public MySettings() { }
}
 
public class CustomConfigHandler : IConfigurationSectionHandler
{
   public CustomConfigHandler() { }
 
   public object Create(object parent, object configContext, System.Xml.XmlNode section)
   {
      MySettings settings = new MySettings();				
      settings.lastUser = section.SelectSingleNode("lastUser").InnerText;
      settings.lastNumber = int.Parse(section.SelectSingleNode("lastNumber").InnerText);
 
      return settings;
   }
}
 
public class Program
{
   public static void Main(string[] args)
   {
      MySettings settings = (MySettings)ConfigurationManager.GetSection("customSettings");
 
      Console.WriteLine(settings.lastUser);
      Console.WriteLine(settings.lastNumber);
   }
}

Observe no arquivo de configuração a seção <configsections>, que declara uma seção customizada e informa se noma na propriedade de name e do método que implementa IConfigurationSectionHandler e o nome do assembly na propriedade type.
Então, podemos criar uma seção de configuração customizada, com elementos para cada valor personalizado.

O método CustomConfigHandler.Create irá ler os valores da sessão customizada e atribuir a uma classe de dados que irá retornar os dados de forma tipada.

A seção <appsettings> está incluído apenas para demonstrar que um arquivo. Config pode conter configurações personalizadas e configurações de aplicativos padrão.

Enjoy

XML Correto

<elemento atributo='Stacem'>Formula matemática do item</elemento>

XML corrompido

<elemento atributo='St'acem'>Valor de X > que valor de Y.</elemento>

Para resolver esse problema, devesse utilizar em campos de informações (valores dos elementos ou atributos) um “encode” para esses caracteres.

Encode XML

Basicamente são 5 valores:

No Framework.NET existem alguns caminhos de aplicar o encode XML:

1. string.Replace()
A maneira mais feia, mas que funciona, seria utilizar o famoso string.Replace().
Repetindo a rotina 5 vezes, uma para cada caracter especial.

string text = "Este é um \"nó\" XML com caracteres 'especiais' & <> diferente de tudo!!";
string encodedXml = text.Replace("&", "&amp;").Replace("< ", "&lt;").Replace(">", "&gt;").Replace("\"", "&quot;").Replace("'", "&apos;");
// RESULT: Este é um &quot;nó&quot; XML com caracteres &apos;especiais&apos; &amp; &lt;&gt; diferente de tudo!!

2. System.Web.HttpUtility.HtmlEncode()
É utilizado para codificar textos em HTML, muito utilizado em ASP.NET, porem ele não codifica o apóstrofo e força você utilizar uma referência de pacote Web. Se for uma aplicação desktop, não recomendo sua utilização.

string text = "Este é um \"nó\" XML com caracteres 'especiais' & <> diferente de tudo!!";
string encodedXml = HttpUtility.HtmlEncode(text);
// RESULT: Este é um &quot;nó&quot; XML com caracteres 'especiais' &amp; &lt;&gt; diferente de tudo!!

3. System.Security.SecurityElement.Escape()
Outra maneiroa é utilizar o comando Escape() que trata os 5 caracteres especiais.

string text = "Este é um \"nó\" XML com caracteres 'especiais' & <> diferente de tudo!!";
string encodedXml = System.Security.SecurityElement.Escape(text);
// RESULT: Este é um &quot;nó&quot; XML com caracteres &apos;especiais&apos; &amp; &lt;&gt; diferente de tudo!!

Gosto muito da opção de codificar com System.Security.SecurityElement.Escape(), acredito que seja a forma mais estética com relação ao código.
Não sei quanto a desempenho das formas, mas manipulação de string não é a melhor das escolhas.
E a segunda alem de não abranger todos os caracteres especiais, ainda fica limitada a aplicações web.

Espero ter ajudado

O Framework .NET possui o objeto Thread que permite mais flexibilidade e gerenciamento sobre as thread executadas em background do que o objeto ThreadPool.

Thread Priority
Uma das propriedades do objeto Thread á sua prioridade. Após a thread criada, mas antes de iniciar a thread, podemos definir a prioridade da thread com propriedade Thread.Priority usando o enumerador ThreadPriority.
A Thread priority controla como o sistema operacional irá agendar o tempo para a execução da Thread. Geralmente threads com maior prioridade rodam antes das threads com baixo prioridades, por padrão as threads tem o valor de prioridade definida como Normal.

Thread State
Outra propriedade do objeto é Thread.ThreadState pode ser utilizada para verificar o estado das threads em background.
Os estados possíveis são:

• Unstarted: estado inicial da thread (antes de executar o método Thread.Start).
• Running: estado ativo ou executando (após de executar o método Thread.Start).
• Stopped: estado parada.
• WaitSleepJoin: estado esperando outra thread completar.
• SuspendRequested: estado repondendo solicitanção de pausa.
• Suspended: estado suspensa.
• AbortRequested: estado respondendo a solicitanção de abandono.
• Aborted: estado abortado.

Thread com parâmetros e retorno em C#

Para fornecer parâmetros para uma thread, criamos uma classe com um construtor que recebe um ou mais parâmetros e armazena o dado e a usa para criar o objeto ThreadStart.
Para obter o retorno da Thread, criamos um método que recebe o resultado de retorno como uma parâmetro. Depois criamos um delegate para o método e passamos o delegado e próprio método como parâmetro para a classe.

using System;
using System.Threading;
 
namespace ManagerThread
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Calculator calculator = new Calculator("Multiplicador", 15, ResultCallback);
 
            Thread thread = new Thread(calculator.Execute);
            thread.Start();
 
            Console.WriteLine("Main Thread aguarda finalização das threads em background.");
            thread.Join();
            Console.WriteLine("Thread completada.");
            Console.ReadKey();
        }
 
        public static void ResultCallback(int value)
        {
            Console.WriteLine("Resultado: {0}", value);
        }
    }
 
    public class Calculator
    {
        // Delegate que define a assinatura do método de callback (retorno).
        public delegate void ResultDelegate(int value);
 
        private readonly ResultDelegate callback;
        private readonly string message;
        private readonly int value;
 
        public Calculator(string message, int value, ResultDelegate callback)
        {
            this.message = message;
            this.value = value;
            this.callback = callback;
        }
 
        public void Execute()
        {
            Console.WriteLine(message);
 
            if (callback != null)
            {
                callback(value*2);
            }
        }
    }
}

A thread é executada somente após o comando thread.Start(). O comando thread.Join() força a thread principal a ficar aguardando a finalização da thread em background para seguir o processo.

Observações:
Threads podem estar em mais de 1 estado ao mesmo tempo.
Os métodos Thread.Suspend e Thread.Resume são utilizados para pausar e retornar a thread principal. Porem estes métos esta depreciados, e podem causar problemas de execuação, utilize o método Thread.Abort().

Enjoy

O que é o M de Model

O Model representa os dados da aplicação, ou seja, são objetos que armazenam as informações a serem transportados da camada inferior para e pela interface, dessa forma a camada de interface é desacoplada das demais camadas. É muito comum iniciantes confundirem model com objetos de domínio, inclusive já li esse erro em diversas literaturas, o que ajuda a tornar as coisas mais confusas.
Também não confunda arquitetura em camadas com MVC, pois a estruturação do MVC encontra-se somente na primeira camada.

Exemplificando

Criei um ASP.NET MVC Application chamado NewsletterApp. A idéia é criar nessa aplicação um cadastro de cliente, e exemplificar o conceito de Model.

Nessa estrutura criei uma classe Model chamada Customer.cs

public class Customer
{
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
    public bool IsActive { get; set; }
}

Um controller chamado HomeController que possui três Action Methods, um Index() que irá renderizar a View Index.aspx, os outros dois CustomerRegistration, repare nos atributos AcceptVerbs isso irá permitir que as requisições do tipo Get sejam atribuídas ao primeiro Action Method CustomerRegistration e os submits do formulário (requisições do tipo Post) sejam atribuídas ao segundo.

public class HomeController : Controller
{
    public ViewResult Index()
    {
        return View();
    }
 
    [AcceptVerbs(HttpVerbs.Get)]
    public ViewResult CustomerRegistration()
    {
        return View();
    }
 
    [AcceptVerbs(HttpVerbs.Post)]
    public ViewResult CustomerRegistration(Customer customer)
    {
        // TODO: executar o processo de cadastro do cliente 
        // Neste ponto, é chamada para camada de negócio ou banco de dados
 
        return View("CustomerResponse", customer);
    }
}

Observação: No último Action Method coloquei um comentário. Ele se refere ao local onde o poderia ser realizada a chamada para camada de negócio ou banco de dados, para o cadastramento dos dados do cliente. Como o foco desse post não é o desenvolvimento desse processo. Optei em utilizar um comentário para exemplificar.

E duas páginas Index.aspx que é a nossa Startup Page. nela constem somente uma ancora (tag a) para a página CustomerRegistration.aspx que executa o processo de cadastro.

    <p>< %= Html.ActionLink("Cadastro Cliente", "CustomerRegistration") %></p>

E CustomerRegistration.aspx que possui um formulário com um input type=”submit”, para enviar os dados do cliente para a Action de destino do Form.

    <h1>Cliente</h1>
    <fieldset>
    < % using(Html.BeginForm()) { %>
        <p>Nome:</p>
        <p>< %= Html.TextBox("Name") %></p>
        <p>Email:</p>
        <p>< %= Html.TextBox("Email")%></p>
        <p>Telefone:</p>
        <p>< %= Html.TextBox("Phone")%></p>
        <p>Ativo: < %= Html.DropDownList("IsActive", new[] {
                    new SelectListItem { Text = "Sim",Value = bool.TrueString },
                    new SelectListItem { Text = "Não",Value = bool.FalseString }}) %>
        </p>
        <input type="submit" value="Salvar" />
    < % } %>
    </fieldset>

Agora vamos criar mais uma página para a resposta do cadastramento.
Para isso basta clicar com o botão direito sobre o diretório Home > Add > View. Informamos o nome da página, no exemplo utilizei CustomerResponse.
E selecionamos a opção Create a strongly-typed view.

E inclui o seguinte código na página.

1
2
3
4
5
6
7
8
9

<h1>Obrigado!</h1>
<p>< %= Html.Encode(Model.Name) %> foi cadastrado com sucesso.</p>
<p>Seu status é 
< % if (Model.IsActive == true){ %>
        ativo.
< % }else{ %>
        inativo.
< % } %>
</p>

Neste momento você deve estar se perguntando como algumas algumas coisas acontecem?
É agora que entra a mágica do MVC.

Model Binding

Na HomeController a primeira Action Method de CustomerRegistration simplismente renderiza a View, porém a segunda recebe uma instância de Customer como um parâmetro.
A pergunta aqui é como um método é invoca via HTTP request passando um tipo .NET como parâmetro se ele é totalmente desconhecido do HTTP?
Simples… Chama-se Model Binding. O ASP.NET MVC automaticamente instância e converte os parâmetros por meio de chave/valor que tenham os mesmos nomes das propriedades do tipo .NET utilizado como parâmetro no Action Method.
Repare que os nomes dos elementos text do formulário possuem o mesmo nome dos atributos da classe Customer.

Outra característica apresentada pela segunda Action é a especificação da View que irá ser renderizada, e definição do objeto Model que será passado para View, esse View é chamado de strongly typed view, pois está fortemente tipada com um objeto da aplicação.
Esta view permite que seja acessada a variável chamada Model que esta relacionada ao tipo da criação da página no caso do exemplo o objeto Customer.

Conclusão

Gostei muito da arquitetura MVC por permite uma melhor separação de responsabilidade dos componentes de interface. Como por exemplo a separação de Actions para Get E Post. O encapsulamento de parâmetro em instância de objetos reduz a escrita de código.
A utilização de objetos Model na aplicação ficou mais presente, e sua interação com outros instâncias passa a ser mais requerida.

Até mais
Enjoy

Ao criar um projeto do tipo ASP.NET MVC Web Application uma aplicação de demonstração (padrão) é apresentada na Solution Explorer.

O ASP.NET MVC a primeira vista parece ser bem complicado, mas apartir do momento que se conhece melhor a sua estrutura e seu funcionamento, ele passa a ser bem simples.

Estrutura do ASP.NET MVC Web Application

Primeiramente vamos nos atentarmos a estrutura, pois ela contem diversas convensões que devem ser utilizadas pelo ASP.NET MVC.

Repare nos diretórios, obrigatóriamente teremos o Controller, Model e View.
Outra convensão é para as classes controladoras (contidas no diretório Controller), devem possuir o sufixo Controller em seus nomes e um sub-diretório no diretorio View. Confuso? Repare na Solution o diretorio Controller, note que possui duas classes controladoras Account e Home ambas com o sufixo Controller. Agora veja o diretório View, ele possui dois sub-diretórios com o mesmo nome da controladora (Account e Home).
No diretório View ficam os templates que correspondem a ações dos controllers e seram renderizados.
O sub-diretório View/Shared contém recorsos compartilhados com a aplicação, como página de erro genérica, master page, entre outros.
O diretório Script é destinado a armazenar biblioteca JavaScript e scripts (.js)
O diretório Content é destinado a armazenar arquivos de estilo (CSS), arquivos de imagens e outros não dinâmicos.
Na raiz do ASP.NET MVC Web Application temos os arquivos Global.asax, default.aspx e web.config estes arquivos são utilizados em conjunto para realizarem a sobreescrita (rewrite) de URL, mas esse assunto ficará para um próximo post.

Como ASP.NET MVC trabalha

Para compreender melhor o funcionamento do ASP.NET MVC, vamos remover alguns arquivos e diretórios da aplicação padrão.

• App_Data (diretório)
• AccountController.cs (arquivo)
• Account (diretório)
• About.aspx (arquivo)
• Index.aspx (arquivo)
• Error.aspx (arquivo)
• LogOnUserControl.ascx (arquivo)
• Site.Master (arquivo)

Hello Word

Como é padrão e não pode faltar em qualquer tutorial de introdução, vamos criar a famosa aplicação Hello Word!. Para isso no arquivo HomeController reescreva o código para que fique da seguinte forma:

1
2
3
4
5
6
7

    public class HomeController : Controller
    {
        public string Index()
        {
            return "Hello, word!";
        }
    }

Pronto, ao executar (F5) criamos nosso primeiro ASP.NET MVC Application.

Na arquitetura MVC, os controllers são reponsáveis por manipular as requisições. No .NET, controller são classes derivadas de System.Web.Mvc.Controller. E cada método público no Controller é conhecido como Action Method (método de ação), que são chamados da web por meio de alguma URL. Em nossa aplicação acima temos nosso controller chamado HomeController com seu action method chamado Index.
Quando executamos a aplicação o Routing System (sistema de rotas) do ASP.NET MVC decidiu qual controller e action method executar. Não por acaso utilizei este controller e action method, esta é a configuração padrão de nosso aplicação, que está configurada no arquivo Global.asax.cs, como pode ser visto:

1
2
3
4
5
6
7
8
9
10

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
 
    routes.MapRoute(
        "Default",                                            // Route name
        "{controller}/{action}/{id}",                         // URL with parameters
        new { controller = "Home", action = "Index", id = "" }// Parameter defaults
    );
}

Em nosso Routing System, é definido a rota default com o controller Home e o action method Index sem passagem de parâmetro. Dessa forma as seguintes requisição serão manipuladas pela action Index no HomeController:

• /
• /Home
• /Home/Index

Renderizando Web Pages

Como já mensionado, na arquitetura MVC o Controller é responsável por manipular as requisições e as Views são componentes de interface do usuário. Assim não está correto em nossa aplicação o controller enviar a resposta (no nosso caso texto) para o browser. Em uma aplicação real o controller deve passar essa tarefa para uma View. Para isso vamos reescrever o método Index da seguinte forma:

1
2
3
4
5
6
7

public class HomeController : Controller
{
    public ViewResult Index()
    {
        return View();
    }
}

Dessa forma a action retorna um objeto do tipo ViewResult, passando para o Framework a instrução de renderizar uma View. O próximo passo é criar a View, para isso podemos clicar com o botão direito no action method Index e selecione Add View, isto irá criar um novo template para o action method em “~/Views/Home/Index.aspx”.
Altere o código HTML na tag body da seguinte forma:

1
2
3
4

<body>
    <h1>Hello, Word!</h1>
    <p>(renderizada apartir da View)</p>
</body>

Nossa aplicação está finalizada, execute para visualizar a página rendenrizada pela View.

Repare que não é necessário informar o nome da View que será chamada. O Framework renderiza a View que contém o mesmo nome do action method.

Há outros objetos de retorno que um Action Method pode retornar que instrui o framework diferentes fins. Esses tipos de retorno são chamados Action Results, mas isso será assunto para um próximo post, assim como a compreensão do M de Model de nossa arquitetura MVC.

Enjoy

Neste post irei mostrar como é facil criptografar e descriptografar dados utilizando o Enterprise Library.

Para o exemplo utilizei o Enterprise Library 4.1-October 2008. Que tem como pré requisitos, Framework.NET 3.5 e Visual Studio 2008. Para uma configuração inferior, utilize outras versões do Enterprise Library.

Devido a flexibilidade do Enterprise Library, as configurações são mantidas em uma arquivo XML (app.config, web.config ou um arquivo .xml a parte) na aplicação.
Ao instalar o Enterprise Library duas ferramentas de configuração são instaladas: uma embutida no Visual Studio (Configuration Editor), e uma aplicação externa (Enterprise Library Configuration Console). As alterações feitas no arquivo de configuração não obrigam a recompilação da aplicação, tornando assim fácil a reconfiguração da aplicação.

Configurando uma aplicação com Criptography Application Block

Para o exemplo, crie um projeto do tipo Console Application, de nome EntLibCriptography (pode ser qualquer nome).
Adicione as refenrencias para os assembly do bloco de aplicação Cryptography Application Block. Para isso, no Visual Studio clique com o botão direito sobre o no de projeto da Solution Explorer, e clique em Add References.
Clique em Browser e localize as dlls:

• Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.dll
• Microsoft.Practices.EnterpriseLibrary.Common.dll
• Microsoft.Practices.ObjectBuilder2.dll

Agora adicione ao projeto um arquivo Application Configuration File (App.config).
Clique com o botão direito sobre o arquivo App.config, e clique em Edit Enterprise Library Configuration.

O próximo passo é configurar o Cryptography Application Block no arquivo de configuração.
Para isso, clique com o botão direito sobre o App.config (no Enterprise Library Configuration e não no Solution Explorer), selecione New e clique em Cryptography Application Block.

Configurando Symmetric Algorithm Provider

Clique em Symmetric Providers, selecione New, e clique em Symmetric Algorithm Provider.

No Type Selector, selecione o tipo de symmetric algorithm provider, neste exemplo utilizaremos o RijndaelMananged, que é o tipo padrão.

Agora vamos gerar a chave de criptografia (o Cryptographic Key Wizard permite gerar ou importar uma chave existente).
O Cryptographic Key Wizard, apresentará as seguintes opções:

• Create a new key
• Use an existing DPAPI-protected key file
• Import a password-protected key file

Escolha “create a new key” e clique em Next.
No próximo passo, informamos nossa chave CHAVETESTE e clicamos em Generate para converter o texto em uma chave hexadecimal (pode ser informado uma chave hexadecimal diretamente).
Depois clique em Next.
Escolha um local para salvar o arquivo de chave, e clique em Next.
O próximo passo será configura o modo de acesso a chave, escolha Machine mode e clique em Finish.

Código de criptografia e decriptografia

Abaixo o código de ciframento e deciframento utilizando utilizando o tipo de criptografia Rijndael.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

using System;
using System.Text;
using Microsoft.Practices.EnterpriseLibrary.Security.Cryptography;
 
namespace EntLibCriptography
{
    public class Program
    {
        public static void Main(string[] args)
        {
            // Cifra mensagem
            string mensageEncrypted = Cryptographer.EncryptSymmetric("RijndaelManaged", "senha");
            Console.WriteLine("mensagem cifrada: {0}", mensageEncrypted);
 
            // Decifra mensagem
            string mensageDecrypted = Cryptographer.DecryptSymmetric("RijndaelManaged", mensageEncrypted);
            Console.WriteLine("mensagen decifrada: {0}", mensageDecrypted);
        }
    }
}

Resultado:

Enjoy

A Enterprise Library faz parte de um grupo da Microsoft conhecido como Patterns & Practices, e não é nativo do Framework.NET, não possui suporte, localização ou garantias de compatibilidade, porem pode ser baixado gratuitamente.

O Enterprise Library prove blocos de código com funcionalidades que seria necessário desenvolver em uma aplicação caso já não estivesse pronto. Com a vantagem de já terem sidas testadas pela Microsoft e outras empresas de diversos tipos de aplicação. Estes blocos de aplicação tem a função de auxiliar equipes de desenvolvimento, permitindo que se concentre nas regras de negócio do cliente evitando que percam tempo criando tarefas comuns a uma aplicações como registro de log, autorização de usuários, acesso a dados, criptografia e outros.

Os blocos de aplicação fornecidos pelo Enterprise Library são:

• Caching Application Block: possibilita a incorporação de cache local na aplicação.
• Cryptography Application Block: possilita a fácil implementação de criptografia simétrica ou de hash.
• Data Access Application Block: possibilita a implementação a funcionalidade de acesso ao banco de dados de forma padronizada e simplificada.
• Exception Handling Application Block: possilita criar uma estratégia consistente de tratamente de exceções entre as camadas de uma aplicação.
• Logging Application Block: possilita a criação de um procedimento padrão de registro de log na aplicação.
• Policy Injection Application Block: possibilita implementar politicas de interceptação de operações para implementar funcionalidades comuns como registro de log, uso de cache, tratamento de exceção, entre outros.
• Security Application Block: possibilita a incorporação de autenticação e cache de dados relacionados a segurança da aplicação.
• Validation Application Block: utilizado para criar regras de validação para objetos de negócio, podendo ser reutilizado em diversas camadas da aplicação.

A instalação do Enterprise Library fornece os seguintes itens:

• Arquivos Binários: inclui pre-compilado, strong-named assemblies para todos os códigos fontes.
• Código Fonte: inclui o código fonte para todos os blocos de aplicação, ferramenta de configuração, teste unitário, e o QuickStarts.
• Teste Unitário: inclui os teste unitários que foram criados enquanto os blocos de aplicação eram desenvolvidos.
• QuickStarts: aplicações de exemplo para o fácil entendimento das caracteristicas dos blocos de aplicação.
• Documentação: que pode ser visualizada como Visual Studio Help. A documentação inclui um guia sobre com utilizar o Enterprise Library e referência a biblioteca.

Abaixo um mapa de dependência entre os blocos de aplicação:

Até mais

1. Determinar quais objetos não mais será utilizado, ou seja, não estão mais acessíveis na aplicação;
2. Liberar os recursos (memória) utilizados por esses objetos

Entendendo o funcionamento do Garbage Collector

Basicamente o GC divide a memória disponível em 3 áreas distintas:

1. Maneged Heap
2. Pilha
3. Unmanaged Heap

O GC em conjunto com a CLR por meio de diversos algoritmos executa o gerenciamento da área de memória managed heap, que aloca reference types. Enquanto a pilha é utilizada para alocar value types. A unmanaged heap é utilizada para armazenar recursos não gerenciados de forma automática ou recursos nativos.
Mais detalhe da arquitetura do GC ficará para um próximo post, pois irá envolver alguns temas ainda não tratados.

Recursos Não Gerenciados

Um ponto importante é controle de recursos não gerenciados (recursos nativos, que pode ser um arquivo, janela, conexões de banco de dados, sockets, Win32, entre outros).
Implicitamente o Framework.NET mantém um controle das instâncias utilizadas pela aplicação, porem o mesmo não se repete para recursos não gerenciados. Para recursos não gerenciados deve-se fornecer uma maneira de liberar os recursos da memória depois que o aplicativo tiver terminado de usá-los, ou seja, deve ser um processo manual (codificado) executado pelo programador.
Há duas maneiras de se finalizar um recurso não gerenciado:

• Implicitamente utilizando o método Finalize();
• Explicitamente utilizando o método Dispose() do IDisposable;

Observação: Por padrão a Microsoft recomenda a implementar as duas formas de finalizar o objeto. Sendo que o método Finalize() serve de garantia de execução de liberação de memória impedindo que o recurso fique permanentemente vazando caso algum programador esqueça de chamar o método Dispose().

A primeira impressão que temos ao ver o finalizador (redefinindo ao método Finalize de System.Object) existente no .NET é que este atua como um destruidor (destructor) presente em linguagens com C/C++ é que são similares. Porem não se iluda pela aparência, pois são bem diferentes em suas características.

Caracteristicas do Finalizador:

• Execução nem sempre é não garantida;
• Execução não determinística (instante em que o método é executado não é conhecido);
• Chamada ao método ocorre desde que não existam ciclos infinitos;
• Quando chamado shutdown, sua execução só ocorre caso seu tempo de execução não seja superior a 2 segundos e o somatório não exceda 40 segundos (tempos aproximados);

Em resumo o CLR não garante a ordem de chamada dos métodos Finalize().

Exemplo de implementação do finalize:

Código C#.NET:

1
2
3
4
5
6
7
8
9

public class AlgumaClasse
{
   …
   ~AlgumaClasse() // finalizador
   {
      // código de limpeza
   }
   …
}

Codigo gerado pelo compilador:

1
2
3
4
5
6
7
8
9
10

public class AlgumaClasse
{
   …
   protected override void Finalize()
   {
      try { /* código de limpeza */ }
      finally { base.Finalize(); }
   }
   …
}

O método Dispose é uma implementação de um padrão conhecido como “padrão de descarte” e impõe uma ordem na vida de um objeto.
O método Dispose() deve liberar os recursos que ele possui assim como os recursos de propriedade de seus tipos base. Esse processo é executado através de uma hierarquia de tipos de base, ou seja, cada objeto irá chamar o método Dispose() da classe estendida ou implementada. Garantindo assim que os recursos são sempre limpos adequadamente.
Um característica particular do método Dispose() é que este pode ser chamado várias vezes sem lançar exceção.
É importante salientar que não há benefícios de desempenho na utilização do método Dispose() a objetos gerenciados pela CLR (tais como Arrays). Este método deve ser utilizado em objetos que utilizam recursos nativos e objetos COM que são expostas ao Framework.NET, como exemplo podemos citar a classe FileStream que implementa a interface IDisposable.

Exemplo de implementação do métiodo Dispose():

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

// Design pattern para uma classe base.
public class Base: IDisposable
{
   //Implementação da interface IDisposable.
   public void Dispose() 
   {
     Dispose(true);
      GC.SuppressFinalize(this); 
   }
 
   protected virtual void Dispose(bool disposing) 
   {
      if (disposing) 
      {
         // libera outros estados (managed objects).
      }
      // Libera sus próprios estados(unmanaged objects).
      // Define campos grandes como null.
   }
 
   // Sintaxe para finalização do código.
   ~Base()
   {
      //Chamada simples Dispose(false).
      Dispose (false);
   }
}
// Design pattern para a classe derived.
public class Derived: Base
{   
   protected override void Dispose(bool disposing) 
   {
      if (disposing) 
      {
         // Liberação de recursos gerenciados
      }
      // Liberação de recusos não gerenciados.
      // Define campos grandes como null.
      // Chama Dispose da classe base.
      base.Dispose(disposing);
   }
   // A classe derived não tem o método Finalize
   // ou um método Dispose com parametro pois herda da classe base.
}

Enjoy

Primeiramente vamos conceiturar o que é socket, ou soquete em portugues. De uma visão geral um soquete pode ser definido como uma tomada que designa uma cavidade ou região usada para ligar algum artifício específico.

No mundo da computação, um socket é o elo de ligação entre os processos do servidor e do cliente. Ele é a “porta” na qual os processos enviam e recebem mensagens. De acordo com JAMES F KUROSE: “socket é a interface entre a camada de aplicação e a de transporte dentro de uma máquina”. Para quem não lembra, ou não sabe, camada de aplicação e transporte fazem parte do modelo OSI.
Através de um socket podemos estabelecer a comunicação entre máquinas possibilitando o envio e recebimento de dados.

A interface padronizada de sockets surgiu originalmente no sistema operacional Unix BSD (Berkeley Software Distribution). Tinha a função de suporte a comunicação em rede. Esta interface é a base para a maioria das interfaces entre protocolos de internet TCP/IP existente.

A identificação de um socket na rede é realizada por um IP e um porta. Comumente utiliza-se portas acima de 1000 pois as inferiores são utilizadas pelo sistema operacional. Sua comunicação é realizada pelos protocolos UDP ou TCP. Assim, é possível termos tanto comunicação orientada a conexão (via TCP), quanta não orientada a conexão (via UDP). O socket abstrai esse conceito, permitindo assim a utilização de qualquer um dos meios.

No C# para se trabalhar com sockets os recursos enconstram-se no namespace System.Net.Sockets.

Implementando uma aplicação com socket

Este é um simples código de uma aplicação Client/Server utilizando socket.
Abaixo o passo a passo de criação da aplicação:

Server App

1. Criar um projeto do tipo WindowsForm com o nome CommunicationSocket.
2. Incluir um botão que será utilizado para enviar mensagem do servidor para o cliente.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

using System;
using System.IO;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using System.Windows.Forms;
 
namespace CommunicationSocket
{
    public partial class ServerApp : Form
    {
        private Socket socket;
        private Thread thread;
 
        private NetworkStream networkStream;
        private BinaryWriter binaryWriter;
        private BinaryReader binaryReader;
 
        public ServerApp()
        {
            InitializeComponent();
            thread = new Thread(new ThreadStart(RunServer));
            thread.Start();
        }
 
        public void RunServer()
        {
            TcpListener tcpListener;
            try
            {
                IPEndPoint ipEndPoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 2001);
                tcpListener = new TcpListener(ipEndPoint);
                tcpListener.Start();
 
                MessageBox.Show("Servidor habilitado e escutando porta...", "Server App");
 
                socket = tcpListener.AcceptSocket();
                networkStream = new NetworkStream(socket);
                binaryWriter = new BinaryWriter(networkStream);
                binaryReader = new BinaryReader(networkStream);
 
                MessageBox.Show("conexão recebida!", "Server App");
                binaryWriter.Write("\nconexão efetuada!");
 
                string messageReceived = "";
                do 
                {
                    messageReceived = binaryReader.ReadString();
                    MessageBox.Show("Mensagem: " + messageReceived, "Server App");
 
                } while (socket.Connected);
            } 
            catch (Exception ex) 
            {
                MessageBox.Show(ex.Message);
            } 
            finally 
            {
                binaryReader.Close();
                binaryWriter.Close();
                networkStream.Close();
                socket.Close();
 
                MessageBox.Show("conexão finalizada", "Server App");
            }
        }
 
        private void btnSendMsg_Click(object sender, EventArgs e)
        {
            try
            {
                binaryWriter.Write("Server respondendo: Houston, we have a problem!!!");
            }
            catch (SocketException socketEx)
            {
                MessageBox.Show(socketEx.Message, "Erro");
            }
        }
    }
}

Client App

1. Criar um projeto do tipo WindowsForm com o nome ClientApp.
2. Incluir botão que será utilizado para enviar mensagem do cliente para o servidor.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

using System;
using System.IO;
using System.Net.Sockets;
using System.Threading;
using System.Windows.Forms;
 
namespace ClientApplication 
{
    public partial class ClientAppForm : Form 
    {
        private NetworkStream networkStream;
        private BinaryWriter binaryWriter;
        private BinaryReader binaryReader;
        private TcpClient tcpClient;
 
        private Thread thread;
 
        public ClientAppForm() 
        {
            InitializeComponent();
            thread = new Thread(new ThreadStart(RunClient));
            thread.Start();
        }
 
        public void RunClient() 
        {
            try 
            {
                tcpClient = new TcpClient();
                tcpClient.Connect("127.0.0.1", 2001);
 
                networkStream = tcpClient.GetStream();
                binaryWriter = new BinaryWriter(networkStream);
                binaryReader = new BinaryReader(networkStream);
 
                String message = "";
                do 
                {
                    try 
                    {
                        message = binaryReader.ReadString();
                        MessageBox.Show(message, "Mensagem Recebida");
                    } 
                    catch (Exception ex) 
                    {
                        MessageBox.Show(ex.Message, "Erro");
                        message = "FIM";
                    }
                } while (message != "FIM");
 
                binaryWriter.Close();
                binaryReader.Close();
                networkStream.Close();
                tcpClient.Close();
            } 
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message, "Erro");
            }
        }
 
        private void btnSendMsg_Click(object sender, EventArgs e) 
        {
            try 
            {
                binaryWriter.Write("Mensagem do cliente");
            } 
            catch (SocketException socketEx) 
            {
                MessageBox.Show(socketEx.Message, "Erro");
            }
        }
    }
}

Para realizar a comunicação o Servidor utiliza o objeto TcpListener que fica escutando toda requisição no IP “127.0.0.1″ porta 2001.
Na aplicação Cliente o objeto TcpClient é informado sobre o IP (ou DNS) e porta do servidor que irá se conectar. Após esse a realização toda a comunicação é feita por meio de stream através do objeto NetworkStream.

Repare que tanto Servidor quanto o Cliente trabalha com processamento em paralelo (Thread) para evitar que a aplicação fique travada até o término do processamento, ou para manter um processamento dedicado e contínuo que é o caso do servidor.

Nesse exemplo utilizei MessageBox para apresentar as mensagens, pois para inseri-las em um TextBox no Form é necessário utilizar delegates e reflections, senão teremos um erro de cruzamento de Threads (Cross-thread operation not valid).
Mas isso acho que é assunto para o nosso próximo post.

Até mais

1
2
3
4
5
6
7
8
9
10
11
12
13
14

using System.Text.RegularExpressions; 
namespace ExtensionMethodsExample
{
    public class Util
    {
        /// <summary>Verifica se o argumento do tipo string é um numérico</summary>
        /// <param name="arg">argumento a ser validado</param>
        /// <returns>True - se for numérico</returns>
        public bool IsNumeric(string arg)
        {
            return Regex.IsMatch(arg, @"^\d+$");
        }
    }
}

Com o uso do Extension Methods podemos inserir o método que verifica se a variável é numérica no próprio tipo string.
Abaixo um exemplo de seu uso, e depois vou explicar como o extension methods é declarado.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

using System;
using System.Text.RegularExpressions;
 
namespace ExtensionMethodsExample
{
    public static class Extensions
    {
        public static bool IsNumeric(this string arg)
        {
             return Regex.IsMatch(arg, @"^\d+$");
        }
    }
} 
 
public class Program
{
    public static void Main(string[] args)
    {
        string codigo1 = "1234";
        string codigo2 = "ABCD";
 
        Imprime(codigo1);
        Imprime(codigo2);
    }
 
    private static void Imprime(string codigo)
    {
        if (codigo.IsNumeric())
        {
            Console.WriteLine("Codigo numerico: {0}", codigo);
        }
        else
        {
            Console.WriteLine("Codigo alphanumerico: {0}", codigo);
        }
    }
}

Para criarmos um extension methods precisamos de uma classe e método estático. Todo método extension sempre terá seu primeiro parâmetro a palavra reservada this, seguido do tipo ao qual o método será inserido, no exemplo o tipo string. Esse parâmetro representa a própria instância do objeto. Para os parâmetros subseqüentes serão utilizados na chamada do método. O nome da classe é de livre escolha, ela não interfere na implementação do extension methods, a única ressalva é que seja uma classe estática.

Compare a diferença da verificação de condição utilizando a classe Util e o extension methods

1
2
3
4
5

Util util = new Util();
if (util.IsNumeric(codigo))
{
    // faz algo
}

e

1
2
3
4

if (codigo.IsNumeric())
{
    // faz algo
}

O código torna-se mais legível e mais implícito seus métodos, tornando a linguagem muito mais dinâmica.
Enjoy