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!
Evento RowUpdating do GridView não está disparando
Olá! 
Cenário:
Esse post na verdade é uma dica (#tip).
Se você utilizar vários controles com mesmo ID nos ItemTemplate e EditTemplate, o evento de Update (Atualizar) não disparada. Você clica no botão e não acontece nada. Não há postback.
ERRO:
<asp:TemplateField HeaderText="Bla bla">
<ItemTemplate>
<asp:Label ID="lbl1" runat="server" Text='<%# Eval("Valor1") %>’ />
</ItemTemplate>
<EditItemTemplate>
<asp:Label ID=" lbl1" runat="server" Text='<%# Eval("Valor1") %>’ Visible="false" />
<asp:DropDownList ID="ddl1" runat="server" />
</EditItemTemplate>
</asp:TemplateField>
SOLUÇÃO:
Utilize Ids diferentes para cada ItemTemplate. Isso fará o Update disparar o evento de RowUpdating.
<asp:TemplateField HeaderText="Bla bla">
<ItemTemplate>
<asp:Label ID="lbl1" runat="server" Text='<%# Eval("Valor1") %>’ />
</ItemTemplate>
<EditItemTemplate>
<asp:Label ID="lbl2" runat="server" Text='<%# Eval("Valor1") %>’ Visible="false" />
<asp:DropDownList ID="ddl1" runat="server" />
</EditItemTemplate>
</asp:TemplateField>
Abraço!
#GridView #RowUpdating #event #notfiring
Thiago Silva - Especialista SharePoint 