Demandas RBS declarativas instruem o runtime a executar uma checagem RBS antes de rodar um método. É a forma mais segura de usar RBS para restringir acesso a código. Existem duas desvantagens para este modo:

• Somente pode ser usado para restringir acesso a métodos inteiros.
• Podem resultar em uma exceção em runtime. Se o método foi chamado por um evento do windows, a exceção é lançada e sua aplicação pode parar.

Para usar demanda RBS declarativa, seu código precisa ter 3 elementos:

• O método System.AppDomain.CurrentDomain.SetPrincipalPolicy para especificar a política de segurança.
• Um bloco Try/Catch para tratar tentativas de acesso sem sucesso e para reportar erros.
• Um atributo PrincipalPermission para declarar requisitos de acesso ao método.

Para aplicar o atributo, você precisa definir duas coisas antes:

• A ação que PrincipalPermission terá, que é conseguida através da enumeração SecurityAction. Geralmente usamos SecurityAction.Demand para RBS.
• Uma ou mais propriedades da classe PrincipalPermission. Use Authenticated para restringir acesso a usuários autenticados, Role para grupos e User para usuários.
  

Neste código que segue, eu quero lançar uma exceção caso o usuário que esteja tentando executar o método FazerPagamento() não pertença ao grupo de administradores:
[PrincipalPermission(SecurityAction.Demand, Role = @"BUILTIN\Administradores")]
static void FazerPagamento()
{
//Qualquer código aqui.
}

Você já se encontrou em situações que perdia minutos preciosos tendo de debugar código?

Imagine aquele laço for{} interminável, em que algo está dando errado mas que você precisa debugar até encontrar o ponto da iteração onde a variável que devia trazer um inteiro, traz um null!

Para evitar essa perda de tempo, o .NET fornece, na classe Debug, o método Assert(). Este método permite que você use uma condição para que o Runtime faça um Break durante a execução da aplicação. Embora neste exemplo sejam apenas três itens, imagine que você tenha um for{} percorrendo centenas de registros, seria muito útil usar algo como isto:

O primeiro parâmetro do método é a condição em que o código vai sofrer o Break. Isto só acontecerá quando a condição for False. Aqui, eu quero ter certeza que os indices sempre guardem algum texto. Neste caso, você terá algo parecido com isto:

Você deve estar se perguntando: Os usuários terão de ver essa tela feia? Não, eles não precisam passar por isto. Basta que você configure o Build do projeto para Release, quando for entregá-lo e estes comandos da classe Debug nem serão compilados.

Não importa o quanto bem codificada e testada é uma aplicação, é muito provável que ela tenha erros ou algum comportamento inesperado. Muitas vezes, os usuários reportam erros ao desenvolvedor em uma linguagem a qual fica difícil saber o que acontece com o sistema.

Versões recentes do Windows trazem recursos úteis para sabermos o que acontece nos sistemas. Os eventos de log são úteis para que o desenvolvedor registre certos aspectos do estado das aplicações, incluindo erros bastante sérios.

Porém, o uso de Eventos de Log traz algumas desvantagens:

ü  Objetos EventLog, incluindo EventLogEntry e EventLogEntryCollection nunca devem ser passados a códigos menos confiáveis. É importante estar ciente do contexto em que esses objetos serão executados.

ü  A classe EventLogPermission é requerida em muitas ações nas quais há uso da classe EventLog. Conceder essa permissão a códigos parcialmente confiáveis pode abrir sérias vulnerabilidades de segurança.

ü  Ler e registrar eventos consome recursos relativamente grandes em termos de utilização do disco, processador e outros recursos. Objetos EventLog devem ser usados quando necessários.

Criando e deletando um Log de Eventos

                Para criar um log de eventos, o Framework .Net fornece a classe EventLog. Para usá-la, a propriedade Source precisa ser especificada e uma mensagem precisa ser registrada, como mostra o código seguinte, que requer uma referencia ao namespace System.Diagnostics:

public static void CriandoEventoLog()

{

   EventLog MeuLog = new EventLog(“LogEventoTeste”);

   MeuLog.Source = “LogEventoTeste”;

   MeuLog.WriteEntry(“CriaEventoLog chamado”,   EventLogEntryType.Information);  

}

Depois de criar um objeto EventLog e especificar a propriedade Source, informações sobre o objeto podem ser vistas na janela de eventos do Windows.

Deletar um Log é tão simples quanto. Para remover o log de demonstração, use o metodo Delete, da classe EventLog:

public static void DeletaLogEvento()

{

   EventLog.Delete(“LogEventoTeste”);

}

