Rafael Dias

A biblioteca ACBrLibCEP ainda não esta finalizada, o manual possui todas as libs que já começamos a implementação, nem todas foram finalizadas ainda. O comando de ConsultaCadastro existe sim só não estava na documentação mas a mesma já foi atualizada.

A correção que fiz não interfere nada na parte do QrCode, favor abrir um outro tópico para tratarmos do assunto nele.

So tem um jeito de ficar assim, a senha esta errada mesmo no java, pois quem faz a criptografia é a dll se no c# funciona automaticamente no java também. Eu conferi o demo em java em vi que a função getPassword retorna um array de char e por isso a senha ia errada, já foi feita uma correção no demo, baixe novamente e faça novos testes.

emit_cRegTrib só tem 0 e 1 como diz no manual https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca17.html No seu caso o correto seria 1. Eu enviei uma outra versão da dll favor fazer o download da mesma ela deve corrigir este problema. Realmente tinha um problema que so acontece quando carrega o xml e o mesmo não tem as informações padrões preenchidas, a lib não preenchia elas.

Alteração já se encontra no SVN.

Você esta usando a ultima versão disponível para download ?

Geralmente no Linux é instalado o OpenSSL 1.1 que é incompatível com o ACBr, outra coisa a se observar é o nome das dependerias esperadas pelo acbr.

Colocou a dll e suas dependências dentro da pasta System32 ? Dentro do Netbeans eu coloco um path com dependência para localizar a lib, teria como fazer isso por config ou código ? Tem que ver como o Tomcat faz o path do exe, talvez colocar no path do JRE ou do exe do Apache/Tomcat resolva.

Carregamento das dependências de dll nativas seguem o protocolo de procurar nos Paths, isso é o comportamento normal não tem como alterar. A sequencia é sempre path do exe primeiro, depois paths do windows. Você pode fazer uma chamada no inicio do seu exe para definir o path para a pasta correta que ela será usada na procura por dll, utilizando o codigo abaixo. var path = Assembly.GetExecutingAssembly().CodeBase; path += Environment.Is64BitOperatingSystem ? "ACBrLib\\x64\\" : "ACBrLib\\x86\\"; Environment.SetEnvironmentVariable("PATH", path, EnvironmentVariableTarget.Process); Com isso nem se faz necessário alteração na classe atual. Você também pode colocar as libs como resources e extrai-las de acordo com o OS dentro do path do programa, o bom desta opção é que você garante sempre que a lib que esta sendo usada é a versão a qual você testou.

Olha eu consegui ler seu xml corretamente aqui na lib inclusive mandei regerar e o xml veio idêntico. Vou tentar usar o demo do VB6 para ver se consigo reproduzir o erro. Outra coisa como esta o xml de env para o aparelho esta diferente do xml que você mandou carregar ? Teria como extrair o log do aparelho também ?

Sim se olhar no demo as propriedades são enviadas usando a função configGravarValor, principalmente propriedades que são criptografadas, se tentar usar diretamente no ini vai dar erro pois a mesma vai ser lida de forma incorreta pois não possui criptografia. O recomendado é usar a configGravarValor e a função configLerValor para se trabalhar com o ini da ACBrLib.

Pelo visto no log de build faltou incluir o projeto ACBr Common, por isso os vários erros de classes não encontradas, o mesmo se encontra na pasta raiz dos demos em java. Obs.: Por favor quando postar log favor anexar ao posto facilita a leitura do problema.

para resolver isso é simples. Você pode distribuir as dll corretas de acordo com o OS do seu cliente, o que é muito simples. Modificar a classe para carregar das pastas como você fez na mensagem Copiar as dll corretas nas pasta do windows. Qualquer uma das opções acima funciona corretamente, não tem necessidade de mexer na lib.

Qual a linguagem de programação ? Esta usando a dll direto ou alguma classe disponibilizada pelo projeto ?

A configurações se encontra no manual sim https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca16.html Veja a sessã DANFe