Projeto morreu ?

[HenriqueTelesOpenline]

Olá !!
Eu reparei que há 8 meses o pacote nuget não é atualizado
as PRs estão abandonadas sem resposta
Várias mudanças interessantes para levar o projeto para frente estão paradas...

Seria interessante os mantedores do projeto arrumarem alguém mais ativo para cuidar das novas mudanças. Um projeto dessa importância não pode ficar parado tanto tempo.

Seria interessante também se o projeto tivesse um DISCORD onde desse para os interessados conversarem sobre dúvidas ou novas implementações.

[carloscds]

@HenriqueTelesOpenline este projeto é o @rafd75 que cuida.

[rafd75]

Oi @HenriqueTelesOpenline - boa tarde!

O @carloscds acabou de publicar o pacote no nuget... Falei com ele e solicitei que quando ele fizesse a publicação dos outros 2 projetos (abaixo), que também publicasse o Boleto2Net.

1 - https://github.com/BoletoNet/boletonet
2 - https://github.com/BoletoNet/BoletoNetCore

Quanto aos PRs não aprovados:

#318 - Foi analisado e existem pendências a serem resolvidas. Da uma olhada lá, e me diz se você aprovaria o PR (que diz alterar o header do Sicred)

#338 - Criação de parâmetro para logotipo: Mas altera (além da classe do boleto), pelo menos o Bradesco, e o Brasil. Dentro do Brasil, olhando por cima, vi uma inconsistência:

#343 - Alguns pontos, antes de falarmos sobre o código propriamente dito...
A - Sobre o FastReport: Acreditamos que quanto menor a dependência de outros libs, melhor. O Boleto2Net já entrega tanto em HTML, quanto em PDF. Qual a razão de acoplar outro gerador dentro do Boleto2Net
B - Ser multitarget : Já existe o projeto do NetCore (obs: não acompanho lá) -> https://github.com/BoletoNet/BoletoNetCore - qual a vantagem de incluir esse recurso aqui?
O PR está cheio de alterações no código, e muita gente já usando em produção. Os testes unitários estão ali para ajudar, mas tem muita coisa que não passa no teste, como por exemplo, as mensagens sobre o sacado, que percebi ter passado por um ajuste também.

Voltando ao título da issue, não acredito que o projeto está morto não. O objetivo principal da criação do "2" (baseado no Boletonet) é exatamente manter um padrão de código, e esses PRs maiores, são sempre um problema para analisar.

[HenriqueTelesOpenline]

Olá
Obrigado pelas respostas e desculpe se me fiz parecer rude com o título da issue. Não foi a intenção.

Vamos lá
Respondendo sobre a minha PR #343

Sobre o FastReport: Acreditamos que quanto menor a dependência de outros libs, melhor

FastReport é amplamente usado e atualizado com frequência. Inclusive o projeto OpenSource de nota fiscal eletrônica em .Net mais conhecido (Zeus DFe.Net) o usa. Não é uma lib anônima, nesse caso eu vejo com bons olhos, afinal também temos o NRecoPdf.

Outro ponto positivo é que é muito mais fácil dar manutenção em um relatório do que um código HTML e CSS escrito com C#.

Qual a razão de acoplar outro gerador dentro do Boleto2Net

Ele só está sendo compilado nas versões .NetCore. Não foi alterado para .Net framework.

Mas acredito que futuramente possa ser uma opção viável usar o FastReport para centralizar a impressão em pdf. Sendo que o mesmo também exporta relatório em HTML e Imagem.

B - Ser multitarget : Já existe o projeto do NetCore

Mas o BoletoNetCore não é um fork do BoletoNet. Ele meio que tem uma trajetória própria. Na minha opnião isso cria uma barreira no desenvolvimento pois certas alterações que forem desenvolvidas para o Boleto2Net podem não se adequar no BoletoNetCore e vice-versa já que a estrutura dos dois tem diferenças.

