Uma operação muito comum é a cópia de streams. Há diversas situações onde você pode querer usar isso, como por exemplo, armazenar um conteúdo de um arquivo em memória, para não precisar acessar o arquivo físico toda vez que precisar dele. Antes do .NET Framework 4.0, com o stream de origem em mãos, precisávamos armazenar os blocos em um buffer temporário, e em seguida, copiar para o stream de destino.

Apesar de não ser uma tarefa muito difícil de fazer, ela é propícia a erros, já que você precisa ficar manipulando índices para invocar os métodos Read e Write. Com o .NET Framework 4.0, a Microsoft acaba de adicionar um método (de instância) chamado CopyTo na classe Stream. Com ele, todas as classes que derivam direta ou indiretamente dela, poderão copiar o conteúdo atual para um outro Stream. Tudo o que precisamos fazer é:

MemoryStream ms = new MemoryStream();

using (FileStream fs = File.Open("Arquivo.xml", FileMode.Open)
    fs.CopyTo(ms);

Até antes do .NET Framework 4.0, você possui um método estático chamado Combine, exposto pela classe Path. Dado duas strings para este método, ele retorna uma nova string contendo a combinação desses dois paths, colocando ou removendo barras quando necessário. Isso ajuda bastante, já que não precisamos ficar lidando com a string diretamente, verificando se existe ou não as barras para efetuar a concatenação.

Provavelmente você já deve ter se deparado com a situação onde você tem o path separado em mais partes. Com isso, o problema volta a acontecer, pois o método Combine não permite informarmos mais do que duas strings. A versão 4.0 do .NET Framework, a Microsoft adicionou uma nova versão (overload) deste método, que permite informarmos o path através de um paramarray, e com isso, podemos colocar quantas strings quisermos, que ele fará todo o trabalho necessário, e nos devolverá o resultado esperado. Veja o exemplo abaixo:

Console.Write(new StreamReader(Path.Combine("d:\Arquivos", "Logs", "Cobranca", "2009.log")).ReadToEnd());

Eventualmente, se você informar uma string vazia, ele automaticamente omitirá do resultado final. Além disso, a primeira string passada para este método, deverá sempre representar o path absoluto ("d:\" ou "\\arquivos"). Se ele encontrar qualquer outro path absoluto no meio, a operação será reiniciada, e todos os paths anteriores serão descartados.

Grande parte das aplicações Web, independentemente de qual tecnologia ela foi criada, tem a necessidade de manter informações por um determinado tempo. Essas informações, na maioria das vezes, refletem alguma configuração definida pelo cliente, que customiza alguma seção do aplicativo, e quer manter isso em algum local para não precisar refazê-la mais tarde.

Quando estamos falando em uma aplicação desenvolvida em ASP.NET, você utiliza algumas funcionalidades definidas pela tecnologia, tais como Session, Caching, Profile, ViewState ou Cookies, para atingir esse objetivo. A escolha entre qual utilizar, vai depender do escopo, performance e nível de segurança. Esses detalhes devem ser cuidadosamente analisados, tentando equilibrar cada um dos pontos mencionados.

Aplicações construídas em Silverlight também tem a mesma necessidade, precisando, de alguma forma, armazenar informações para serem utilizadas posteriormente. Como sabemos, o Silverlight possui uma versão do .NET Framework exclusiva, trazendo várias APIs para o gerenciamento de estado. Como o aplicativo desenvolvido em Silverlight está rodando no navegador, você não tem acesso à variáveis de sessão, Caching ou Profile, já que estão acessíveis apenas pelo ASP.NET e do lado do servidor. Devido a isso, a Microsoft disponibilizou no Silverlight o Isolated Storage. Esse recurso não é exclusidade do Silverlight, e já está disponível no .NET Framework desde a sua primeira versão, e foi reescrito para o Silverlight, ganhando alguns novos conceitos.

Com o Isolated Storage podemos montar uma estrutura de arquivos para a aplicação, armazenando qualquer tipo de informação, desde um simples arquivo texto até um arquivo mais complexo (como a serialização de um objeto em formato binário/Xml). Do ponto de vista do desenvolvedor, temos uma estrutura para armazenamento das informações bem próximo ao que é o sistema de arquivos. O Isolated Storage é como os cookies (armazenar do lado do cliente), mas ao invés de armazenar somente chave/valor (strings), é um sistema de arquivos virtual, dando muito mais flexibilidade e segurança.

Apesar de uma aplicação Silverlight também ser acessada e executada através de um navegador, ela diferente bastante de uma aplicação Web tradicional. Ao contrário dessas aplicações tradicionais, que são executadas no servidor e apenas o HTML correspondente é enviado ao cliente, aplicações Silverlight são consideradas parcialmente confiáveis, e rodam dentro do navegador em um ambiente conhecido como “sandboxing”, que protegem o computador do cliente de aplicações maliciosas, evitando que aplicações Silverlight acessem recursos da máquina, compromentendo-a.

Antes de trabalharmos com o Isolated Storage, precisamos conhecer como funciona o nível de isolamento que ele fornece. O isolamento permitirá definirmos o escopo de acesso de uma determinada informação. O Silverlight possui dois níveis de isolamento: usuário + aplicação ou usuário + site. O primeiro deles irá isolar as informações pelo usuário dentro da aplicação (XAP), estando acessíveis somente a partir da mesma. Já a segunda opção, irá isolar as informações pelo usuário dentro do site, e todas as aplicações Silverlight que estão acessíveis a partir do mesmo site (domínio), irão compartilhar a informação de acordo com o usuário. É importante ficar claro que cada usuário tem dois locais de armazenamento, sendo um deles exclusivo para uma determinada aplicação, enquanto o outro pode ser acessado de qualquer aplicação, desde que esteja dentro daquele mesmo site.

O local de armazenamento e leitura dos arquivos estão condicionados ao usuário que está acessando a aplicação. Isso quer dizer que o Silverlight somente poderá acessar (para leitura ou gravação) o diretório local, que estará localizado debaixo do perfil do usuário atual. Esse caminho poderá variar de acordo com o sistema operacional, onde no Windows Vista está em C:\Users\<Usuario>\AppData\LocaLow\Microsoft\Silverlight\is e no Windows XP em C:\Docuemnts and Settings\<Usuario>\Local Settings\Application Data\Microsoft\Silverlight\is. É importante dizer que você não precisa se preocupar com o endereço, pois ao utilizar o Isolated Storage, ele se encarregará de salvar ou ler as informações do local correto, não permitindo que uma aplicação maliciosa acesse, de forma arbitrária, o sistema de arquivos da máquina cliente, comprometendo a segurança.

Depois da parte teórica, vamos analisar a API que temos disponível para manipular o Isolated Storage. Basicamente temos quatro classes a nossa disposição, estando todas elas debaixo do namespace System.IO.IsolatedStorage, mas separadas em dois assemblies diferentes, sendo o mscorlib.dll e o System.Windows.dll.

A primeira classe que temos é a IsolatedStorageFile. A finalidade desta classe é representar uma das areas disponíveis no Isolated Storage para um determinado usuário, abstraindo o sistema de arquivos virtual que ele nos fornece. Essa classe não pode ser instanciada diretamente; ao invés disso, ela possui dois métodos estáticos chamados GetUserStoreForApplication e GetUserStoreForSite, quais retornam instâncias da mesma, com as respectivas áreas de armazenamento. A partir da instância desta classe, podemos criar, excluir ou enumerar diretórios e arquivos. Para efetuar essas tarefas, essa classe fornece métodos autoexplicativos, tais como: CreateDirectory, DeleteDirectory, GetFilesNames, GetDirectoryNames, DeleteFile e CreateFile.

Os métodos para recuperar arquivos ou diretórios pode, opcionalmente, receber uma string, representando um critério de busca, especificando um subdiretório, ou até mesmo utilizar o caracter “*”, para refinar ainda mais a busca. O método CreateFile cria o arquivo desejado e retorna uma instância da classe IsolatedStorageFileStream, representando o arquivo recém-criado, para que você consiga gravar ou ler as informações do mesmo. O exemplo abaixo ilustra como proceder para criar e ler um arquivo dentro do repositório de uma aplicação específica:

//Criando o Arquivo
using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication())
    using (IsolatedStorageFileStream stream = store.CreateFile(“Teste.txt”))
        using (StreamWriter sw = new StreamWriter(stream))
            sw.WriteLine(“Teste”);

//Lendo o Arquivo
using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication())
    using (IsolatedStorageFileStream stream = new IsolatedStorageFileStream(“Teste.txt”, FileMode.Open, store))
        using (StreamReader sr = new StreamReader(stream))
            MessageBox.Show(sr.ReadToEnd());

