none
Carregando objeto remoto por CreateInstanceFrom RRS feed

  • Pergunta

  • Pessoal,

    Estou com um problema para carregar objetos com uso do comando System.Activator.CreateInstanceFrom, e não estou encontrando uma forma de resolver. 

    Nosso executável carrega objetos em tempo de execução, a partir de uma lista variável. Para isso, temos um comando mais ou menos assim:

    Dim a As Object
    a = System.Activator.CreateInstanceFrom(arquivoDll, "BibliotecaX.ClasseY").Unwrap()

    Isso funciona perfeitamente quando o arquivoDLL é local (por exemplo, arquivoDLL = "C:\temp\bibliotecas\BibliotecaX.dll"). Efetivamente, ao cliente o qual distribuímos o sistema, sempre são carregados os objetos a partir de diretórios locais, não havendo problemas no ambiente de produção.

    Entretanto, em nosso ambiente de desenvolvimento, possuímos um servidor onde armazenamos bibliotecas comuns. Durante a tentativa de execução do projeto do executável, quando o comando é acionado (com o arquivo setado para algo do tipo "\\servidorTal\diretorioD\BibliotecaX.dll"), recebemos a exceção:

    System.Security.SecurityException ("Esse assembly não permite chamadores parcialmente confiáveis").

    Não desejamos adicionar o atributo "<Assembly: Security.AllowPartiallyTrustedCallers()> " nos projetos envolvidos, e também consideramos desnecessário acrescentar Strong Name Key em cada uma das DLLs, já que o problema não ocorre em produção. Trata-se apenas de um inconveniente no ambiente de desenvolvimento.

    Verifiquei que, se eu mapear uma Unidade de Rede para o diretório do servidor (exemplo "Z:\" = "\\servidorTal\diretorioD\"), e trocar a chamada do objeto usando essa unidade (exemplo, arquivoDLL = "Z:\BibliotecaX.dll"), a exceção dos chamadores parcialmente confiáveis não ocorre! Ou seja, parece que o .NET está considerando meu servidor de rede como uma zona de internet, e tratando a carga do objeto com restrições de segurança. Mas, com o mapeamento de rede, tudo ocorre como o esperado. Entretanto, também não gostaria que todos os desenvolvedores do setor aqui da empresa criassem uma Unidade de Rede para poder testar seus projetos que utilizam essas bibliotecas comuns. 

    Pesquisei algum exemplo ou dica na internet, para uso de AppDomain, URLAttribute, etc, no comando CreateInstanceFrom, relacionado com servidores de rede, mas não encontrei nada muito claro. 

    Alguém aqui do Forum teria uma dica ou solução para que possamos criar objetos a partir de um servidor de rede, sem necessidade de mapeamentos de unidades de rede e sem inclusão de atributos no Assembly dos projetos, nem Strong Name Keys?

    Grato pela atenção!


    Daniel Ethur - Porto Alegre/RS

    quinta-feira, 12 de abril de 2012 13:56

Respostas

  • Bom dia André!

    Sem problema! Imaginava que a solução do problema estaria no Visual Studio, como uma opção na IDE, ou algo parecido.

    De qualquer forma, encontrei uma forma de solucionar o problema aqui na empresa. Como havia explicado, o problema só ocorria aqui, no ambiente de desenvolvimento da equipe, e não no cliente, durante a execução das aplicações em modo de projeto. 

    Alteramos, nas configurações do projeto, na guia Security, a opção "Enable ClickOnce Security Settings" para sim, selecionando a opção "This is a full trust application". A partir de então, o Visual Studio passa a gerar para o sistema, durante a compilação, os arquivos relacionados ao ClickOnce (*.Application e *.Manifest). Não nos interessa, por enquanto, os recursos do ClickOnce, mas, durante a execução do projeto, a criação das instâncias dos objetos através do comando CreateInstanceFrom, a partir de DLLs em um servidor de rede, não causam mais a exceção dos Chamadores Parcialmente Confiáveis. Isso sem precisar acrescentar qualquer atributo no Assembly do projeto, nem strongs names keys, nem mapeamentos de unidades de rede. Ou seja, o problema está resolvido.

    Grato pela atenção do todos!


    Daniel Ethur - Porto Alegre/RS

    quinta-feira, 19 de abril de 2012 12:03

Todas as Respostas

  • http://social.msdn.microsoft.com/Forums/pt/vsgeralpt/thread/7d198c76-1f12-4881-8d64-f810e2404fbe

    One word frees us of all the weight and pain of life: that word is love.

    quinta-feira, 12 de abril de 2012 20:56
  • Olá Malange!

    Muito boa a discussão do link postado. Mas efetivamente, não está relacionado com o problema que relatei acima. De qualquer forma, agradeço a atenção!

    Sds.,


    Daniel Ethur - Porto Alegre/RS

    quinta-feira, 12 de abril de 2012 21:17
  • Por questões de segunranção o framework não permite executar em rede, de todo jeito você deve permitir esse acesso. Você pode usar o CasPol

    http://bytes.com/topic/visual-basic-net/answers/589578-cant-run-2005-app-network

    ou tente o que sugere o link abaixo:

    http://www.jjclements.co.uk/2008/01/21/run-net-application-from-network-share/


    Bruno Ferreira de Souza
    MSP - Microsoft Student Partner
    MCTS .NET Framework - Windows Applications
    MCPD .NET Framework - Windows Applications
    MCC - Microsoft Community Contributor
    www.maestrodotnet.com.br
    @BrunoMaestro

    domingo, 15 de abril de 2012 19:21
  • Olá Bruno!

    Os artigos são bem esclarecedores. Interessante, entretanto, é que nas configurações do .NET Framework aqui da minha máquina, está ligada FullTrust para assemblies da IntranetLocal, e o problema já acontecia com essa opção assim. Mas tenho dúvida se essa configuração serve para todas as versões do .NET framework, já que no Painel de Controle, ferramentas administrativas, o título da opção de configuração é Microsoft .NET Framework 2.0 Configuration, e as DLL's ao qual me refiro na dúvida estão todas compiladas com framework 3.0 ou superior. Será que existe uma ferramenta de configuração para essas versões superiores do framework, ou elas "capturam" as configurações dessa 2.0 mesmo?

    E também não encontrei explicação de o porquê do funcionamento através do mapeamento de rede; se é uma questão de segurança a execução de código em rede, não estaria aí, então, uma falha de segurança do .NET framework?


    Daniel Ethur - Porto Alegre/RS

    segunda-feira, 16 de abril de 2012 12:18
  • Prezado(a),
    Estou migrando seu post para o fórum de Desenvolvimento .NET Geral.
    Por favor, das próximas vezes que tiver alguma dúvida relacionada a esse assunto, poste por lá.
    Obrigado.

    André Alves de Lima
    Microsoft MVP - Client App Dev
    Visite o meu site: http://www.andrealveslima.com.br
    Me siga no Twitter: @andrealveslima

    quinta-feira, 19 de abril de 2012 10:53
    Moderador
  • Bom dia André!

    Sem problema! Imaginava que a solução do problema estaria no Visual Studio, como uma opção na IDE, ou algo parecido.

    De qualquer forma, encontrei uma forma de solucionar o problema aqui na empresa. Como havia explicado, o problema só ocorria aqui, no ambiente de desenvolvimento da equipe, e não no cliente, durante a execução das aplicações em modo de projeto. 

    Alteramos, nas configurações do projeto, na guia Security, a opção "Enable ClickOnce Security Settings" para sim, selecionando a opção "This is a full trust application". A partir de então, o Visual Studio passa a gerar para o sistema, durante a compilação, os arquivos relacionados ao ClickOnce (*.Application e *.Manifest). Não nos interessa, por enquanto, os recursos do ClickOnce, mas, durante a execução do projeto, a criação das instâncias dos objetos através do comando CreateInstanceFrom, a partir de DLLs em um servidor de rede, não causam mais a exceção dos Chamadores Parcialmente Confiáveis. Isso sem precisar acrescentar qualquer atributo no Assembly do projeto, nem strongs names keys, nem mapeamentos de unidades de rede. Ou seja, o problema está resolvido.

    Grato pela atenção do todos!


    Daniel Ethur - Porto Alegre/RS

    quinta-feira, 19 de abril de 2012 12:03