Ir para conteúdo
  • Cadastre-se

gostartlab

Membros Pro
  • Total de ítens

    15
  • Registro em

  • Última visita

Sobre gostartlab

gostartlab's Achievements

Apprentice

Apprentice (3/14)

  • Collaborator Rare
  • First Post
  • Reacting Well Rare
  • Conversation Starter
  • One Year In

Recent Badges

6

Reputação

  1. Deu certo agora com a atualização no cliente pessoal. Muito obrigado pelo suporte !
  2. Olá @Renato Rubinho, funcionou com esta nova versão, era algum conflito local mesmo no build. Quando versionar para o nuget público nos avise fazendo favor ? Deixamos o cliente para emitir NFCe temporariamente em produção, com a nova versão vai funcionar o MFE deles. Obrigado.
  3. @Renato Rubinho, no arquivo que mandou não tem alteração parece, decompilando mostrou o mesmo código: Aconteceu o mesmo erro. Pode tentar gerar com uma outra versão pra gente garantir que não teve algum conflito ou algo assim por ter gerado na mesma versão ?
  4. Pessoal, conseguimos descobrir o problema. O real problema é que na classe ACBrLibHandle.cs, está sobrescrevendo a variável PATH do usuário/sistema, neste caso quando a DLL do acbr vai carregar a DLL do mfe, ela não é encontrada, porque o PATH não tem mais as outras referências. Alterando este trecho: public static string LibraryPath { get => libraryPath; set { if (value != libraryPath) Environment.SetEnvironmentVariable("PATH", value); libraryPath = value; } } por isto: public static string LibraryPath { get => libraryPath; set { if (value != libraryPath) { var currentPath = Environment.GetEnvironmentVariable("PATH"); var updatedPath = string.Concat(currentPath, ";", value); Environment.SetEnvironmentVariable("PATH", updatedPath); } libraryPath = value; } } Ai resolveu, assim somente adicionamos no PATH já existente, mas mantendo todas as referências que já tinham.
  5. Nunca fiz isso, mas acredito que consigo sim. Vou fazer um teste e retorno @Renato Rubinho. Vlw
  6. @Daniel InfoCotidiano, no meu caso não utilizo o Visual Studio, não tenho ctz se é pelo seu print. Mas de qlqr forma, compilamos via linha de comando o projeto: dotnet publish --no-restore --configuration Release -p:AssemblyVersion=0.0.1 -p:Version=1294207768-staging -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true --self-contained true --output ./publish-agent-win --runtime win-x64 src/Agent.WorkerService passamos a runtime pra win-x64, porém a minha dúvida é se isso também se propaga para as libs que referenciamos ou se deve definido quando geram o pacote para versionar no nuget. O nosso Agent.WorkerService.csproj esta dessa forma: <Project Sdk="Microsoft.NET.Sdk.Worker"> <PropertyGroup> <TargetFramework>net6.0</TargetFramework> <RuntimeIdentifiers>win-x64;osx-x64;linux-x64</RuntimeIdentifiers> <Nullable>enable</Nullable> <ImplicitUsings>enable</ImplicitUsings> <RootNamespace>Agent.WorkerService</RootNamespace> <Version>1.2.3.4-Dev</Version> </PropertyGroup> <ItemGroup> <PackageReference Include="ACBrLib.Core" Version="1.2.2" /> <PackageReference Include="ACBrLib.NFeMT" Version="1.0.6" /> <PackageReference Include="ACBrLib.PosPrinterMT" Version="1.0.3" /> <PackageReference Include="ACBrLib.SatMT" Version="1.0.3" /> </ItemGroup> </Project>
  7. Comparando os projetos ACBrLib.Core, ACBrLib.SatMT e ACBrLib.NFeMT, somente no ACBrLib.Core tem a configuração <Platforms>AnyCPU;x86</Platforms>, e como o problema parece ser em relação a arquitetura x86 e x64, parece mais ser na configuração deste projeto. Tem algum motivo para ter esta configuração no projeto ? Perguntando pois pode ser algo que não temos mapeado aqui. Mandando aqui como está o csproj para o ACBrLib.Core dentro do nosso projeto, o que agente faz é copiar os fontes para dentro do nosso projeto, porém sem a configuração Platforms
  8. Olá, porém antes da atualização do código para utilização da biblioteca via nuget estava funcionando. Quando volto para utilizar os códigos C# dentro da nossa aplicação funciona, se mudamos para os pacotes nuget, o erro aparece. Utilizando exatamente as mesmas DLL ACBr e MFE, todos utilizando a instalação x64.
  9. Olá pessoal, estamos recebendo a seguinte mensagem para o MFE (estado do ceará): - Erro ao carregar a função: AssociarAssinatura na Biblioteca: mfe.dll Nós já estávamos com uma versão anterior funcionando no cliente, versão x64 do nosso sistema, versões x64 das DLLs do ACBr e também instalação do MFE em x64. Nesta nova versão (que começou o erro), fizemos a atualização das DLLs para as mais novas e também removemos os projetos (código fonte) do nosso projeto e passamos utilizar as disponibilizadas no nuget, mantendo tudo em x64, que então começou este erro. Fizemos um teste voltando para as versões do ACBr que sabíamos que funcionava para ter certeza que não era algum problema na versão da DLL, e também aconteceu o mesmo problema, um outro teste foi voltar o código fonte ACBrLib(C#) para o projeto, e ai funcionou normalmente. Vimos também um tópico aqui no fórum comentando sobre a compilação do projeto, que cita "muito provavel você compilou seu projeto como AnyCPU" Parece ser um problema com a ACBrLib.Core.csproj que está configurando a plataforma com <Platforms>AnyCPU;x86</Platforms>. Podem nos dar um help com essa questão ? Obrigado.
  10. Olá Rubinho, obrigado, era isso mesmo. Deu certo aqui com a opção posPrinter.Config.ArqLog.
  11. Boa tarde pessoal, estamos migrando nosso código C# para utilizar a versão disponibilizada via Nuget, sentimos falta de alguns Meios de Pagametos na ACBrLib.Sat.CodigoMP. Os que utilizamos atualmente que sentimos falta são: mpBoletoBancario, mpDepositoBancario, mpPagamentoInstantaneo e mpSemPagamento (https://portal.fazenda.sp.gov.br/_layouts/download.aspx?SourceUrl=/servicos/sat/Downloads/Especificacao_SAT_v_ER_2_30_03.pdf) Obrigado
  12. Boa tarde pessoal, estamos migrando nosso código C# para utilizar a versão disponibilizada via Nuget, sentimos falta da Sessão Principal, na configuração do ACBrLib.Core.Config.PosPrinterConfig, para configuração dos logs. Obrigado
  13. Com a versão 1.2.2 deu certo. Muito obrigado pessoal. Só tenho mais 2 pontos que sentimos falta aqui nos pacote do Nuget, se devo abrir um novo tópico aqui no fórum sobre, por favor me avise que abro. Na ACBrLib.Core.Config.PosPrinterConfig não tem a sessão Principal, é onde estamos configurando os logs. E na ACBrLib.Sat.CodigoMP, não tem os pagamentos mpBoletoBancario, mpDepositoBancario, mpPagamentoInstantaneo e mpSemPagamento (https://portal.fazenda.sp.gov.br/_layouts/download.aspx?SourceUrl=/servicos/sat/Downloads/Especificacao_SAT_v_ER_2_30_03.pdf) Mais uma vez obrigado.
  14. Boa noite, concordo com a sua solução também. Como eu fiz um ajuste somente para minha aplicação funcionar não preciso me preocupar com compatibilidade de versões anteriores. Sabem quando teremos essa solução dos fontes distribuidos no Nuget ? Obrigado
  15. Olá, estou iniciando com a utilização dos pacotes C# via Nuget e me deparei com o seguinte problema: Minha applicação é distribuída para Linux e Windows via pacote self-contained (1 único binário), assim não temos dependências do dotnet runtime na máquina que executaremos a aplicação. Porém na classe ACBrLibHandle.cs tem um código que não é compatível com a aplicações self-contained. Em modo de debug (localhost) funciona normalmente, porém quando vamos executar a aplicação compilada, recebo o seguinte erro: Unhandled exception. System.TypeInitializationException: The type initializer for 'ACBrLib.Core.ACBrLibHandle' threw an exception. ---> System.NotSupportedException: CodeBase is not supported on assemblies loaded from a single-file bundle. at System.Reflection.RuntimeAssembly.get_CodeBase() at ACBrLib.Core.ACBrLibHandle..cctor() in /builds/app-back/src/ACBrLib.Core/ACBrLibHandle.cs:line 29 --- End of inner exception stack trace --- at ACBrLib.Core.ACBrLibHandle.get_IsWindows() in /builds/app-back/src/ACBrLib.Core/ACBrLibHandle.cs:line 96 at Application.Agent.WorkerService.AgentWorkerServiceStartup.CreatePlataformHostBuilder(String[] args) in /builds/app-back/src/Application.Agent.WorkerService/Program.cs:line 32 at Application.Agent.WorkerService.AgentWorkerServiceStartup.Main(String[] args) in /builds/app-back/src/Application.Agent.WorkerService/Program.cs:line 22 Na ACBrLibHandle.cs hoje tem o seguinte código para definir o path padrão de carregamento das bibliotecas: static ACBrLibHandle() { MinusOne = new IntPtr(-1); var uri = new Uri(Assembly.GetEntryAssembly().CodeBase); // CodeBase não é suportado em self-contained var path = Path.GetDirectoryName(!uri.IsFile ? uri.ToString() : uri.LocalPath + Uri.UnescapeDataString(uri.Fragment)); LibraryPath = Path.Combine(path, "ACBrLib", Environment.Is64BitProcess ? "x64" : "x86"); } Acredito que algo assim resolveria o problema (estou utilizando esta versão hoje no meu fonte, porém não utilizo o path padrão das libs e sim seto o meu em tempo de execução via ACBrLibHandle.LibraryPath static ACBrLibHandle() { MinusOne = new IntPtr(-1); var baseDir = AppContext.BaseDirectory; if (!string.IsNullOrEmpty(baseDir)) { var uri = new Uri(AppContext.BaseDirectory); var path = Path.GetDirectoryName(!uri.IsFile ? uri.ToString() : uri.LocalPath + Uri.UnescapeDataString(uri.Fragment)); LibraryPath = Path.Combine(path, "ACBrLib", Environment.Is64BitProcess ? "x64" : "x86"); } } Obrigado
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.