Observação: Os exemplos acima não estão contemplando o tratamento de erros. Todas as operações que se faz com o Isolated Storage, você deve envolver em um bloco try/catch, monitorando por possíveis exceções do tipo IsolatedStorageException. Um cenário onde ela pode ser lançada, é quando o usuário desabilita o acesso ao Isolated Storage ou atinge a cota máxima.

Cotas

Imagine que uma determinada aplicação possui um código malicioso, que cria arquivos sem nenhum controle. Em breve, não haverá mais espaço disponível no disco do cliente, que foi todo tomado pela aplicação. Felizmente o Isolated Storage disponibiliza o conceito de cotas. As cotas são um recurso bastante interessante, garantindo que a quantidade de informações geradas pela aplicação não ultrapasse um limite imposto pelo Silverlight. O Silverlight utiliza o conceito de grupos para gerenciar as cotas. Com isso, aplicações oriundas de um mesmo site, compartilham a mesma cota.

Por padrão temos 1MB de espaço disponível para cada grupo. Com uma aplicação Silverlight rodando no navegador, ao clicar com o botão direito, você tem a opção Silverlight Configuration. Ao abrir a janela, haverá uma aba chamada Application Storage. Lá temos a relação dos sites que estão fazendo uso deste recurso, exibindo o tamanho atual e o máximo permitido. Essa tela de configuração ainda permite você gerenciar o Isolated Storage, como excluí-los ou até mesmo desabilitá-lo. A imagem abaixo exibe essas configurações:

