Consuma uma montagem .NET de uma página clássica do ASP

Question

Eu tenho um site antigo do .NET 2005 que possui algumas páginas do ASP e com problemas de referência de objetos para acessar o .NET DLL. A tarefa de manutenção foi proferida para mim e o desenvolvedor original não está em lugar algum :( Eu já comecei no .NET, para que eu realmente não dominei o lidar com esse tipo de problema.

Na seta abaixo, é onde estou incentivando a referência do objeto "(0x80131500) não definida como uma instância de um objeto".

Set objCommon = Server.CreateObject("Wrapper.CommonFunctions")
  Dim machineBuilding
--->>>  If objCommon.IsMachineAccount(strLogin, machineBuilding) Then

Eu já segui estas etapas:

1. regasm /tbl /codebase mycomdll.dll
2. gacutil /i mycomdll.dll
3. Copie o diretório MyComdll.dll para o System32
4. Do console, execute o ISSRESET
5. Se a sua DLL for criada no Framework 2.0, crie um arquivo "dllhost.exe.config" no diretório System32 e coloque o seguinte:

<?xml version="1.0"?> <configuration> <startup> <supportedRuntime version="v2.0.50727"/> <requiredRuntime version="v2.0.50727"/> </startup> </configuration>

6.- reiniciar o IIS com o comando ISSRET

E também estes:

1. Sob as propriedades do projeto a. Sob Application Informações de Assembléia i. Verifique “Torne o conjunto do Assembly”. b. Sob construção i. Verifique “Registre -se para com interop"
2. Não assine.
3. Certifique -se de que o IUSR tenha permissões completas para o arquivo.
4. Reinicie o IIS via iisreset para lavar qualquer caches.

E ainda não foi bem -sucedido executando o aplicativo. Mais alguma idéia do que verificar ou fazer? Obrigado!

Emir

Answer 1

O problema era que o aplicativo está procurando um arquivo que contém o nome do host do banco de dados.

Answer 2

O valor do HRESULT é muito relevante. Observe o 'código da instalação' em 0x80131500, 13 indica que a fonte de erro é gerenciada código. Você já tem a tradução amigável para 1500.

Em outras palavras, o código gerenciado lançou uma exceção e não foi tratado. Isso não é incomum, é claro, o código gerenciado geralmente lança exceções. Especialmente NullReferenceException, o que você desencadeou. A depuração disso não é tão fácil, pois você está executando o código gerenciado em um processo não gerenciado. Não tenho certeza de qual é o procedimento adequado para o IIS, normalmente é feito com as ferramentas + conectar ao processo. A melhor maneira de enfrentar isso é isolar o código, escrever alguns testes de unidade.

Fora isso, a variável de construção mecânica me parece um bom candidato ao NRE. Você não inicializou.

BTW: Não tem nada a ver com o registro. Isso produz um tipo de erro muito diferente.

Answer 3

Eu tinha uma solução semelhante à sua, mas já se foi há muito tempo. No entanto, ainda tenho algumas informações sobre isso e notei que minha declaração do Regam é diferente.

regasm mycomdll.dll /tlb :mycomdll.tlb

Suas referências tbl em vez de tlb - talvez esse seja o problema?

Eu também acho que você deve verificar novamente os valores dos parâmetros e, em seguida, chamar o método com esses valores de parâmetros por meio de um cliente .NET rápido e sujo para verificar se o método lança um erro.

Eu também quero confirmar que meu código ASP clássico correspondia ao seu ...

set obj = server.CreateObject("mycomdll.myclass")
...
call obj.method(false)
...
myvar = obj.method2(param1, param2, param3)