Compatibilidade Net Core

tssa88 commented 6 years ago

Prezados, boa tarde. Gostaria saber se esse projeto é compatível com NET Core? Seria possível buildar/rodar o projeto em uma máquina linux? Caso negativo, existe previsão?

henrique25t commented 6 years ago

É sim. Estamos usando ele aqui na empresa. Usamos .Net core MVC e está ok. Eu baixei a solução no meu pc e vou aprendendo como funciona, mas no nosso programa da empresa estamos usando o pacote NuGet.

ederfdias commented 6 years ago

@henrique25t bom dia, vocês adicionaram a DLL através do NuGet e não teve nenhum warning no projeto? Adicionei no meu projeto ASp.Net Core e apareceu uma warning que talvez não seja completamente compatível com o projeto. Aconteceu isso com vocês? Obrigado.

rcoproc commented 6 years ago

Comigo aconteceu também, e será que irá funcionar com dotnetcore ???

oscarpires commented 6 years ago

também tenho tentado utilizar no aspnet core, porem o warning de que o componente exige o framework 4.6.1 sem compatibilidade plena com o aspnet core v2.0

rcoproc commented 6 years ago

Fiz o teste e não funciona no aspnet core.. só funciona no aspnet MVC. Uma pena, será que alguém aqui já fez alguma conversão para o dotnetcore ????

rcoproc commented 6 years ago

Este fork aqui https://github.com/Tagliatti/BoletoNetCore/ do Filipe Tagliatti está funcionando em Dotnetcore , só não sei se está atualizado. Gera o HTML e o arquivo de remessa, não está gerando o PDF apenas.

carloscds commented 6 years ago

@rcoproc Tinha uma outra tread falando disto.

carloscds commented 6 years ago

@rcoproc Mas não está difícil, só precisamos trocar o componente de PDF para este: https://www.nuget.org/packages/NReco.PdfGenerator.LT

carloscds commented 6 years ago

@rcoproc Pessoal, dei uma olhada no codigo atual e teremos que remover o System.Web e tudo e também atualizar o NReco, como mencionei antes. É uma alteração considerável, já que a impressao do boleto foi toda feita com System.Web.

penihel commented 5 years ago

Na minha aplicação, eu tenho que gerar PDF a partir de HTML, em .NET CORE.

Eu resolvi transformando isso numa chamada pra um serviço externo

https://jsreport.net/

https://jsreport.net/learn/dotnet-local

Creio que seria a melhor opção.

No meu caso eu deixo uma App rodando uma instancia do server do JSReport e conecto pelo Client .NET https://jsreport.net/learn/dotnet-client

Pra rodar o Server, eu criei uma imagem Docker https://jsreport.net/blog/render-reports-using-azure-app-service

carloscds commented 5 years ago

@penihel O problema desta abordagem é este serviço sair do ar.

penihel commented 5 years ago

@carloscds Realmente, mas no meu caso isso não é um problema. Eu só crio a imagem docker em uma webApp no Azure, e recebo uma url pra fazer as requisições. e esta URL sempre está online.

Mas existe uma solução local https://jsreport.net/learn/dotnet-local Nesta opção o JSReport cria um Server Local que junto com a WebApp. Porém esta opção só funciona com todas as opções se sua APP roda em uma VM no IIS. Se for uma WebApp Azure Windows, não rola. Rola se for linux.

Mas uma opção legal, seria a biblioteca pode ser configurada para definir qual serviço/classe de geração de PDF ela irá usar. Assim fica flexível.

carloscds commented 5 years ago

@penihel Precisamos de algo que seja compilado junto com o código, como é hoje. Senão aumenta a complexidade do uso do componente.

olavorn commented 5 years ago

@penihel Precisamos de algo que seja compilado junto com o código, como é hoje. Senão aumenta a complexidade do uso do componente.

Fala @carloscds

Como aquele branch do dnx não deu muito certo (rsrs) fiz uma abordagem diferente dessa vez pra ver se vai. Vamos manter esse fork, mas havendo interesse, fazemos um pull request.

Assim são 1 projeto quebram em 2 projetos + testes.