A partir da instância da classe IsolatedStorageFile temos acesso à alguns membros, que permitem manipular as cotas. O primeiro deles é a propriedade AvailableFreeSpace, que como o próprio nome diz, retorna a quantidade de espaço disponível para aquela “store”. Ainda temos a propriedade Quota, que representa a quantidade máxima permitida para aquela “store”.

A idéia do Isolated Storage é armazenar poucas informações, e justamente por isso, que 1MB é um valor razoável. Mas e se precisarmos de um tamanho maior para armazenar as informações que estão sendo geradas pelas aplicações? É neste momento que entra em cena o método IncreateQuotaTo. Este método recebe como parâmetro a nova cota, retornando um valor boleano indicando se a alteração foi ou não realizada com sucesso. Isso se deve ao fato de que somente podemos aumentar a capacidade de armazenamento do Isolated Storage, com o consentimento do usuário. Ao chamar esse método, uma mensagem aparece na aplicação (como mostrado na figura abaixo), informando o usuário se ele permite ou não esse crescimento.

O código abaixo ilustra como podemos proceder para efetuar o aumento da capacidade do Isolated Storage para 10MB, utilizando os membros que vimos acima:

int space = 1024 * 1024 * 10;

using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication())
    if (store.AvailableFreeSpace < space)
        if (store.IncreaseQuotaTo(space))
            MessageBox.Show("Cota aumentada com sucesso.");

Persistindo Objetos

Em algumas situações podemos querer armazenar instâncias de classes que a aplicação manipula, para mais tarde recuperá-las e dar prosseguimento ao que usuário estava fazendo, evitando que ele refaça essas tarefas. Para atingir esse objetivo, basta serializarmos o objeto em formato binário ou Xml com os formatadores que já conhecemos, em conjunto com o Stream gerado pelo Isolated Storage.

