Eu tenho um aplicativo da web que estava usando a versão 2.1.0 do SubSonic. Ao adicionar alguns novos recursos, me deparei com um bug nessa versão que foi corrigida no 2.2.0.
Na minha caixa de dev, eu mudo a versão da DLL referenciada e tudo funcionou bem.
Após atualizar o servidor Windows 2008 R2 que executa o IIS 7.5, o bug persistiu.
Eu procurei no servidor e substituí cada instância do SubSonic.dll pela versão mais recente.
Reiniciou o site, o pool de aplicativos e, em seguida, o servidor inteiro.
Eu executei o Process Explorer do SysInternal e verifiquei o processo w3wp.exe para o site e, de acordo com ele, o w3wp.exe está fazendo referência à versão 2.2.0 do SubSonic.dll.
Eu copiei o banco de dados e os arquivos de site daquele servidor Windows 2008 para outro 2008 (um que nunca tinha v2.1.0 carregado) e confirmei que o erro não ocorre lá.
Com base nos sintomas, parece que o servidor está segurando a versão 2.1.0 da DLL, mas não consigo descobrir onde ela está e como me livrar dela.
Informações adicionais:
Eu verifiquei o GAC, sem subdsonic dlls.
Instalado 2.2.0 no GAC usando o gacutil do Windows SDK 6.1
Configure um novo Site e AppPool no servidor e carregue uma nova cópia dos arquivos do site da minha caixa de mensagens.
O site é C # .Net 2.0 usando MVC 1 com nHaml 2.0 para o mecanismo de visualização.
Usado o cygwin find para procurar no sistema de arquivos por qualquer arquivo com o mesmo tamanho que o 2.1 DLL.
Encontrou algumas cópias que a caixa de pesquisa do Windows não tinha, elas estavam apenas em uma pasta de backup, não deveriam estar em uso, excluídas apenas por precaução.
Os únicos arquivos restantes com o mesmo tamanho da versão 2.1.0 são:
./Windows/System32/DriverStore/FileRepository/prnca00z.inf_amd64_neutral_27f402ce616c3ebc/Amd64/CNBDR4_5.DLL
./Windows/winsxs/amd64_microsoft-windows-getuname.resources_31bf3856ad364e35_6.1.7600.16385_pt-br_eca42f29f7e4d0ea/getuname.dll.mui
./Windows/winsxs/amd64_prnca00z.inf_31bf3856ad364e35_6.1.7600.16385_none_ea189c313845a10e/Amd64/CNBDR4_5.DLL
./Windows/winsxs/x86_microsoft-windows-getuname.resources_31bf3856ad364e35_6.1.7600.16385_pt-br_908593a63f875fb4/getuname.dll.mui
Que parecem não ter nada a ver com as DLLs de SubSonic.
Atualização 8-30-2010
O raciocínio em relação ao bug para suspeitar da versão da DLL em uso é o problema:
O erro que está acontecendo é bastante específico e na minha caixa de desenvolvimento quando eu mudo entre 2.1.0 e 2.2.0 da DLL previsivelmente acontece sob 2.1.0 e não 2.2.0.
Eu também coloquei o site em um servidor diferente e ele funciona bem com o 2.2.0, então o trabalho não é exclusivo da minha caixa de desenvolvimento.
Basicamente, na versão 2.1.0 ao fazer uma consulta de resultados paginados, os elementos da cláusula WHERE são duplicados para que a consulta gerada termine com "WHERE CreatedOn > '8-1-2010' AND CreatedOn > '8- 1-2010 '".
Embora redundante, sintaticamente, isso é bom para executar.
Quando você adiciona em um SubQuery é quando dá errado porque o objeto SubQuery tem seu SQL gerado duas vezes e a segunda vez em vez de começar com um WHERE ele inicia com um AND porque um sinalizador booleano no objeto de rastreamento se o WHERE tiver foi iniciado é verdade no início desde a primeira vez que gera o SQL.
Portanto, sob 2.1.0, você obterá "WHERE id IN (ID SELECT FROM WHERE CreatedOn > '8-1-2010') AND id IN (ID SELECT DA tabela AND CreatedOn > '8-1-2010 ') "
No 2.2.0, a cláusula WHERE em uma consulta paginada não repete suas condições e, portanto, a subconsulta não gera uma sintaxe SQL incorreta.
A geração SQL ocorre dentro da DLL e eu posso observar através do SQL Profiler que o 2.1.0 gera a sintaxe ruim, mas quando executo localmente com a 2.2.0 a sintaxe é adequada.
Como esse erro é uma situação tão específica, o site funciona bem em geral, é apenas em uma consulta de pesquisa específica que isso acontece e é muito fácil repetir isso sem código, dados ou estrutura de dados ou outras alterações de ambiente , erros sob 2.1.0 mas não 2.2.0.
Eu não tinha dado detalhes sobre o bug anteriormente, pois não parece relevante para resolver o problema, a resolução deve ser sobre qualquer dll de terceiros carregados a partir do diretório bin de um site asp.net sendo armazenado em cache e não atualizar versão após o pool de aplicativos, reinicializações de serviços e máquinas, criação de novos contêineres, exclusão e reenvio de todos os arquivos do site, etc.