Sem pdf (netstandard2.2) -> 100% Html Embeded. boleto2.net
O com PDF (pesado, mas 100% netstandard2.2) boleto2.net.pdf https://github.com/BoletoNet/boleto2net/issues/184#issuecomment-509087901

carloscds commented 5 years ago

@olavorn Que ferramenta de PDF você usou ? Pois o problema esta neste ponto. Eu mesmo ja fiz um clone do projeto e migrei para Core, mas sem o PDF.

olavorn commented 5 years ago

Usei a mesma que o NReco usa. BoletoBancarioPdf.cs

        public byte[] MontaBytesPDF(bool convertLinhaDigitavelToImage = false, string urlImagemLogoCedente = null)
        {
            return (new Wkhtmltopdf.NetCore.HtmlAsPdf().GetPDF(MontaHtmlEmbedded(convertLinhaDigitavelToImage, true, urlImagemLogoCedente)));
        }

Só que embarcar os executáveis na dll que deixa a lib pesada. Mas atualmente o projeto faz isso pra deixar mais simples.

carloscds commented 5 years ago

@olavorn Mas o nreco para Core é pago!

olavorn commented 5 years ago

Nao usei NReco. Usei a Wkhtmltopdf "que é a mesma que o NReco usa". Mas ela é free e Open Source.

carloscds commented 5 years ago

@olavorn Pelo visto ele funciona no Linux também, você testou ?

olavorn commented 5 years ago

Não cheguei a testar no linux para fins do boleto, mas tenho outra aplicação que usa um conceito parecido, e a mesma biblioteca. E com algumas dependências ela funciona no Linux sim sem problemas.

https://www.nuget.org/packages/Wkhtmltopdf.NetCore

olavorn commented 5 years ago

carloscds commented 5 years ago

@olavorn Sim, muitos componentes são baseados neste arquivo. Acredito que podemos publicar isto. Lembrando que uma vez migrado para Core, quem utiliza .NET inferior a 4.6 não conseguirá mais usar. O que acha @rafd75 ?

olavorn commented 5 years ago

@carloscds talvez fosse o caso que criar uma tag v2 e um branch v2 a partir daí e mudar a versão com breaking changes. Ex: v3. Talvez interesse a outros manter a versão atual. Assim poderiamos ficar com dois pipelines pra publicar o nuget.

rafd75 commented 5 years ago

bom dia @carloscds @olavorn ...

Eu não consigo opinar nessa questão...

Mas se eu entendi bem o que o Olavo sugeriu, nós teríamos dentro de um mesmo projeto, as duas possibilidades, e se alguém implementasse uma nova carteira no branch Master, reaproveitaria no branch v2 ... Se for isso mesmo, acho uma boa ideia...

No caso, migrar o Boleto2Net para Core, exigindo a versão 4.6, me parece um problema considerando o tanto de pessoas que utiliza o componente.

Uma outra alternativa, seria ter o BoletoCoreNet (como um terceiro projeto), mas perderia o reaproveitamento de novas implementações feitas no Boleto2Net (e vice-versa)...

Enfim... o .NET não é minha ferramenta principal de trabalho e não conheço essas questões de versão para poder opinar neste assunto.... mas se puderem me explicar melhor, eu gostaria de entender as possibilidades.

olavorn commented 5 years ago

@carloscds talvez fosse o caso que criar uma tag v2 e um branch v2 a partir daí e mudar a versão com breaking changes. Ex: v3. Talvez interesse a outros manter a versão atual. Assim poderiamos ficar com dois pipelines pra publicar o nuget.

Também poderíamos verificar as dependências fazerndo configuração multitarget no projeto.. Desta forma, creio que poderíamos aproveitar a grande maioria das classes nesse formato, ainda nas versões anteriores do .net. Só que ainda assim teriamos que ter uma separação inicial do projeto antes de criar a tag, e eliminação das dependências específicas de versões, como a classe control , .ashx etc.

System.Drawing é outro calo também. Então teriamos que implementar de maneira condicional pras duas plataformas; A Alternativa é definir o projeto como multitarget: Fiz um teste e passou com a branch da ExodusSistemas/boleto2net;

Acho que resolveria a questão das dependências pra versões anteriores.. Pelo menos pra quem vai usar a versão HTML.