Como isso será uma tarefa comum, a Microsoft facilitou a vida dos desenvolvedores, criando uma classe chamada de IsolatedStorageSettings (a única que está contida no Assembly System.Windows.dll). Essa classe nada mais é do que um dicionário de dados, onde a chave é do tipo string e o valor do tipo object, ou seja, podemos armazenar a instância de qualquer objeto do .NET (desde que ele seja serializável).

Essa classe não pode ser instanciada diretamente pela aplicação. Ao invés disso, você captura as instâncias predefinidas a partir de duas propriedades estáticas que ela mesma fornece: ApplicationSettings e SiteSettings. Escolher qual delas usar, irá depender do nível de compartilhamento das informações que você desejar, assim como já vimos acima.

Para manipular esse dicionário, podemos utilizar os conhecidos métodos Add e o indexer, que dado um chave retorna o respectivo valor. Se informar uma chave inexistente para o indexer, uma exceção será disparada. Para evitar isso, essa mesma classe fornece um método chamado TryGetValue, que dado a chave e um parâmetro de saída representando o valor correspondente, retorna um valor boleano indicando se foi ou não possível recuperar o valor. Esse procedimento é mostrado através do código a seguir:

IsolatedStorageSettings store = IsolatedStorageSettings.ApplicationSettings;
store.Add("Cliente", new Cliente() { Email = "ia@israelaece.com", Nome = "Israel Aece" });

Cliente cliente = null;

if (store.TryGetValue<Cliente>("Cliente", out cliente))
    MessageBox.Show(cliente.Nome);

Conclusão: Vimos no decorrer deste artigo os benefícios e facilidades que temos ao trabalhar com ele, mas devemos levar em consideração que essas informações ficam armazenadas no disco, e alguém pode encontrar os arquivos gerados e manipulá-los, comprometendo a aplicação. Justamente por isso, nunca armazene informações sensíveis dentro dele, ou de qualquer arquivo no disco, a menos que esteja devidamente protegido.

PersistenciaDeDadosEmSL.zip (63.76 kb)

Algumas classes que estão contidas no namespace System.IO trabalham com arrays de strings. Para citar alguns exemplos, temos as classes Directory e DirectoryInfo, que fornecem dois métodos chamados GetDirectories e GetFiles. Ambos os métodos retornam um array de strings, representando os sub-diretórios ou os arquivos que constam dentro de um determinado diretório.

Além disso, temos também a classe estática File, que possui os métodos ReadAllLines e WriteAllLines, utilizados para ler e escrever linhas em um arquivo, respectivamente. O primeiro método retorna um array de strings, e o segundo recebe também um array de strings.

Para os métodos que retornam array de strings, é necessário criar, alocar a memória e, finalmente, preenchê-lo. Somente depois de todo esse processo, é que iremos conseguir acessar os elementos. Em cenários onde você tem poucos arquivos/sub-diretórios, você não deverá ter maiores problemas com performance. E enquanto estiver manipulando arquivos pequenos, você também não notará um baixo desempenho, causado pelo overhead dos arrays.

A performance começa a ser degradada a partir do momento que você está extraindo informações a partir de um diretório (local ou remoto), com muitos objetos. Já no caso da manipulação do conteúdo do arquivo, podemos sofrer quando há muitas informações a serem lidas e/ou escritas. Visando amenizar esses problemas, a Microsoft inseriu novos métodos na BCL do .NET 4.0.

Agora as classes Directory e DirectoryInfo passam a ter dois novos métodos EnumerateDirectories e EnumerateFiles, que ao invés de trabalhar com arrays de strings como os métodos citados acima, passam a retornar classes que implementam a interface IEnumerable<string>. Já no caso dos métodos ReadAllLines e WriteAllLines, apenas um novo overload foi criado para suportar também o IEnumerable<string>. Todos esses métodos removem a necessidade de criar e alocar um array potencialmente grande, trabalhando sob demanda, e permitindo o acesso imediato, sem a necessidade de aguardar que o array seja criado, carregado e retornado.