Tenha certeza se você deseja remover informações valiosas com esse método!

Escrevendo em um Log de Eventos

Você só precisou de poucas linhas de código para escrever no arquivo de log:

MeuLog.WriteEntry(“CriaEventoLog chamado”, EventLogEntryType.Information);

O método WriteEntry parece ser muito simples, mas ele tem dez sobrecargas! Além de poder manipular Eventos de Log da sua própria aplicação, a classe EventLog também permite ler e escrever nos eventos do Windows (Aplicação, Segurança e Logs do Sistema).  O código seguinte mostra como usar esses Logs (lembre-se de que você deve ter permissões para tal).

Escrevendo em Log de Aplicação:

public static void EscreverLogAplicacao()

{

   EventLog AppLog = new EventLog(“Application”);

   AppLog.Source = “DemoLogAplicacao”;

   AppLog.WriteEntry(“Escrevendo em Log de Aplicação”, EventLogEntryType.Information);

}

Escrevendo em Log de Segurança:

public static void EscrevendoLogSeguranca()

{

   EventLog AppSeguranca = new EventLog(“Security”);

   AppSeguranca.Source = “DemoLogSeguranca”;

   AppSeguranca.WriteEntry(“Ocorreu um ataque de trojan ao sistema do seguinte IP: 192.168.0.1″, EventLogEntryType.Warning);

}

Escrevendo em Log de Sistema:

public static void EscrevendoLogSistema()

{

   EventLog AppSistema = new EventLog(“System”);

   AppSistema.Source = “DemoLogSistema”;

   AppSistema.WriteEntry(“O serviço será inicializado assim que o Windows for reinicializado.”, EventLogEntryType.Information);

}

Até agora, um log de eventos foi criado e escrevemos informações nele. A classe EventLog tem uma propriedade Entries, a qual é uma instancia de EventLogEntryCollection, e contém objetos EventLogEntry. Depois que você obter uma instancia da sua classe EventLog, você pode iteragir pelas entradas de logs, como mostra o seguinte código:

public static void LendoLogEventos()

{

   EventLog LogEventos = new EventLog();

   LogEventos.Log = “LogSistema”;

   foreach (EventLogEntry LogEntry in LogEventos.Entries)

   {

      Console.WriteLine(LogEntry.Source + “:” + LogEntry.Message);

   }

}

Para limpar o log usamos o metodo Clear da classe EventLog:

public static void ApagarLog()

{

   EventLog ApagaLog = new EventLog(“LogDemo”);

   ApagaLog.Source = “ApagaLogDemo”;

   ApagaLog.Clear();

 }

Imagine que você precise criar um User Control, porém, precisa permitir que o desenvolvedor defina como ele será exibido na página.

Imagine que você não saiba como seu controle aparecerá na tela do usuário, onde somente o desenvolvedor, em tempo de design, definirá isso. Isto significa que não podemos incluir no nosso controle nenhuma Texbox, Labels, ou qualquer que seja outro controle. Não sabemos se os dados serão exibidos como link, caixas de texto ou áreas, por exemplo.

Templated User Controls resolve esta questão. Para criar um Templated User Control, você precisa de uma classe que implemente a interface INamingContainer e herde da classe Control. A interface INamingContainer define classes que são contêiners para controles, como as classes Page, Gridview e outras. Você precisa dela para quando quiser renderizar o mesmo controle várias vezes em tempo de execução.

Para criar seu Templated User Control, siga os seguintes passos:

Adicione um UserControl ao seu projeto e nomeie-o para PessoaControl.ascx
Arraste um PlaceHolder ao arquivo .ascx e nomeie-o para PessoaHolder
No CodeBehind do seu .ascx, adicione as propriedades Nome, Cidade e Idade à sua classe. Adicione também uma propriedade do tipo ITemplate.

public ITemplate PessoaTemplate
{
get { return _PessoaTemplate; }
set { _PessoaTemplate = value; }
}

private ITemplate _PessoaTemplate;

Na pasta App_Code, adicione uma classe chamada PessoaContainer, que será a classe implementada pela interface INamingContainer. Não esqueça que ela também herda da classe Control. Essa classe será usada pelo controle para exibir as propriedades na página. Portanto, defina as mesmas propriedades públicas que usou no CodeBehind do seu .ascx .

public class PessoaContainer:Control, INamingContainer
{
public PessoaContainer(string _nome, string _cidade, int _idade)
{
Nome = _nome;
Cidade = _cidade;
Idade = _idade;
}
private string _nome;
public string Nome
{
get { return _nome; }
set { _nome = value; }
}
private string _cidade;
public string Cidade
{
get { return _cidade; }
set { _cidade = value; }
}
private int _idade;
public int Idade
{
get { return _idade; }
set { _idade = value; }
}
}

