Archive
WebResource ASP.NET – Gerando URL diferente para cada servidor IIS
Olá! 
Cenário:
Imagine que você está desenvolvendo sua aplicação e ela requer diversos arquivos para funcionar, como: arquivos javascript, css, html, imagens, etc. Mas você não quer a solução final tenha diversos arquivos… Quer colocar toda a solução dentro de um único arquivo.
O WebResource (e o ScriptResource para versões mais atuais o .NET Framework) nos dão essa possibilidade. Assim, podemos compilar todos os arquivos de “apoio” dentro da DLL. Ou seja, o arquivo final será apenas uma DLL.
E os arquivos serão referenciados usando o WebResource. Já viram algumas aplicações que usam o WebResource.axd ou ScriptResource.axd seguido de uma longa QueryString?
O “d” é o parâmetro, criptografado, para o arquivo. O “t” é um timestamp usado para saber se o arquivo teve alteração ou não. São gerados automaticamente pelo .NET Framework.
ERRO:
Não é um erro, mas é um comportamento que precisamos contornar. Por padrão, o IIS vai usar a “MachineKey” autogenerated para montar a URL criptografada.
<machineKey validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"
validation="SHA1" decryption="Auto" />
Logo, em um ambiente com vários IIS em Load Balance, por exemplo, cada servidor irá gerar uma URL diferente para o “mesmo” recurso. Isso pode trazer problemas para ambientes que dependam do cache, pois como a URL muda, sempre irá fazer download.
Outros cenários podem ser afetados, como “robôs” de testes que são configurados com URLs. Quando o robô esperar uma URL, virá outra. Além de ViewState criptografada, session state e outros.
IIS 1:
IIS 2:
SOLUÇÃO:
Podemos “forçar” para que a URL criptografada seja sempre a mesma em todos os servidores IIS.
Para isso devemos configurar um valor para MachineKey no web.config da aplicação.
Na web existem alguns geradores de MachineKey. Tendo em mãos uma configuração de MachineKey (validationKey;decryptionKey), basta inserir no web.config da aplicação dentro da tag <system.web>.
Web.config:
IIS 1:
IIS 2:
NOTA: Atenção para os cenários de Cache, pois para que os arquivos sejam inseridos nas políticas de cache, o “compilation debug=’false’” não pode ser “true”.
https://support.microsoft.com/en-us/kb/2580348 – Debug Mode in ASP.NET Applications
“Scripts and images downloaded from the WebResource.axd and ScriptResource.axd handlers are not cached.”
“It is recommended that debug mode is always disabled in a production environment.”
Abraço!
Abrir Dialog em um CustomAction
Olá! 
Cenário:
Neste post vou dar mais uma dica de utilização das funcionalidades nativas do SharePoint 2010.
Muitas vezes criamos links e/ou botões para abrir páginas, e muitas vezes queremos abrir essas páginas em dialogs (ou modal) do SharePoint.
Há inúmeras formas de fazer isso… mas você pode utilizar a função nativa do SharePoint 2010 para isso!
SOLUÇÃO:
Já mostrei como utilizar o Dialog em outro artigo (http://thiagottss.com.br/2010/04/25/usando-client-object-model-do-sharepoint-2010-para-melhorar-a-experincia-do-usurio-ux/), mas aqui está uma outra opção:
OpenPopUpPageWithTitle(url, callback, width, height,title);
Esse método está no core.js e internamente chama o SP.UI.ModalDialog (que mostrei no artigo acima) para abrir o link em Modal Dialog.
Aqui está um exemplo de utilização em um CustomAction:
<CommandUIHandlers>
<CommandUIHandler
Command="MeuCommand" CommandAction="javascript:OpenPopUpPageWithTitle(‘{SiteUrl}/Lists/MinhaLista/AllItems.aspx’, RefreshOnDialogClose, 600, 400,’Meu Custom Action’);" />
</CommandUIHandlers>
Abraço!
Thiago Silva - Especialista SharePoint 