Há algum tempo escrevi um artigo sobre transferencia e codificação de dados no WCF. Quando optamos por utilizar o modelo streaming, há um cuidado extra que devemos tomar para efetuar o fechamento dele. Neste cenário sempre há o desafio de saber quando e quem fecha o stream e que foram abordadas no artigo mecionado acima.

Quando alguém envia um stream para o outro lado, este deverá permanecer aberto até que a transferencia seja concluída. Não temos problemas quando o stream é passado diretamente com parametro ou como retorno de uma operação. O problema começa a acontecer quando voce altera a mensagem para que, além do stream, informe dados adicionais, como é mostrado no artigo e ressalto aqui:

[MessageContract]
public class StreamData
{
    [MessageHeader]
    public string NomeDoArquivo;

    [MessageHeader]
    public int Tamanho;

    [MessageBodyMember]
    public Stream Conteudo;
}

Ao retornar esse objeto, o stream relacionado a ele ficará aberto, causando problemas futuros. O WCF possui uma propriedade chamada AutoDisposeParameters, que está acessível através do atributo OperationBehaviorAttribute. Essa propriedade que, por padrão é True, diz ao runtime do WCF para invocar o método Dispose de todos os parametros (input e output) e dos objetos de retorno que implementam a Interface IDisposable e, a partir de agora, conseguimos entender porque quando lidamos com a classe Stream diretamente (ou uma de suas derivadas), o stream é devidamente fechado.

Como já deve suspeitar, o que nos resta fazer é também implementar a Interface IDisposable na classe StreamData e, dentro do método Dispose, invocar o método Dispose dos membros internos, garantindo assim, que o arquivo que está sendo utilizado por essa classe, seja fechado quando o método retornar.

[MessageContract]
public class StreamData : IDisposable
{
    [MessageHeader]
    public string NomeDoArquivo;

    [MessageHeader]
    public int Tamanho;

    [MessageBodyMember]
    public Stream Conteudo;

    public void Dispose()
    {
        if (this.Conteudo != null)
            this.Conteudo.Dispose();
    }
}

A versão 3.0 do .NET Framework temos um namespace chamado System.IO.Log, qual traz uma série de classes para manipular um log de informações, utilizando o sistema de arquivos como repositório, mas baseando-se em registros. Isso permite catalogar e ler as informações como se elas fossem itens, ao invés de ficar manipulando linhas, strings, etc., como acontece atualmente.

Para fazer o uso dessas classes, é necessário adicionar a referencia para o assembly System.IO.Log.dll que está dentro do seguinte diretório: %ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\.

Como já era de se esperar, tudo o que for catalogado deverá ser convertido em um array de bytes. Já durante a leitura, o retorno será através de um Stream, que também deverá ser carregado para um array de bytes. O exemplo abaixo exibe como proceder para armazenar dados e também para ler o conteúdo do mesmo arquivo:

using (FileRecordSequence f = new FileRecordSequence("Teste.log"))
{
    f.Append(
        new ArraySegment<byte>(Encoding.Default.GetBytes("Mensagem para logar")),
        SequenceNumber.Invalid,
        SequenceNumber.Invalid,
        RecordAppendOptions.ForceFlush);
}

using (FileRecordSequence f = new FileRecordSequence("Teste.log"))
{
    foreach (LogRecord r in f.ReadLogRecords(f.BaseSequenceNumber, LogRecordEnumeratorType.Next))
    {
        int length = (int)r.Data.Length;

        byte[] data = new byte[length];
        r.Data.Read(data, 0, length);
        Console.WriteLine(Encoding.Default.GetString(data));
    }
}

Note que para cada append, haverá uma instancia da classe LogRecord que representará o registro corrente. A classe FileRecordSequence, responsável por grande parte do processo, também traz suporte ao processamento assíncrono, com os métodos BeginAppend e EndAppend.