A versão PDF exige um trabalho extra pois a biblioteca embarcada que eu usei só pe compatível para o target netstandard2.0. Desta forma, para liberarmos para versões anteriores, precisariamos selecionar uma versão compatível com net40 e net2.0. Poderíamos fazer isso de diversas formas, mas faltou tempo pra ver melhor isso hj. Mas não é um grande desafio.

Para implementar isso, o .csproj tem que ter aquele modelo condicional de multiplatadorma:

<PropertyGroup>
    <TargetFrameworks>netstandard2.0;net40;net20</TargetFrameworks>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
    <ApplicationIcon />
    <OutputType>Library</OutputType>
    <StartupObject />
    <Version>2.0.0</Version>
  </PropertyGroup>

...
 <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard2.0' " >
    <PackageReference Include="System.Drawing.Common" Version="4.5.1" />
  </ItemGroup>
<!-- .NET Framework 4.0 target -->
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
    <Reference Include="System.Drawing" />
  </ItemGroup>

oscarpires commented 5 years ago

bom dia pessoal

@carloscds não entendi a questão de não conseguir usar c/ versão inferior a 4.6. O boleto.net para Core não é na pratica, um projeto separado do Boleto2Net framework 4;6? devido as profundas mudanças, estão sendo mantidos e evoluídos paralelamente? As melhorias e manutenções tendem a só ocorrer no BoletoNet Core ?

a propósito @carloscds, assisti sua palestra no teatro em Campinas. Parabéns, mandou mto bem!

On Wed, Jul 17, 2019 at 8:44 AM Carlos dos Santos notifications@github.com wrote:

@olavorn https://github.com/olavorn Sim, muitos componentes são baseados neste arquivo. Acredito que podemos publicar isto. Lembrando que uma vez migrado para Core, quem utiliza .NET inferior a 4.6 não conseguirá mais usar. O que acha @rafd75 https://github.com/rafd75 ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/BoletoNet/boleto2net/issues/104?email_source=notifications&email_token=AAD52X2B7KJWJ7T4C3D6UHTP74AZNA5CNFSM4FJHCBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2D5O7Q#issuecomment-512219006, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD52XZPIXXRVX2WOSOL3ODP74AZNANCNFSM4FJHCBCQ .

olavorn commented 5 years ago

@oscarpires , creio que se formos pelo caminho de criar uma estrutura comum que suporte todas as plataformas e criar projetos que apenas viabilizem agregação de mais serviços e funcionalidades que não são comuns (Ex: PDF), então creio que poderemos em um futuro próximo convergir pra todas as plataformas e evoluir as funcionalidades referentes ao negócio principal de maneira unificada.

oscarpires commented 5 years ago

@olavorn https://github.com/olavorn me parece que não será viável termos uma estrutura comum, devido o .net core não possuir retrocompatibilidade com o .net framework. Se os componentes forem migrados pro .net core, a camada de visualização (razor) irá conseguir consumir, mas no .net framework não. Precisará recompilar no .net framework, certo? A tendência será evoluir o projeto no .net core e manter o legado no .net framework ?

On Wed, Jul 17, 2019 at 11:59 AM Olavo Rocha Neto notifications@github.com wrote:

@oscarpires https://github.com/oscarpires , creio que se formos pelo caminho de criar uma estrutura comum que suporte todas as plataformas e criar projetos que apenas viabilizem agregação de mais serviços e funcionalidades que não são comuns (Ex: PDF), então creio que poderemos em um futuro próximo convergir pra todas as plataformas e evoluir as funcionalidades referentes ao negócio principal de maneira unificada.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BoletoNet/boleto2net/issues/104?email_source=notifications&email_token=AAD52XYKZRONQMS4KTI3A6TP74XTXA5CNFSM4FJHCBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2EPVAI#issuecomment-512293505, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD52X4AWRAO6G44CFBPQSTP74XTXANCNFSM4FJHCBCQ .

carloscds commented 5 years ago