A forma como o BoletoNetCore escolheu para imprimir o pdf também não achei interessante, pois eu fico dependente de instalar uma ferramenta de terceiros no meu computador para conseguir gerar um pdf. Referenciar uma lib do nuget (FastReport) para mim parece bem mais adequado do que a abordagem que eles escolheram.

qual a vantagem de incluir esse recurso aqui?

Tem várias. A maior de todas é não precisar ter de dar manutenção em dois projetos. Quando alguém adicionar uma carteira no BoletoNet, não precisa ficar se preocupando em adaptar pro BoletoNetCore. E o contrário também serve. Pode ter carteiras implementadas lá no .NetCore que não temos aqui. São cérebros pensantes distribuídos em 2 projetos diferentes. Pouco prático.

Fora isso, quem usa versão antiga (.Net 4.0) não vai sofrer com a alteração, pois na mudança pro multitarget eu priorizei manter a versão atual para não atrapalhar quem já usa o projeto hoje.

Resumindo:

• Um projeto só para dar manutenção
• Quem usa versão antiga (.Net 4.0) não vai sofrer com a alteração
• Atrair o pessoal do Core pra contribuir com o projeto
• Manter o projeto atualizado com as versões do .Net suportadas pela microsoft.
• Desde o Visual Studio 2015 não tem componente SDK .Net 4.0 no installer, ou seja, está bem defasado.
• Ferramentas de Build CI/CD (Github actions / Azure Pipelines) já não fazem deploy automático em versões do .Net que não são suportadas pela microsoft

O PR está cheio de alterações no código, e muita gente já usando em produção.

O código compilado em .Net 4.0 permaneceu o mesmo, exceto uma única mudança.
A Remoção do Browsable das classes. Realmente eu não sei o impacto dessa mudança. Não cheguei a entender o motivo de ter essa anotação nas classes.

O restante das mudanças está configurado para ser compilado apenas no .Net Core. Pode ser um pouco confuso a princípio, mas eu estou a disposição para ajudar a entender as mudanças.
Se quiser agendar de fazer uma conferência num horário que ficar bom para nós, eu me disponibilizo. Vai ser benéfico pra todo mundo.

Detalhe!!!
Muitas das grandes mudanças são referentes aos 2 projetos de teste que eu adicionei no projeto.
São dois projetos teste que emitem boleto. É só rodar o programinha, preencher os dados e mandar gerar boleto. Esse projeto eu criei para auxiliar nos testes de layout que forem feitos e para melhorar o entendimento de quem quiser implementar o projeto.
Ainda tá bem cru, porém caso meu PR seja aprovado, eu e um amigo estamos interessados em melhorar isso.
Então fora o multi target tem mais essa vantagem.

Para Concluir
Se tiver interesse, eu me disponibilizo de realizar uma call para explicar as mudanças, o que pode ser afetado, aonde estão as partes mais críticas alteradas para alinharmos 100% as idéias.

[carloscds]

@HenriqueTelesOpenline Faca um PR com as implementacoes do .NET Core, ficaremos muito felizes com a sua contribuicao. Lembrando que isto força o projeto a quebrar compatibilidade com .NET Full.

[HenriqueTelesOpenline]

@carloscds Já fiz
É a #343
Não vai quebrar a compatibilidade pq e mantive a compatibilidade com o .Net Atual
Eu deixei multitarget em:
.Net Framework 4.0 (Atual)
.Net Framework 4.8 (LTS)
.Net Standard 2.1
.Net 6.0 (LTS)

Ele quebrou a compatibilidade com a ferramenta de CI/CD por que o agente de build não tinha a sdk pra compilar o projeto

Estou a disposição para ajudar a resolver os impasses

[carloscds]

@HenriqueTelesOpenline Verific o .NET Standard 2.1, ele nao é compatível com o .NET Full.

[HenriqueTelesOpenline]