Por curiosidade, abri o .NET Reflector com o .NET Framework 4.0 e comecei a explorar as classes que ele disponibiliza e, logo percebi um novo namespace: System.IO.MemoryMappedFiles. Dentro deste namespace, entre as poucas classes, temos a classe MemoryMappedFile. É importante dizer que é uma versão CTP, sem a garantia de que isso prevalecerá na versão final.

A finalidade dela é mapear um espaço da memória para o conteúdo de um determinado arquivo (ou algum outro recurso), criando um objeto que servirá de "ponte" entre a aplicação e o arquivo físico, criandos "views" deste arquivo e, como principal benefício, permitirá acessar "seções" do arquivo, sem carregá-lo completamente para a memória. Abaixo um exemplo simples que faz a utilização desta classe:

using System.IO;
using System.IO.MemoryMappedFiles

using (MemoryMappedFile mmf = 
    MemoryMappedFile.CreateFromFile(new FileStream("C:\Teste.txt", FileMode.Open)))
{
    byte[] buffer = new byte[5];
    mmf.CreateViewStream(120, 5).Read(buffer, 0, 5);
    Console.WriteLine(Encoding.Default.GetString(buffer));
}

O primeiro parametro do método CreateViewStream é a posição inicial dentro do arquivo e, o segundo, a quantidade de caracteres que voce quer extrair.

A Base Classe Library (também conhecida como BCL) é um conjunto de classes que o .NET disponibiliza para todas as linguagens que rodam sob o .NET Framework. Essa base encapsula várias funcionalidades que tornam o trabalho dos desenvolvedores muito mais fácil. As classes contidas dentro da BCL é comum para qualquer tipo de aplicação, ou seja, independentemente de tecnologia (ASP.NET, Windows Forns, WPF, etc.), você poderá consumir essas classes que, representam tarefas que são comumente utilizadas. A imagem abaixo exibe onde a BCL está encaixada dentro da plataforma .NET.

A versão 2.0 adicionou novas tipos e namespaces, enriquecendo ainda mais esta estrutura. Essas classes vão desde novas coleções (tipadas) até novos namespaces, como é o caso do System.Transactions. Apesar do .NET Framework estar em sua versão 3.5, ele utiliza o .NET 2.0 como seu núcleo. A figura abaixo ilustra perfeitamente a posição do .NET 2.0 dentro do .NET 3.X.

A BCL é composta por vários namespaces e, através dos capítulos abaixo, veremos detalhadamente cada um dos principais deles. A idéia é abordar o conteúdo mais útil ao dia-à-dia, mostrando exemplos em Visual Basic .NET e Visual C#. Sendo assim, nem todas as classes/funcionalidades serão cobertas aqui mas, para isso, poderá recorrer ao MSDN Library.

ATENÇÃO: Os arquivos estão em formato XPS. Caso não tenha o visualizador, você poderá baixá-lo aqui.

Conteúdo

• Capítulo 1 – Tipos de dados e Interfaces Este capítulo abordará a arquitetura de tipos fornecido pelo .NET Framework, onde na primeira parte do capítulo, será abordado os tipos padrões padrões e veremos como identificar se trata-se de um tipo valor ou referência. Além disso, analisaremos um problema grave, deixado de lado por muitos desenvolvedores, que é a questão do boxing e unboxing. Ainda nessa primeira parte, analisaremos alguns novos tipos introduzidos nesta versão do .NET Framework, em principal, os Generics. Na segunda e última parte do mesmo, vamos abordar as várias Interfaces que estão disponíveis para serem implementados em tipos customizados, fornecendo funcionalidades adicionais ao tipo criado.

• Capítulo 2 – Trabalhando com Coleções As coleções são componentes importantes em qualquer tipo de aplicação e, para isso, esse capítulo abordará extensamente o uso das mesmas, começando pelas coleções primárias, fornecidas desde as primeiras versões do .NET Framework até as novas coleções, introduzidas na versão 2.0 do .NET Framework, quais fazem uso dos Generics. Além das coleções, analisaremos as Interfaces disponíveis para podermos estender as funcionalidades existentes e customizarmos para o nosso cenário.