@olavorn @oscarpires O problema de migrar para netstandard2.0 é que quebra a compatibilidade com .NET inferior a 4.6.1 (https://docs.microsoft.com/pt-br/dotnet/standard/net-standard). Sendo assim eliminamos usuários inferiores a esta versão. Criar um novo branch/projeto pode ser a saida para inicarmos a portabilidade, mas como o @rafd75 falou, teremos trabalho dobrado para migrarmos coisas novas de um para outro. Manter tudo em um único projeto pode ser complicado, pois estando no .NET Core fatalmente iremos implementar algo que quebra o código em versões anteriores. Isto tudo em minha opinião é claro, fiquem a vontade para opinar :-)

marcosgerene commented 5 years ago

@carloscds @oscarpires @rafd75 @olavorn @thiagosoeiro

Caros, vou falar como usuário.

Meus principais softwares são desktop, hoje uso a versão 4.6.2 do .Net.

Mudanças na versão do .Net sempre são traumáticas para quem vem do mundo desktop, como sou software house estamos falando em ter que atualizar o .net framework em uma quantidade razoavel de clientes (hoje está diminuindo, pois o windows 10 vem ajudando nesse sentido).

Bem recentemente migrei do 4.6.1 para o 4.6.2, parece simples, mas deu um suporte razoável... e bem, se eu tivesse feito antes o efeito era menor, porque era menos gente usando, menos maquinas... logo, chego à minha conclusão: Se a ideia for "quebrar" para quem usa abaixo da 4.6, este processo deve ser feito o quanto antes, menos pessoas afetadas, menor o trauma.

olavorn commented 5 years ago

Senhores, com relação ao princípio da retrocompatibilidade, estou quase convencido que isso supera a questão.

Com relação as mudanças, nem veria a necessidade de discutir isso, pois poderemos abraçar ambos, o que teoricamente teriamos que ajustar, ao meu ver são dependências de construção internas na versão principal, tais como: Objetivo: Migrar toda a lógica orientada a plataforma para projetos satélites:

Abandono da dependência do System.Web e das versões utilizando o .ashx. => (boleto2net.webforms para quem tiver interesse)
Abandono do System.Web (Classe Control, etc) => (boleto2net.webforms)
Priorização da logica de processamento de arquivo, leitura CNAB e geração em Hipertexto. (ficaria na boleto2net)
Impressão em PDF (boleto2net.pdf)

Desta forma, conseguimos manter o projeto base e seu desenvolvimento em um único ponto, e conseguimos evoluir canais e plataformas de maneira integrada.

Proponho que a gente abra uma branch para isso, e eu me proponho a fazer um pull request inicial para avaliação baseado no nosso fork. Daí podemos avaliar e discutir as mudanças item a item no próprio pull request.

carloscds commented 5 years ago

@olavorn por mim ok!

olavorn commented 5 years ago

Recomendo para nivelamento,

https://docs.microsoft.com/pt-br/dotnet/standard/frameworks

carloscds commented 5 years ago

@olavorn Eu já passei este link alguns comentários acima!

olavorn commented 5 years ago

Vou esperar o link da branch então, @carloscds. Pra a gente iniciar o PR.

carloscds commented 5 years ago

@olavorn @rafd75 Resumindo então: vamos criar outro projeto chamado "BoletoNetCore" e subir um código modificado la?

olavorn commented 5 years ago

Por mim, pode até ser uma branch desse por enquanto. Não creio que precise criar um novo projeto ainda. Ou vcs já querem começar com um nuget funcionando?

carloscds commented 5 years ago

@olavorn @rafd75 Criado: https://github.com/BoletoNet/BoletoNetCore

rafd75 commented 5 years ago

Pronto! ...

Fiquei boiando em alguns pontos, mas se o que eu entendi estiver correto, o projeto "Core" vai ser separado em 2 (parte do boleto em si + parte do PDF)... e isso faz com que ele funcione em qualquer ambiente desde que seja do framework 4.6 para frente... confere?

Se for isso, minha ideia aqui é - em breve - migrar do Boleto2Net para o BoletoNetCore - e passar a investir o tempo nesse novo projeto... (minha única condição de uso é que se mantenha uma padronização nos bancos/carteiras e obrigatoriedade de teste unitário de tudo - pois foi isso que me motivou a sair do BoletoNet e refazer as coisas no Boleto2Net).

carloscds commented 5 years ago

@rafd75 Sera um unico projeto, trocando o NReco pelo outro.

BoletoNet / boleto2net

Compatibilidade Net Core #104