@carloscds O que seria .NET Full ?
Eu nunca ouvi falar dessa nomenclatura
Na internet não vejo nada falando sobre
Eu só conheço .Net Framework, .Net Core e .Net Standard

[carloscds]

@HenriqueTelesOpenline Ok amigo, vou deixar o @rafd75 seguir com você ok! O owner deste projeto é ele.

[HenriqueTelesOpenline]

Certo @carloscds
Eu posso botar .NET Standard 2.0 se for esse o caso

[carloscds]

@rafd75 Valida com o @HenriqueTelesOpenline

[rafd75]

@HenriqueTelesOpenline

Vamos marcar e conversar a respeito. Mas algumas considerações referente a sua resposta:

• FastReport
O projeto atual já contempla a geração do boleto, utilizando o que veio pronto do BoletoNet.
O Boleto2Net tem 5 anos, e desde então, vem resolvendo o problema dessa forma.
Talvez, a solução de criar uma propriedade que exponha o caminho do logotipo (foi o sugerido na outra issue), sem criar outra dependência (além da NRecoPdf), me parece melhor. (Obs: o outro PR está parado, pq não é só "a propriedade criada" que foi solicitado. Tem uma pancada de ajustes, já citei na mensagem anterior).
Veja, amanhã pode aparecer outro gerador de PDF que é melhor para um grupo de devs, e acabamos criando uma nova responsabilidade no Boleto2Net, que vai além da proposta original, que é ter um código seguro e confiável para gerar boletos.
Quanto ao ajuste (layout), concordo que é mais fácil editar um relatório do que o HTML da forma que foi feito (desde o BoletoNet), mas devemos levar em consideração que essa edição não deve ocorrer de forma rotineira.

• Multitarget
Minha experiência não é avançada neste contexto, e nestes casos, sempre consulto o @carloscds a respeito.
A ideia de ter um mesmo projeto funcionando com o .Net Standard / .Net Core, é uma boa, porém não podemos em nenhum cenário, correr o risco de parar o que está implementado.
Uma premissa que me motivou reescrever o BoletoNet e começar esse Boleto2Net era padronizar as carteiras e bancos, para quem usar, se sentir seguro ao usar. Imagina uma faturamento recorrente (aqui ocorre isso) com 100, 200, 300 boletos emitidos com código errado e enviado por correio para os clientes.) Então, reforço, o objetivo aqui, é oferecer sempre segurança para quem usa o projeto. Mantendo o Boleto2Net na proposta original, é um caminho para isso.
(Sobre "Net Full" => https://www.youtube.com/watch?v=9uTpliQW4MY )

• Projetos de exemplo
Talvez o que precisamos aqui, é melhorar a documentação indicando exemplos do próprio projeto de testes, e a classe "proxy" (essa classe é utilizada para automação OLE através de outras linguagens).

Bom ... dito isso, podemos conversar, mas atente-se aos argumentos já expostos aqui.

[HenriqueTelesOpenline]

@rafd75 Eu entendo sua preocupação. Segurança de que o código não foi quebrado é prioridade máxima.

Aceitar fazer uma reunião no Google meet para alinhar essas questões, se me permitir demonstrar.
Que dia/horário fica bom para você ?

[rafd75]

Tenho uma call agora (18h), que deve durar uns 30/40 min...
logo na sequencia, consigo até umas 19h15/19h30. Não sei se da tempo para demonstrar, mas certamente para resolvermos as questões teóricas.

[HenriqueTelesOpenline]

Pode ser amanhã ?
Hoje eu estou conversando com o pessoal do projeto da NFe (Zeus DFe.Net) pra ajudar a alinhar justamente essas questões de multitarget que fiz lá também.

Tô por conta deles aqui. Analisando se deu algum conflito, testes e tudo mais.

[rafd75]

bom ... Amanhã e sexta, por conta do feriado, dias complicados.
o melhor seria pós expediente... talvez na próxima semana, qualquer dia, por volta das 18h, seja melhor.