Agora volte ao CodeBehind do seu controle e aplique os atributos TamplateContainer, passando a classe container PessoaContainer à ele e o atributo PersistenceMode.

[PersistenceMode(PersistenceMode.InnerProperty)]
[TemplateContainer(typeof(PessoaContainer))]
public ITemplate PessoaTemplate
{
get { return _PessoaTemplate; }
set { _PessoaTemplate = value; }
}

No método Page_Init() do controle, verifique se a propriedade PessoaTemplate está definida.
Se estiver definida, instancie a classe container e crie uma instância do ItemTmplate dentro da classe container.

public void Page_Init()
{
PessoaHolder.Controls.Clear();
if (PessoaTemplate == null)
{
PessoaHolder.Controls.Add(new LiteralControl(“Template não foi definido”));
}

PessoaContainer pContainer = new PessoaContainer(Nome, Cidade, Idade);
PessoaTemplate.InstantiateIn(pContainer);
PessoaHolder.Controls.Add(pContainer);
}

Agora adicione um webform no projeto e registre o controle:
<%@ Register TagName=”PessoaControl” TagPrefix=”uc1″ Src=”~/PessoaControl.ascx” %>

Adicione um controle à página e defina as propriedades. Veja que você pode formatar as informações do modo que puder, dentro da tag <PessoaTemplate>:

<uc1:PessoaControl ID=”PessoaControl1″ runat=”server” Nome=”Luciano Carvalho da Silva”
Cidade=”Rio de Janeiro” Idade=”26″ >
<PessoaTemplate>
<select id=”Select1″>
<option><%# Container.Nome %></option>
<option><%# Container.Cidade %></option>
<option><%# Container.Idade %></option>
</select>
</PessoaTemplate>
</uc1:PessoaControl>

Chame o método DataBind() no Page_Load() da sua página.

Note que o controle não é exibido no Design. Mas se você executar a página, poderá ver as modificações.

Abraços, e até a próxima.

Bom, primeiramente, sejam bem-vindos. Este é o primeiro post deste blog, que tem o intuito de discutir e avançar no aprendizado do Microsoft .Net Framework.
Hoje vou falar de Serialização de dados, um assunto um tanto extenso que daria muitos outros posts, se eu fosse falar sobre todos os meios de serializar objetos.

Mas o que é serialização e quando vou precisar usar?

Quando você precisa converter seus objetos em documentos para serem usados por outros processos ou transmitidos pela rede, você os está serializando.
Você precisará deste processo quando outras aplicações necessitarem obter informações dos seus objetos.

Existem dois formatos de serialização no namespace System.Runtime.Serialization :

* BinaryFormatter: Encontrado no namespace System.Runtime.Serialization.Formatters.Binary . É o meio mais eficiente de serialização, utilizado quando os objetos serão lidos por aplicações desenvolvidas no .Net Framework.
* SOAP Formatter: Encontrado no namespace System.Runtime.Serialization.Formatters.Soap . Formato baseado no XML, mais útil para aplicações não desenvolvidas no .Net e para transferir dados por redes, pois é o formato que tem mais sucesso contra bloqueios de firewalls que o BinaryFormatter.Hoje vou falar sobre o SOAPFormatter. Em breve, mostro o funcionamento do BinaryFormatter.

Para usar o SOAPFormatter, adicione uma referência ao System.Runtime.Serialization.Formatters.Soap.dll no seu projeto. Os passos básicos para serializar neste formato são os seguintes:

* Crie um stream para salvar a saída no disco;
* Crie um objeto SOAPFormatter;
* Use o SOAPFormatter.Serialize() para serializar os dados no arquivo.

Primeiro, vamos criar nossa classe que será serializada. Para tornar uma classe serializável, aplique o atributo [Serializable] à ela.

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Serialization;

namespace Serializa_Funcionario
{
[Serializable]
class Funcionario
{
public string nome;
public DateTime dataNascimento;
public int idade;

public Funcionario(string _nome, DateTime _dataNascimento, int _idade)
{
nome = _nome;
dataNascimento = _dataNascimento;
idade = _idade;
}

public Funcionario() {}

public override string ToString()
{
return nome + ” nasceu em ” + dataNascimento.ToShortDateString() + ” e tem ” + idade.ToString() + ” anos de idade”;
}

}
}

