O assunto que quero compartilhar hoje é algo bem simples, mais simples até do que eu imaginava.

Hoje tive que bloquear as funções de Copy, Paste e Cut de um Textbox (ou Input) e logo fui fazendo uma funçãozinha Javascript para fazer isso. O que eu não sabia, talvez por não aparecer no Intellisense do Visual Studio, era que o DHTML (que é uma junção das tecnologias HTML e javascript) disponibiliza muitas outras funções alem de onclick's e onkeydown's. Existem diversos eventos já prontos que seriam úteis em casos como o meu, por exemplo. É só colocar em seu código HTML (Na sua página asp, aspx, etc) e pronto!

Vou colocar abaixo as duas maneiras de se fazer o tratamento de Copiar/Colar. Via função JavaScript (utilizando outros eventos DHTML's) e via DHTML com as funções prontas.

Via Javascript:

<script type="text/javascript">    
       
    function BloquearCopyPaste(e) {       
        var teclasBloqueadas = new Array('c', 'x', 'v');
        var keyCode = (e.keyCode) ? e.keyCode : e.which;
        var isCtrl;

        if (window.event)
            isCtrl = e.ctrlKey
        else
            isCtrl = (window.Event) ? ((e.modifiers & Event.CTRL_MASK) == Event.CTRL_MASK) : false;

        if (isCtrl) {
            for (i = 0; i < teclasBloqueadas.length; i++) {
                if (teclasBloqueadas[i] == String.fromCharCode(keyCode).toLowerCase()) {
                    alert('Ctrl+C, Ctrl+V e Ctrl+X bloqueados');
                    return false;
                }
            }
        }
        return true;
    }
   
     function BloquearBotaoDireito(e) {
        var isRight = (e.button) ? (e.button == 2) : (e.which == 3);
       
        if(isRight) {
            alert('Botão direito do mouse bloqueado!');
            return false;
        }
        return true;
    }
   
</script>

E no input teriamos algo parecido com isso:

<input type="text" onkeydown="return BloquearCopyPaste(event)" onmousedown="return BloquearBotaoDireito(event);" />

Via eventos DHTML:

<input type="text" onCopy="return false;" onPaste="return false;" onCut="return false;" />

Fica aí a dica. Vale a pena dar uma olhadinha na lista dos eventos DHTML antes de sair fazendo suas funções javascript!

Um abraço e até o próximo post!

Nesses últimos dias tive um problema no qual eu setava o Session TimeOut no Web.Config porém a configuração não surtia efeito.

Fiz umas pesquisas e vou compartilhar com vocês o que levantei a respeito desse assunto.

Para configurar o Session TimeOut corretamente talvez você precise mudar suas configurações em mais de um lugar, pois, determinada configuração pode estar anulando outra. Vou listar os possíveis lugares a se configurar logo abaixo:

• Web.Config da aplicação

Quando pensamos nesse assunto a primeira opção que geralmente vem a cabeça é a chave Session State do Web.config da aplicação:

<sessionState mode="InProc"
                      stateConnectionString="tcpip=127.0.0.1:42424"
                      sqlConnectionString="data source=127.0.0.1;trusted_connection=true"
                      cookieless="false" 
                      timeout="20" />

• Idle TimeOut do Application Pool

O tempo default de TimeOut do Application Pool por inatividade é de 20 minutos. Para alterá-lo selecione Propriedades no AppPool desejado, selecione a aba Performance e altere o tempo do Idle TimeOut.

Removendo a opção no Checkbox o processo nunca será reciclado por tempo de inatividade.

• Recycle TimeOut do Application Pool

Selecione Propriedades no AppPool desejado e vá a aba Recycling.

Muito cuidado ao editar esta configuração pois um tempo curto de Recycle pode afetar diretamente a performance de sua aplicação.

Obs: As duas configurações mencionadas acima são aplicadas a todos os Sites que usam determinado Application Pool.

• Session TimeOut da aplicação no IIS

Clique com o botão direito na aplicação desejada e selecione Propriedades. Selecione a aba Home Directory e clique em Configuration.

Abrindo a janela de Configuração de Aplicação selecione a aba Options e conforme mostrado abaixo, mude o tempo de Session TimeOut.

• Default WebSite e DefaultAppPool

As configurações mencionadas acima tambem podem ser aplicadas ao Default WebSite e ao DefaultAppPool.

Caso alguma delas não tenha sido configurada em seu AppPool ou em seu WebSite, por uma questão de hierarquia, a configuração pode estar sendo herdada dos "defaults". Verifique-os para garantir que eles não vão atrapalhar o Session TimeOut de sua aplicação.

No meu caso o Session TimeOut da aplicação e o Idle TimeOut do AppPool estavam com um tempo pequeno, não permitindo que minhas alterações no Web.config surtissem efeito. Fique atento!

Até o próximo post!

Conforme dei uma prévia no post anterior, encontrei alguns problemas para analisar um Dump gerado em um servidor que rodava Windows Server 2003 SP2 64Bits em uma máquina rodando Windows 7 Ultimate 64bits.

Obs: Só tive este problema, pois não possuia uma VM ou uma máquina disponível com o mesmo Sistema Operacional do servidor, ou pelo menos o mesmo framework .net montado na mesma arquitetura. Se voce tiver como montar um ambiente semelhante ou ao menos parecido, vale a pena perder um pouquinho de tempo e deixar este ambiente na manga para utilizações futuras.

Geralmente, tudo que encontramos na internet é que um dump gerado em uma máquina com sistema operacional 64 Bits deve ser analisado em outra máquina 64 Bits de mesma arquitetura, porém a coisa não é bem assim.

Logo ao carregar a extensão SOS.dll (extensão para debugar aplicações gerenciadas do .net) e tentar verificar as Threads da aplicação e o seguinte erro apareceu na minha tela:

0:000> .load C:\Windows\Microsoft.NET\Framework64\v2.0.50727\sos.dll
0:000> !threads
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is
                in the version directory
            3) or, if you are debugging a dump file, verify that the file
                mscordacwks___.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.

