Jump to content

Nelson A Sousa

Membros
  • Content Count

    235
  • Joined

  • Last visited

  • Days Won

    1

Nelson A Sousa last won the day on July 29 2018

Nelson A Sousa had the most liked content!

Community Reputation

69 Excellent

1 Follower

About Nelson A Sousa

  • Rank
    Membro
  • Birthday 05/17/1967

Contact Methods

  • Skype
    nelsonasousa

Profile Information

  • Sexo
    Masculino
  • Localização
    Muriaé - MG

Recent Profile Visitors

783 profile views
  1. Olá @Rafael Dias, Obrigado pela resposta. Quanto a sua sugestão 1, eu entendi. Eu só prossegui no post, para o caso de não se saber a OS do cliente, ou no caso de um cliente com várias máquinas com vários OS's. Então, para não ter que ter várias versões de distribuição, eu pensei em termos apenas uma distribuição que atendesse qualquer tipo de OS. Quanto à sugestão 2 e 3, eu fiz exatamente isso. Modifiquei a classe e ela carrega as dlls nativas na respectiva pasta da OS. Nos testes que efetuei aqui, o funcionamento correto só ocorre quando as dlls de dependências estão na raiz do EXE. Note que falei das dependências, neste caso, quando aciono a LibNFe ela não busca na pasta configurada na classe de alto nível, mas sim na pasta raiz do EXE. Não sei se estou explicando corretamente...rsrsrs...mas a questão está no carregamento das dlls de dependência.
  2. Minha limitação no Delphi não vai permitir que eu faça muita coisa não. O problema é que as dlls nativas do AcbrLibNFe, não importa a plataforma se x86 ou x64, sempre procuram as dlls dependências na pasta raiz do EXE. Como as dlls da pasta dep, apesar de terem o mesmo nome, são de plataformas diferentes e não podem ser copiadas para a pasta raiz do EXE. Para o carregamento das dlls nativas, no caso a ACBrNFFe32.dll e a AcbrNFe64.dll, cada uma em sua respectiva pasta de plataforma, tudo transcorre normalmente. Somente o carregamento das dependências é que não funciona. Como eu disse, meu conhecimento de Delphi é bem limitado, talvez alguém consiga fazer com que as dlls nativas procurem suas dependências na pasta da própria dll e não na raiz do EXE. Dessa forma poderemos construir um único instalador, já com as versões das duas plataformas x86 e x64. Para exemplificar coloquei a estrutura de pasta ideal na primeira imagem abaixo. Na segunda imagem coloquei a pequena modificação que precisei fazer no constructor da classe. Apenas acrescentei o path das pastas. Reparem que as dlls de dependência, apesar de plataformas diferentes, têm o mesmo nome. Isso impede a colocação das mesmas na pasta raiz do EXE, ou se coloca x86 ou se coloca x64. O que torna a verificação de plataforma executada no constructor da segunda foto, de certa forma inútil.
  3. Bom, sobre o Java eu não posso falar. Mas quanto ao C#, VB e VB.net não tem problema não. Vou fazer umas modificações eu mesmo aqui, e, se der certo, eu envio pra averiguação.
  4. Admito que tem um certo grau de paranóia organizacional de minha parte...rsrsrsrs
  5. @Daniel Simoes, Sim, e que as dlls nativas reconhecessem a mesma estrutura de pastas quando do carregamento das dependências. A raiz no caso seria a pasta AcbrLib, esta sim, seria colocada na pasta do executável. Uma vez que a classe de alto nível reconhecesse a plataforma em que está o EXE sendo utilizado. A estrutura de pastas seguiria uma padronização como a sugerida acima. Dessa forma não importaria a plataforma, se x86 ou x64, e o Acbr rodaria sem problemas.
  6. Olá, É uma boa compartilhar a solução com os demais usuários. Alguém pode estar passando ou passar pelo mesmo problema. Dê uma breve descrição do que estava fazendo errado e como solucionou!! Fica a dica!! Um Abraço,
  7. Sim, um bom exemplo pode ser encontrado no carregamento da SqlServerTypes. Só que no caso, será necessária uma mudança nas dlls nativas,, elas que vão decidir em qual pasta procurar as dependências. Ou então, uma mudança geral em como arquivar as dlls nativas do Acbr, ou seja, separadamente, cada uma na pasta de sua respectiva plataforma. Mas essa segunda opção aí talvez seja necessária somente como forma de organizar os arquivos. Não tem tanta necessidade. Loader.cs
  8. Bom, Resolvido!! Forcei a compilação em x86, copiei todas as dlls envolvidas para a raiz do meu EXE, e funcionou!!! Obrigado @Daniel Simoes!!
  9. Ahh, o erro pode estar aí então. O C# no V. Studio tem a opção de x86, x64 e AnyCPU. Como no exemplo está da mesma forma, ou seja AnyCPU, estou deixando o método construtor decidir qual dll vai ser carregada. Vou forçar em x86 aqui, copiar as dlls para a raiz do meu EXE e fazer um teste. Volto aqui pra dar o resultado. Por enquanto muito obrigado @Daniel Simoes!!!
  10. Olá pessoal, Usando as Libs no C# com o Visual Studio 17. Há uns dias atrás tive um problema para carregar as dlls da AcbrLibPosPrinter. Meu erro era que eu as estava empacotando num arquivo de recurso e isso não era mais necessário. O problema foi resolvido. Fiz o mesmo procedimento com as dlls da ACBrLib.NFe porém voltei a ter problemas ao carregar as dlls. Está retornando o erro de que não foi possível carregar a biblioteca. A única diferença está nas pastas das dependências, não sei se devo manter os nomes das pastas, ou separar apenas por x32 e x64. Ou devo empacotar as dlls da NFe? Podem me dar uma luz?
  11. Posta o Log aí pra gente ver.
  12. É isso aí Rafael!! Sem empacotar!! Solucionado!!
  13. Olá Rafael, Obrigado pela resposta!! Então, o Demo que utilizei é o do SVN (revision 17746), que está na pasta de demos do C#. Lá as dlls estão "empacotadas". Mas vou fazer um teste com as dlls compiladas no Lazarus e volto aqui pra dar um retorno.
×
×
  • Create New...