ZIPAR EXE DOTNET E EXPLODIR SO NA RAM
Bom dia.
Alguém já viu esse artigo http://www.codeproject.com/Articles/7730/Reducing-the-Size-of-NET-Applications ?
A princÃpio seria o que o UPX faz com aplicativos binários do VB6, onde comprime o EXE e gera um PE para ser explodido apenas em memória para execução, sem acesso fÃsico ao EXE original.
Contudo não entendi na prática como usar isso num sistema feito em Dot.NET. Alguém saberia explicar e informar se realmente funciona?
Levando-se em conta que o aplicativo tem DLLs, Resources, e pastas com arquivos de imagem e help externos.
Alguém já viu esse artigo http://www.codeproject.com/Articles/7730/Reducing-the-Size-of-NET-Applications ?
A princÃpio seria o que o UPX faz com aplicativos binários do VB6, onde comprime o EXE e gera um PE para ser explodido apenas em memória para execução, sem acesso fÃsico ao EXE original.
Contudo não entendi na prática como usar isso num sistema feito em Dot.NET. Alguém saberia explicar e informar se realmente funciona?
Levando-se em conta que o aplicativo tem DLLs, Resources, e pastas com arquivos de imagem e help externos.
Sim, isso funciona.
O .Net permite carregar um assembly qualquer a partir da memória usando o Assembly.Load, e o que ele faz ali é basicamente isso, ele incluiu um zip como embedded resource ou algo do tipo no executável responsável por iniciar o programa e então na hora que ele executa este é extraido na memória, carregado com o uso do Assembly.Load e então através das APIs do reflection do .Net ele executa o main do assembly que carregou, e dai ele usa um evento do AppDomain para carregar dlls que ele incluiu junto quando o programa tenta acessar elas.
Mas sinceramente não vejo muita vantagem nisso, a não ser que você vá distribuir o programa sem instalador, para poder incluir junto todas as DLLs e fazer com que seja apenas 1 exe e mais nada, claro que dependendo ainda de ter o .Net Framework instalado no PC.
O .Net permite carregar um assembly qualquer a partir da memória usando o Assembly.Load, e o que ele faz ali é basicamente isso, ele incluiu um zip como embedded resource ou algo do tipo no executável responsável por iniciar o programa e então na hora que ele executa este é extraido na memória, carregado com o uso do Assembly.Load e então através das APIs do reflection do .Net ele executa o main do assembly que carregou, e dai ele usa um evento do AppDomain para carregar dlls que ele incluiu junto quando o programa tenta acessar elas.
Mas sinceramente não vejo muita vantagem nisso, a não ser que você vá distribuir o programa sem instalador, para poder incluir junto todas as DLLs e fazer com que seja apenas 1 exe e mais nada, claro que dependendo ainda de ter o .Net Framework instalado no PC.
Ocelot bom dia.
Independente de ter um único EXE ou a pasta compilada o VS, é necessário ter o framework instalado.
Sendo assim a idéia de ter um único EXE é bem interessante, pois além de reduzir o tamanho do programa distribuÃdo, dificulta muito os bisbilhoteiros, uma vez que não terão como olhar diretamente o EXE (pseudocode) e decompilar. Para isso tem que ter mais conhecimento e usar outras ferramentas mais avançadas, que não são tão fáceis de usar e o resultado já não é 100%.
Você teria como explicar os passos necessários pra fazer isso? Eu não entendi como proceder.
Se possÃvel já agradeço, caso contrário agradeço da mesma forma.
Independente de ter um único EXE ou a pasta compilada o VS, é necessário ter o framework instalado.
Sendo assim a idéia de ter um único EXE é bem interessante, pois além de reduzir o tamanho do programa distribuÃdo, dificulta muito os bisbilhoteiros, uma vez que não terão como olhar diretamente o EXE (pseudocode) e decompilar. Para isso tem que ter mais conhecimento e usar outras ferramentas mais avançadas, que não são tão fáceis de usar e o resultado já não é 100%.
Você teria como explicar os passos necessários pra fazer isso? Eu não entendi como proceder.
Se possÃvel já agradeço, caso contrário agradeço da mesma forma.
Eu poderia até criar um exemplo simples de como fazer isso, mas já te digo que isso não impede que alguém que saiba o que está fazendo consiga extrair o programa verdadeiro para poder olhar o que você fez, e eu diria que precisa usar apenas o ILSpy ou Reflector e mais nada. Você vai conseguir parar provavelmente apenas quem já não saberia o que fazer com o que descobrisse lá.
O tamanho reduzido também não é algo tão considerável assim, pois se você distribuir uma instalação ele já seria compactado na instalação e descompactado na hora que fosse instalado.
Ele vai ocupar menos espaço em disco se for compactado, porém deve usar mais memória já que precisa extrair o arquivo em memória para poder carregar ele, o que também significa que é um pouco mais lento para iniciar o programa, principalmente se ele for grande.
E ainda existe uma limitação, só funciona se todos os arquivos que forem incluÃdos nele sejam feitos em .Net, se tiver por exemplo que mandar junto uma DLL que não foi feita no .Net, digamos por exemplo uma DLL usada por impressora fiscal, ou então uma OCX isso dai já não funciona pois não tem como carregar ela direto da memória desta forma.
O tamanho reduzido também não é algo tão considerável assim, pois se você distribuir uma instalação ele já seria compactado na instalação e descompactado na hora que fosse instalado.
Ele vai ocupar menos espaço em disco se for compactado, porém deve usar mais memória já que precisa extrair o arquivo em memória para poder carregar ele, o que também significa que é um pouco mais lento para iniciar o programa, principalmente se ele for grande.
E ainda existe uma limitação, só funciona se todos os arquivos que forem incluÃdos nele sejam feitos em .Net, se tiver por exemplo que mandar junto uma DLL que não foi feita no .Net, digamos por exemplo uma DLL usada por impressora fiscal, ou então uma OCX isso dai já não funciona pois não tem como carregar ela direto da memória desta forma.
Essa é uma das razões de eu ter abandonado uso de aplicações desktop já faz um bom tempo.
Tópico encerrado , respostas não são mais permitidas