A única diferença desta classe para qualquer outra é que ela tem o atributo Serializable. Aliás, na dúvida de saber se suas classes serão serializadas ou não no futuro, aplique este atributo.
Agora vamos criar a classe Program, a qual irá executar o console:

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Soap;

namespace Serializa_Funcionario
{
class Program
{
static void Main(string[] args)
{
if (args.Length == 0)
{
// Se nao houver nenhum parâmetro, desserializa o arquivo existente.
Funcionario func = Deserialize();
Console.WriteLine(func.ToString());
}
else
{
try
{
if (args.Length != 3)
{
throw new ArgumentException(“Precisa entrar com três parâmetros.”);
}

DateTime data = new DateTime(Int32.Parse(args[1]), Int32.Parse(args[2]), Int32.Parse(args[3]));
int idade = DateTime.Now.Year – dataNascimento.Year;
Funcionario func = new Funcionario(args[0], data, idade);
Console.WriteLine(func.ToString());

Serialize(func);
}
catch (Exception ex)
{
DisplayUsageInformation(ex.Message);
}
}
}

private static void DisplayUsageInformation(string message)
{
Console.WriteLine(“\nERROR:Parâmetros inválidos. ” + message);
Console.WriteLine(“\nSerializa_Fucionario \”Nome\” Year Month Date”);
Console.WriteLine(“\nPor Exemplo:\nSerialize_Fucionario \”Luiz\” 1922 11 22″);
Console.WriteLine(“\nOu, execute o command sem parâmetros para exibir o funcionário anterior.”);
}

private static void Serialize(Funcionario func)
{
// Crio o arquivo para salvar as informações
FileStream fs = new FileStream(@”C:/Funcionario.xml”, FileMode.Create);

// Crio um SoapFormatter
SoapFormatter sp = new SoapFormatter();

// Uso o SoapFormatter para serializar o objeto no arquivo
sp.Serialize(fs, func);

// Fecho o arquivo
fs.Close();

}

private static Funcionario Deserialize()
{
Funcionario dsFunc = new Funcionario();

//Abro o arquivo para ler os dados
FileStream fs = new FileStream(@”C:/Funcionario.xml”, FileMode.Open);

// Crio um SoapFormatter
SoapFormatter sp = new SoapFormatter();

// Uso o SoapFormatter para desserializar o objeto
dsFunc = (Funcionario)sp.Deserialize(fs);

// Fecho o arquivo
fs.Close();

return dsFunc;
}
}
}

Aqui, você precisa preencher as propriedades que serão serializadas. Quando abrir o prompt de comando, digite os parâmetros necessários: nome, data e idade. Se nenhum parâmetro for inserido, vai ser desserializado o arquivo, se existir.

O método Serialize recebe o objeto Funcionario para serializar as propriedades:

private static void Serialize(Funcionario func)
{
// Crio o arquivo onde serão salvas as informações:
FileStream fs = new FileStream(@”C:/Funcionario.xml”, FileMode.Create);

// Crio um objeto SOAPFormatter
SoapFormatter sp = new SoapFormatter();

// Uso o SOAPFormatter para serializar as informações no arquivo, passando o stream e a classe.
sp.Serialize(fs, func);

// Fecho o arquivo
fs.Close();

}

O processo inverso é a desserialização. É quando a aplicação remota vai ler as propriedades do seu objeto no arquivo.
Observe que você deve sempre usar o mesmo formato que serializou para desserializar:

private static Funcionario Deserialize()
{
Funcionario dsFunc = new Funcionario();

// Abre o arquivo
FileStream fs = new FileStream(@”C:/Funcionario.xml”, FileMode.Open);

// Cria o SoapFormatter para desserializar
SoapFormatter sp = new SoapFormatter();

// Usa o SoapFormatter para desserializar o arquivo para o objeto.
dsFunc = (Funcionario)sp.Deserialize(fs);

// Fecha o arquivo
fs.Close();

return dsFunc;
}

Alguns detalhes sobre Serialização:

* O SOAPFormatter não dá suporte para compatibilidade entre versões. Se você tem uma aplicação na versão 1.0, não conseguirá desserializar na versão 2.0.
* O formato BinaryFormatter tem total suporte a versões diferentes.
* Use SOAPFormatter se você precisar de portabilidade e BinaryFormatter para ter mais eficiência.

Em breve irei postar mais sobre serialização, é um assunto que gosto e muito amplo. Deixo uma questão para você:

Se o SOAPFormatter não dá suporte para compatibilidade entre versões, o que fazer quando precisar mudar a versão da aplicação? Vamos escrever toda a serialização de novo?

Um abraço, até a próxima.