• Capítulo 3 – Utilização de Assemblies Um Assembly é a menor unidade de reutilização, segurança e controle de versão. O Assembly é algo importante que deve ser analisado cuidadosamente, pois toda aplicação .NET depois de compilada gerará um Assembly. Este capítulo abordará a sua criação desde um utilitário de linha de comando até o Visual Studio .NET. Além disso, abordaremos também outros assuntos relacionados a Assemblies, como por exemplo, strong names, GAC (Global Assembly Cache), instaladores e arquivos de configuração.

• Capítulo 4 – Monitoramento e depuração de aplicações Toda e qualquer aplicação necessita de algum tipo de monitoramento de seu código para detectar possíveis problemas que possam acontecer e que devem ser analisados. O .NET Framework fornece várias classes que ajudam nesse monitoramento e, este capítulo, é responsável por apresentar essas classes que vão desde a manipulação do Event Log do Windows até classes que interagem com o WMI - Windows Management Instrumentation.

• Capítulo 5 – Manipulando o sistema de arquivos Grande parte das aplicações comerciais que temos atualmente manipulam arquivos. Esses arquivos são arquivos de bancos, arquivos de parceiros e fornecedores que servem para troca de informações. Enquanto os XML Web Services ainda não são uma realidade para muitas empresas, a manipulação de arquivos e seus respectivos conteúdos é ainda muito utilizado. Tendo esse cenário, o capítulo em questão abordará as principais classes contidas dentro do namespace System.IO para exemplificar e facilitar a manipulação de arquivos do disco e streams de dados.

• Capítulo 6 – Serialização A serialização de dados é cada dia mais utilizada em aplicações. Por mais que isso aconteça nos bastidores, esse capítulo abordará desde o seu conceito até como implementá-la; e ainda, em seus diversos formatos, utilizando as classes fornecidas pelo .NET Framework 2.0. Além disso, analisaremos classes e Interfaces que temos disponíveis, que proporcionaram o processo de serialização e deserialização mais flexível, onde podemos customizar e interceptar cada um desses processos de acordo com a nossa necessidade.

• Capítulo 7 – Globalização de Aplicações Cada vez mais se desenvolve softwares que podem ser acessados por várias pessoas de diferentes idiomas e de diferentes locais do mundo. Tendo esse cenário, é importante que a aplicação que estamos desenvolvendo seja possível ao usuário poder customizar o idioma que deseja visualizar os dados e ainda, poder criar a aplicação independente de qualquer cultura. Essa capítulo tem justamente essa finalidade, ou seja, de exibir o que o .NET Framework é capaz de fazer para atender essa necessidade que, torna-se cada vez mais comum.

• Capítulo 8 – Criptografia Criptografia de dados é um ponto muito importante nos mais diversos tipos de aplicações. Geralmente, em aplicações onde alguns dos dados são muito sigilosos, como é o caso de aplicações financeiras, quais mantém os dados de seus clientes, é necessário que se mantenha esses dados seguros pois, se esses dados cairem em mãos erradas, essas pessoas com más intenções, não consigam entender e/ou recuperar esses dados em sua forma legível. Esse capítulo abordará extensamente as classes responsáveis por criptografia e hashing que o .NET Framework disponiliza, bem como utilizá-las e como aplicá-las ao dia-à-dia.

• Capítulo 9 – Utilizando Code Access Security – CAS Toda aplicação que utiliza o Common Language Runtime (CLR) obrigatoriamente deve interagir com o sistema de segurança do mesmo. Quando a aplicação é executada, automaticamente é avaliado se ela tem ou não determinados privilégios. Dependendo das permissões que a aplicação tem, ela poderá rodar perfeitamente ou gerar erros relacionados a segurança. Code Access Security (também conhecido como CAS), é um mecanismo que ajuda limitar/conceder o acesso que o código que está querendo realizar, protegendo recursos e operações. Este capítulo abordará como utilizar o CAS, que é fornecido juntamente com o SDK do .NET Framework e, como configurar devidamente a aplicação para evitar problemas relacionados a segurança.