Conforme está descrito no Erro ao verificar a versão da DLL do servidor e de minha máquina local confirmei que as dlls do framework eram de versões diferentes mesmo ambos sendo 64 Bits e com o framework 3.5 instalados:

Tentei baixar e instalar o Framework novamente no Windows 7 e até mesmo alterar a versão do arquivo manualmente (gambiarra), mas nenhuma dessas alternativas deu certo. O framework .Net que vem por padrão no Windows 7 é definitivamente de uma versão mais atual do que os disponíveis para downloads em outros SO's. (O "porquê" fica para uma próxima pesquisa e um novo post ).

Como tinha acesso ao servidor para obter as dll's (não podia analisar o Dump no Servidor por motivos de performance) tive a idéia de tentar trazê-las a minha máquina, sobrescrevendo as dll's do framework atual.

O primeiro imprevisto que temos no caminho é que desde o Windows Vista os arquivos de sistema são gerenciados pelos TrustedInstaller, um serviço que roda no Windows e cuida da instalação de módulos e gerenciamento de arquivos de sistemas. Esse serviço pode ser desabilitado através do services.msc (ou simplesmente Services no Windows 7) -> Instalador de Módulos do Windows, porem desabilitá-lo não é recomendado já que ele garante a integridade dos arquivos de sistema do Windows.

Para não desabilitar o serviço fiz o seguinte para as 4 dll's de sistema utilizadas no debug de aplicações gerenciadas (mscordacwks, mscorlib, mscorwks, sos):

takeown /f C:\Windows\Microsoft.NET\Framework64\v2.0.50727\sos.dll 

cacls C:\Windows\Microsoft.NET\Framework64\v2.0.50727\sos.dll  /G username:F

Com estes comandos voce passa a ter passa a ter permissões sobre as dlls desejadas.

Tendo permissão sobre as dll's, fiz backup das minhas dll's atuais e as sobrescrevi com as que eu obtive do servidor.

Feito tudo isso é só abrir o WinDBG novamente carregar a "nova" SOS.dll e PRONTO. É Navegar e se divertir no seu dump.

Espero ter ajudado.

Até o próximo post!

Aproveitando meus estudos de Debug de aplicações, estou preparando alguns posts relacionados a WinDBG para debug de aplicações gerenciadas.

O primeiro post já está a caminho explicará como configurar o Windows Seven 64Bits para debugar um Dump gerado em outro Sistema Operacional. Vou utilizar um exemplo de um Dump gerado em Windows Server 2003 SP2 64bits mostrando as diferenças de versões do Framework 3.5 disponíveis para download no site da Microsoft com relação ao presente no Windows 7.

Isso foi algo que me tomou bastante tempo e por isso vou compartilhar com voces!

Como não será um post que vai explicar o WinDBG do inicio (conceitos e primeiras dicas) sugiro que voces leiam os posts do meu amigo André Nobre em seu Blog. Ele fez alguns posts e algumas aulinhas através de streencast. Esta bem simples e intuitivo!

Um abraço e até o proximo post!

Sejam bem vindos ao primeiro post.

Estou inaugurando este Blog no qual tratarei de assuntos relacionados a desenvolvimento e análise software, compartilhando minhas experiências profissionais e minhas dicas de estudos.

Muito obrigado pelo acesso e em breve colocarei o primeiro post "útil" neste blog

Um grande abraço!!!