Imprimir código fonte da aplicação

Se você precisa imprimir o código da sua aplicação (acredite, as vezes isso é necessário), abaixo vai uma dica de como fazer isso com Visual Studio.

Abra todos os arquivos que deseja imprimir no Visual Studio, em seguida vá em View > Other Windows > Macro Explorer > Samples > DevStudio6Editor > PrintAllOpenDocuments.

Até a próxima.

Utilizando o MSBuild

Quantas vezes você já teve que colocar todo o código fonte da aplicação em um arquivo *.zip mas sem os arquivos *.dll e *.exe para que o arquivo fique mais leve, e com isso teve que remover todos manualmente das pastas bin?

Abaixo vai uma dica bem simples de como resolver esse problema.

Na pasta onde se encontra a solution crie dois arquivo *.bat: Build.bat e Clean.bat (ver imagem)

No arquivo Build.bat insira o seguinte:

%windir%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe [mySolution].sln /t:Build
Pause

No arquivo Clean.bat insira o seguinte:

%windir%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe [mySolution].sln /t:Clean

Pause

Agora, se alguma vez já compilou sua aplicação execute o arquivo Clean.bat, caso contrário execute o arquivo Build.bat e veja o resultado.

A dica é simples mas essas são algumas das várias funcionalidades do utilitário MSBuild. Para conhece-lo melhor:

http://blogs.msdn.com/msbuild/archive/2006/01/06/508981.aspx

http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx

Free ebook ASP.NET MVC Framework

Scott Guthrie disponibilizou recentemente o capítulo escrito por ele no livro ASP.NET MVC 1.0.
Na verdade o capítulo se trata de um tutorial passo-a-passo da criação de um projeto utilizando o ASP.NET MVC Framework.

Clique Aqui para fazer o download gratuito do *.pdf

Vale a pena conferir.

Vulnerabilidades de segurança no web.config

Bryan Sulivan, gerente de projetos na SPI Dynamics, fez uma publicação sobre dicas de segurança no web.config, dicas essas que são importantes nos atentarmos no desenvolvimento de aplicações web. Abaixo vamos ter um resumão de seu artigo:

Custom Erros:

Ao desativar os erros personalizados o ASP.Net fornece ao usuário mensagem de erros detalhada, disponibilizando assim informações importantes para um hacker. Ao modificar a tag para “RemoteOnly” ASP.Net é instruído a exibir uma mensagem de erro genérica para chamadas externas, porém nas chamadas locais ele continua exibindo as mensagens de erros detalhada.

Configuração Vulnerável:
(web.config) configuration > system.web > configurationErros mode="Off"
Configuração Segura:
(web.config) configuration > system.web > configurationErros mode="RemoteOnly"

Tracing Enabled

O Tracing, sem dúvida nenhuma, é uma excelente ferramenta para realizar o debug e profiling de uma aplicação web, porém pode oferecer informações preciosas a um hacker para atacar sua aplicação caso esteja habilitado.

Configuração Vulnerável:
(web.config) configuration> system.web > trace enable="true" localOnly="falso"
Configuração Segura:
(web.config) configuration > system.web > trace enable="false" localOnly="true"

Debug Enabled

Um erro muito comum no processo de implantação de aplicações web é a publicação do sistema com o debug habilitado, além de ocasionar em problemas de performance você pode estar fornecendo informações privilegiadas as quais os clientes finais não deveriam ter acesso. Por exemplo se você não tiver desabilitado o debug e desabilitado custom erros, então qualquer mensagem de erro exibida para um usuário final incluirá não somente as informações do servidor, mensagem de erro detalhada e statck trace, mas também o próprio código fonte da página onde ocorreu o erro.

Configuração Vulnerável:
(web.config) configuration > system.web > Debug="true"
Configuração Segura:
(web.config) configuration > system.web > Debug="false"

Cookies acessíveis através de client-side script

Ao alterar a propriedade httpOnlyCookies para "true" você garante, globalmente para sua aplicação, que os cookies gerados estarão acessíveis somente no lado do servidor e que não estarão disponíveis a linguages client-side script como o Javascript.