• Capítulo 10 – Envio de Mensagens (E-mails) Envio de e-mails é muito comum em qualquer tipo de aplicação, seja ela uma aplicação para internet, uma aplicação para Windows ou até mesmo serviços que rodam sem uma intervenção do usuário. O .NET Framework fornece um namespace contendo classes e muitos outros tipos que podemos utilizar nas aplicação para habilitar o envio de e-mails e, conseqüentemente, torná-las muito mais dinâmicas e inteligentes.

• Capítulo 11 – Criando Serviços do Windows Os Serviços do Windows (Windows Services), permitem-nos criar aplicações que rodam em “background” no sistema operacional. Estes serviços podem ser automaticamente inicializados quando o sistema operacional inicializar, podendo ainda ser pausado e reinicializado, sem apresentar nenhuma interface com o usuário. Esses serviços são ideais para ser usado em servidores ou em funcionalidades de longa duração que necessitem ser executadas de forma totalmente independente, sem a intervenção de um usuário. O capítulo corrente abordará desde a sua criação, depuração e instalação do mesmo.

• Capítulo 12 – Interoperabilidade com componentes COM A Microsoft criou a plataforma .NET e, em pouco tempo, essa plataforma foi adotada por muitas e muitas empresas. Algo importante é que muitas dessas empresas, já tinham componentes COM que eram utilizados em massa nas aplicações e que são inviáveis para serem reescritos imediatamente. Felizmente a Microsoft pensou no legado e possibilita a interoperabilidade de componentes COM, interagindo com aplicações baseadas na plataforma .NET e vice-versa. Este capítulo mostrará os passos necessários para efetuar essa interoperabilidade entre as novas aplicações e o que já existe em código legado.

• Capítulo 13 – Reflection Reflection é a habilidade de extrair informações de metadados de um determinado tipo, ou seja, quais parâmetros, métodos, entre outros membros um determinado tipo possui. Isso torna a aplicação bastante flexível, onde podemos extrair informações necessárias para podermos customizar e automatizar a criação de ferramentas e utilitários que auxiliam os próprios desenvolvedores. Além disso, permite a criação em runtime de Assemblies e como instanciar classes via programação. Esse capítulo propõe-se a explicar como criar esse tipo de funcionalidade dentro da aplicação.

• Capítulo 14 – Threading A criação de threads permitem aumentar consideravelmente a performance das aplicações. Elas fornecem a habilidade de conseguirmos delegar processamentos em diversas unidades de execução, aumentando a capacidade de processamento de uma aplicação. Mas utilizando isso de forma errada, poderá piorar ao invés de melhorar, consumindo mais recursos do que o necessário, tendo um comportamento inesperado e retornando valores diferentes do esperado. O .NET Framework fornece várias classes que podemos utilizar para criação e gerenciamento de threads, bloqueio de recursos em um ambiente multi-threading e sincronização. Este capítulo irá ajudá-lo a conhecer alguns problemas existentes em aplicações que fazem o uso de threads e como contorná-los.

Referências Bibliográficas

• Code Complete – Second Edition
  Autor: Steve McConnell
  Editora: Microsoft Press
  ISBN: 0-7356-1967-0

• Writing Secure Code – Second Edition
  Autores: Michael Howard e David LeBlanc
  Editora: Microsoft Press
  ISBN: 0-7356-1722-8

• CLR via C# – Second Edition
  Autor: Jeffrey Richter
  Editora: Microsoft Press
  ISBN: 0-7356-2163-2

• Programming Visual C# 2005: The Language
  Autor: Donis Marshall
  Editora Microsoft Press
  ISBN: 0-7356-2181-0

• Expressões Regulares – Uma abordagem divertida
  Autor: Aurélio Marinho Jargas
  Editora: Novatec
  ISBN: 85-7522-100-0

• Collection 5160: Core Development with Microsoft .NET Framework 2.0
  Autor/Editor: Microsoft

• Collection 5161: Advanced Development with Microsoft .NET Framework 2.0
  Autor/Editor: Microsoft