Regras Personalizadas no FxCop – Parte 2

Olá pessoal,

Na parte 1 falei sobre o desenvolvimento de uma regra personalizada no FxCop. As possibilidades são muitas, até o momento eu desenvolvi duas regras, uma para validar a nomenclatura de variáveis locais nos métodos, pois a regra que vem com o FxCop valida apenas membros (métodos, propriedades, etc.) públicos, e outra regra que verifica se o programador chama o método Dispose dos objetos que implementam a interface IDisposable.

Outra coisa boa é que a mesma assembly pode ser utilizada tanto no FxCop quanto no Code Analysis do VS Team System. Nesse caso basta publicá-la na pasta C:\Arquivos de programas\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules.

Bom regra desenvolvida e testada, agora vem a pergunta: como distribuir a assembly na pasta Rules em todas as estações dos desenvolvedores? Vou ter que sair copiando a assembly máquina por máquina toda vez que houver uma atualização? Infelizmente nem o FxCop nem o Code Analysis do VSTS tem uma solução pronta e automatizada para isso. E o pior, em minhas buscas pela net não encontrei muita orientação sobre esse problema =/

Depois de quebrar um pouco a cabeça encontrei uma solução razoável: colocar a assembly da sua regra em uma pasta na rede. Depois é só apontar o FxCop ou o VSTS para buscarem a regra da rede, assim você precisará atualizar a assembly em apenas um local.

Para essa solução funcionar, indepedente de você utilizar o FxCop ou o VSTS, primeiro altere a configuração de segurança do Framework, senão ele irá bloquear a execução de qualquer assembly a partir da rede:

1 – Vá até Painel de controle > Ferramentas administrativas > Microsoft .NET Framework 2.0 Configuration;
2 – Entre nas propriedades do item My Computer > Runtime Security Policy > Machine > Code Groups > All_Code > LocalIntranet_Zone;
3 – Clique na aba Permission Set, provavelmente estará como LocalIntranet, troque para FullTrust.

Feito isso, no projeto do FxCop você irá até aba Rules, botão direito Add Rules, e adicione a assembly da sua regra a partir de uma pasta na rede.

Se você utiliza o VSTS, ele permite apontar apenas a pasta inteira das Rules para rede, então copie a pasta com as regras pré-existentes (C:\Arquivos de programas\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules) mais a sua para a rede e efetue o apontamento no registro:

1 – Abra o regedit e vá até a chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\EDev;
2 – No registro FxCopDir informe o diretório das regras na rede.

Pronto, agora você tem uma distribuição centralizada das suas regras =)

Abraços!

Regras Personalizadas no FxCop – Parte 1

Olá,

Muitas pessoas imaginam que o FxCop se restringe a validar o seu código seguindo apenas as regras enviadas junto com o pacote de instalação. Isso é um desperdício do poder dessa ferramenta!

Cada conjunto de regras é armazenado em uma assembly, dentro da pasta Rules, por exemplo:

C:\Arquivos de programas\Microsoft FxCop 1.36\Rules\NamingRules.dll

Essa assembly contém as regras que validam a nomenclatura do seu código. Ou seja, se você escrever a sua dll em .NET (utilizando o SDK do FxCop) e colocá-la na pasta Rules, você conseguirá validar o seu código com as suas regras personalizadas.

Bom falar é fácil, mas atualmente temos dois grandes problemas para desenvolver suas próprias regras:

1 – A SDK do FxCop é liberada para uso, porém ainda não tem documentação nem suporte oficial por parte da Microsoft.

2 – As bibliotecas não analisam o código fonte, e sim a IL (Intermediary Language), isso significa que você tem que entender como a IL funciona para analisá-la.

Quanto a falta de documentação oficial, podemos contornar buscando informações na net. Segue abaixo o link de um PDF bem completo que fala sobre a SDK e o forúm do FxCop no MSDN:

http://www.binarycoder.net/fxcop/pdf/fxcop.pdf
http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=98&SiteID=1

Quanto a entender sobre a estrutura da IL e como o código fonte é transformado após a compilação, infelizmente não há muita coisa na net =/. A solução é gerar alguns códigos simples e estudar como eles ficam após compilados em uma ferramenta chamada Introspector. O Introspector irá carregar sua assembly no formato de uma árvore de objetos, que foram criados para tornar mais fácil a análise e navegação através da IL. Isso irá facilitar e muito as tentativas e erros durante o desenvolvimento da sua regra personalizada.

Durante o meu estudo com o Introspector descubri algumas coisas interessantes, como por exemplo o using e o foreach do C#, após a compilação, são transformados em um bloco try/finally com uma chamada ao Dispose no finally =P

O PDF acima contém um link para o download do Introspector.

Continua na parte 2….abraços!

Começando com o FxCop

Oi Pessoal,

Irei compartilhar aqui algumas experiências que tive com o FxCop no trabalho.

FxCop é um utilitário de validação de código desenvolvido pela Microsoft e disponibilizado gratuitamente para download. Ele funciona analisando a IL (Intermediate Language) gerada pela compilação do .NET, e não os arquivos texto do código fonte. Isso traz a vantagem que ele pode analisar códigos produzidos por qualquer linguagem do .NET, e como desvantagem não é possivel validar coisas que não vão para a IL, como regions e diretivas de pré-compilação por exemplo.

Basicamente para o FxCop validar o seu código você deve escolher qual as assemblies que vão ser validadas (não projetos nem .cs, pois ele valida a IL), e escolher qual das regras de validação vão ser aplicadas. Você pode criar suas próprias regras, mas isso é assunto pra outro post =P

Confesso que minha primeira impressão com o FxCop não foi boa, por falta de conhecimento achei a validação realizada por ele muito intrusiva e falha, mas após um pouco de estudo vi que estava enganado =).

Por exemplo: Existe uma regra chamada “Do not raise reserved exception types” (não lance tipos de exceção reservados), que vai alarmar com qualquer thrown new Exception() que você colocar no meio do seu código. Quando vi isso logo pensei “que bobagem, pra que isso? quem é esse FxCop pra dizer que exceções eu devo lançar? rs”. O FxCop pede para você criar uma Exception personalizada na sua aplicação e lançar apenas essa exceção. O motivo disso é simples, se sua aplicação ficar disparando exceções do tipo Exception por todos os lados, quando você for criar um teste unitário que valide se o código está disparando exceções conforme o esperado, isso dificulta identificar se a exceção disparada veio reamente de um thrown seu ou de dentro do Framework por outros motivos.

Claro que nem todas as regras que vem com o FxCop podem se aplicar a seu projeto, existem algumas que validam Spelling (ortografia), logo se você colocar nome dos métodos em português ele vai achar que estão escritos errados rs

Cabe a você antes de começar a validação, avaliar quais regras utilizar, mas pelo que pude avaliar cerca de 90% das regras são uteis para a maioria dos projetos.

Bom isso é só o começo, logo mais postarei sobre integração do FxCop com o Visual Studio, desenvolvimento de regras personalizadas, entre outras coisas =)

Abraços!