Configuração Vulnerável:
(web.config) configuration > system.web > httpCookies httpOnlyCookies="false"
Confiuração Segura:
(web.config) configuration > system.web > httpCookies httpOnlyCookes="true"

Cookieless Session State Enabled

Na primeira versão 1.0 do ASP.Net para se manter o estado de uma sessão ela era armazenada em um cookie. Isso porém causava problemas quando o usuário não aceitava a criação de cookies. Para resolver esse problema a Microsoft adicionou o suporte a cookieless session tokens.

Embora essa solução tenha resolvido o problema da persistência de sessões, ela pode causar uma brecha de segurança muito grande já que o token gerado é adicionado a barra de endereço do navegador (ex.: http://myserver/myapplication/(1234567ABCDEFG)/default.aspx)

Configuração Vulnerável:
(web.config) configuration > system.web > cookieless="UseUri"
Configuração Segura:
(web.config) configuration > system.web > cookieless="UseCookies"

Outras opções de configuração podem ser realizadas no web.config para garantir segurança a sua aplicação, inclusive Bryan Sulivan disponibilizou a parte II de seu artigo que em breve pretendo colocar no blog.

Fonte: http://www.developerfusion.com/article/6745/top-10-application-security-vulnerabilities-in-webconfig-files-part-two/2/

Workshop sobre padrões de projeto.

Realizei na empresa em que trabalho um workshop sobre padrões de projetos. Eu já imaginava que seria complicado falar sobre esse assunto, e realmente foi. Nos trinta minutos finais do workshop, quando já estava batendo papo como se estivesse em uma roda de amigos, acabei conseguindo o que tanto queria, criar polêmica. Apresentei no workshop apenas um formulário de login utilizando MVC juntamente com outros padrões, procurando deixar claro que muita coisa estava ali apenas para analisarmos os padrões, também aproveitei a brecha para apresentar o DDD.

Após realizar a apresentação formal do projeto, perguntei a todos o que eles encontraram de errado no projeto e críticas que tinham para fazer do mesmo, e somente nos trinta minutos finais eles resolveram fazer as suas considerações, são elas:

“Você esta utilizando MVC para uma tela de login, mas foi construído somente para fins didáticos, você não faria isso em um projeto real, certo?”
R.: Os padrões de projeto são conjuntos de “problemas + solução” se não existe o problema não tem porque aplicar a solução. Por isso é importante conhecer e entender os princípios por trás dos padrões, para saber exatamente onde aplicá-los. O application guide da microsoft até preve a construção de interfaces sem a utilização de MVC e da umas dicas de quando utilizá-lo.
http://msdn.microsoft.com/en-us/library/ms978348.asp

“O objetivo do MVC é reaproveitamento de código certo? Por tanto, qual deve ser o prcedimento quando um controller precisa se comportar de forma diferente para cada view? Ex.: Imagine que eu tenha uma tela que me traga 1000 registros, agora imagine a mesma aplicação rodando em um celular, o celular não tem capacidade gráfica para suportar os 1000 registros, como ficaria a minha controller nesse caso?”
R.: O MVC contribui com o reaproveitamento de código sim, mas ele tem um objetivo claro “separar lógica de negócio da lógica de apresentação”. No exemplo informado imagine que na mesma tela de pesquisa o usuário tenha um campo onde ele pode informar quantos registros queremos exibir por página. O que mudou entre a view e a controller? Perceba que a view pode informar a controller quantos registros por página ela consegue suportar, mesmo que não seja um campo visível para o usuário. Agora isso não quer dizer que vamos conseguir construir um único controller para todas as telas em todas as plataformas possíveis, construir outras controller é totalmente admissível e em alguns casos inevitável.

“Quando você manda para controller alguns dados e no meio do fluxo é necessário abrir uma outra tela, é a controller que deve fazer isso, certo?”
R.: Sim e não, a controller com certeza deve saber que é necessário abrir uma outra tela, mas se você deixar na controller o nome da página *.aspx, o nome do formulário ou nome do *.swf a controller fica extremamente ligada a arquivos de interface o que não é legal (isso acontece hoje no padrão Page Controller utilizado nas páginas *.aspx). Nesse caso sugiro duas soluções:

• A controller notifica a view que ela deve abrir uma outra página e ela se encarrega de realizar essa ação (não é muito bonito mas funciona);
• Existe um padrão responsável em controlar as chamadas para outras interfaces chamado Front Controller que também pode ser aplicado.

Com certeza esse assunto pode trazer mais dúvidas e discussões interessantes, não deixem de postar seus comentários.

Free Ebooks

Olá pessoal, Feliz Ano Novo.

Para quem esta interessado em começar o ano estudando abaixo apresento uma lista de e-books para arquitetura e assuntos relacionados, bom aproveito.

• Acceptance Test Engineering Guidance
  
• Application Architecture Guidance
  
• Application Architecture Guide 2.0
  
• Common Service Locator
  
• Composite Application Guidance for WPF
  
• Design for Operations
  
• Enterprise Library
  
• ESB Guidance
  
• GAX Extensions Library
  
• Guidance Explorer
  
• Performance Testing Guidance for Web Applications
  
• Performance Testing Guidance Project
  
• Security Guidance for Applications
  
• SharePoint Development Guidance
  
• Smart Client Architecture and Design Guide
  
• Smart Client Guidance
  
• Team Development with TFS Guide
  
• Team Development with Visual Studio Team Foundation Server
  
• Unity Application Block
  
• VSTS Guidance Project
  
• WCF Security Guidance
  
• Web Client Software Factory
  
• Web Service Software Factory
  

Princípios de padrões de projeto

Definição de Padrão de Desenho
Os padrões de projeto de software ou padrões de desenho de software, também muito conhecido pelo termo original em inglês: Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.
Referência: http://pt.wikipedia.org/wiki/Padrões_de_projeto_de_software

Princípios de Design (Design Principles)
Design Principles ou princípios de design representam um conjunto de orientações que nos ajuda a evitar uma concepção do desenho.

Abaixo uma lista com 3 características importantes de uma má concepção que devem ser evitadas:

• Rigidez: É difícil mudar, porque cada mudança afeta muitas outras partes do sistema;
• Fragilidade: Quando faz uma mudança inesperadamente partes do sistema começam a falhar;
• Imobilidade: É difícil reutilizar o componente em outro aplicativo;

Alguns princípios são descritos abaixo:

Princípio Aberto Fechado (Open Close Principle):
Definição: “Entidades de software como classes, módulos e funções devem ser abertas para expansão, mas fechadas para modificações”;

OPC é um princípio gernérico Quando se refere às classes o princípio Aberto Fechado pode ser assegurado através da utilização de classes abstratas e concretas para implementar alguns comportamentos. Alguns padrões que refletem esse princípio são Template Pattern e Strategy Pattern.

Princípio Inversão de Dependência (Dependency Inversion Principle)
Definição:

• “Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.”;

• “Abstrações não deve depender de detalhes. Detalhes devem depender abstrações.”.

Inversão de dependência ou de controle são termos relativos e são as melhores maneiras pela quais as dependências são realizadas. Na forma clássica, quando um módulo de software (classe, framerwork, ...) precisam de algum outro módulo, que inicializa e possui uma referência direta a ela, isso os tornará acoplados. A fim de separar o primeiro módulo do segundo e fornecer um gancho (propriedade, parâmetro, ...) um módulo externo controlando as dependências irá injetar uma referência ao segundo. Factory Pattern e Abstract Factories Pattern refletem esse princípio.

Princípio Segregação de Interfaces (Interface Segregation Principle)
Definição: “Os clientes não devem depender de interfaces que eles não usam”.

Este princípio nos ensina a cuidar da forma que escrevemos nossas interfaces. Quando escrevemos as nossas interfaces, deve-se ter o cuidado de só acrescentar métodos que deveriam estar lá. Se acrescentamos métodos que não deveriam estar lá as classes que à implementam teram que implementar esses métodos. Por exemplo, se vamos criar uma interface chamada Trabalho e adicionar um método de intervalo para o almoço, todos os trabalhadores terão de implementá-lo. E se o trabalhador é um robô?

Interfaces contendo métodos que não são específicas para isso são chamadas poluídas ou de gorduras interfaces. Devemos evitá-los.

Princípio Programe para uma interface, e não para uma implementação.
Este princípio é realmente sobre a dependência das relações que têm de ser cuidadosamente geridas de uma grande aplicação. É fácil adicionar uma dependência de uma classe, basta adicionar uma declaração de importação. Curiosamente o inverso não é tão fácil assim e se livrar de uma indesejada dependência pode dar muito trabalho. Por isso você tem que desenvolver com os olhos abertos quando se trata a introdução de dependências. Este princípio nos diz que, depender de uma interface é muitas vezes vantajoso.
Referência: Erich Gamma.

Design usando arquitetura ágil

Olá pessoal, 

Eu tenho acompanhado os posts do pessoal da Microsoft envolvidos com o portal patterns and practices e agora eles lançaram um "How to" sobre desenho de arquitetura ágil.

Para aqueles que estão estudando desenvolvimento com metodologias ágeis como XP ou Scrum vale a pena dar uma olhada nesse material.

http://www.codeplex.com/AppArch/Wiki/View.aspxtitle=How%20To%20%20Design%20Using%20Agile%20Architecture&referringTitle=How%20Tos

Abraços,

Acesso a pastas ou arquivos de outra máquina

O código abaixo demonstra como exibir arquivos ou pastas de uma outra máquina que não seja a máquina na qual se encontra a aplicação.

using System; 
using System.Collections.Generic; 
using System.Text; 
using System.Diagnostics; 
using System.IO; 
using System.Net; 
using System.Security.Principal; 
using System.Runtime.InteropServices;

namespace Cronos.Testes 
{ 
    class Program 
    {

        [DllImport("advapi32.dll", SetLastError = true)] 
        private static extern bool LogonUser(string lpszUsername 
                                            , string lpszDomain 
                                            , string lpszPassword 
                                            , int dwLogonType 
                                            , int dwLogonProvider 
                                            , ref IntPtr phToken);

        [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)] 
        private static extern bool CloseHandle(IntPtr handle);

        [DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)] 
        public extern static bool DuplicateToken(IntPtr existingTokenHandle 
                                                , int SECURITY_IMPERSONATION_LEVEL 
                                                , ref IntPtr duplicateTokenHandle);

        // logon types 
        const int LOGON32_LOGON_INTERACTIVE = 2; 
        const int LOGON32_LOGON_NETWORK = 3; 
        const int LOGON32_LOGON_NEW_CREDENTIALS = 9;

        // logon providers 
        const int LOGON32_PROVIDER_DEFAULT = 0; 
        const int LOGON32_PROVIDER_WINNT50 = 3; 
        const int LOGON32_PROVIDER_WINNT40 = 2; 
        const int LOGON32_PROVIDER_WINNT35 = 1;

        static void Main(string[] args) 
        { 
            IntPtr token = IntPtr.Zero; 
            IntPtr dupToken = IntPtr.Zero;

            bool isSuccess = LogonUser("[myUser]" 
                                        , @"[myDomain]" 
                                        , @"[myPass]" 
                                        , LOGON32_LOGON_NEW_CREDENTIALS 
                                        , LOGON32_PROVIDER_DEFAULT 
                                        , ref token);

            WindowsIdentity newIdentity = new WindowsIdentity(token); 
            WindowsImpersonationContext impersonatedUser = newIdentity.Impersonate();

            DirectoryInfo dirInfo = new DirectoryInfo(@"\\[caminho ou ip da outra máquina]\C$\"); 
            FileInfo[] files = dirInfo.GetFiles();

            for (int i = 0; i <> 
            { 
                Console.WriteLine(files[i].Name); 
            }

            Console.Read(); 
        } 
    } 
}

Créditos: Luiz Fernando.

Utilitário - Cronos Creation Db Files

Olá pessoal, 

Eu criei (copiei - o sql scripter faz a mesma coisa além de outros recursos, só que agora é pago!!) um utilitário que gera arquivos em format *.sql para geração / atualização de registros em banco de dados SQL Server.

Pretendo disponibilizar esse mesmo utilitário para trabalhar com outros bancos de dados, mas ainda não tenho uma previsão, mas em todo caso vale a pena conferir.

Aguardo sugestões de todos ok?

http://code.msdn.microsoft.com/CronosCreationDbFile