Runtime: Port Workflow Foundation para .NET Core

cc: @terrajobst , @joshfree , @weshaggard

Precisamos que o System.Xaml seja aberto antes que um esforço sério possa ser feito na portabilidade.

Eu entendo @jakesays .

O ponto é que o WF pode ter suas definições de fluxo de trabalho feitas em classes C# em vez de XAML (por enquanto) e muitas pessoas nem usam a representação XAML dele. Mais tarde, quando o System.Xaml for aberto, também poderemos integrar o designer visual e as definições de XAML. Além disso, estamos trabalhando em um mecanismo de fluxo de trabalho que segue estritamente o uso/implementação do WF, mas em vez de usar o XAML como armazenamento base para definições de fluxo de trabalho, o temos baseado em Json para a loja, o que abre muitas oportunidades para novos designers de fluxo de trabalho em qualquer plataformas (não apenas VS ou o componente de designer hospedado para WPF/WForms) e têm vários benefícios como leitura/gravação mais rápida, simplicidade de esquema, carregamento/compilação mais rápido e operações de tempo de execução. Ele pode até ser usado para capacitar fluxos de trabalho do cliente, para orientar os fluxos de interface do usuário do aplicativo em aplicativos Windows Phone/Store, por exemplo, devido ao seu tempo de execução leve.

Eu realmente acho que o WF é um componente REALMENTE poderoso na plataforma .Net, mas para as tecnologias atuais, o XAML ainda é um "limitador" dele, mas, se por uma decisão de estratégia do MS, podemos mantê-lo como está e portar para o CoreCLR.

Obrigado

@zhenlan pode falar sobre o pensamento atual em torno do WF

@galvesribeiro muitas pessoas podem não usar xaml, mas muitos usam, e de fato é considerado uma parte central do WF. Usamos xaml extensivamente, então eu veria que WF sem suporte a xaml dificilmente valeria a pena usar.

Eu preferiria continuar pressionando a Microsoft para abrir o System.Xaml.

E usar JSON como substituto não é nem um pouco atraente.

@galvesribeiro @jakesays Gostamos muito de saber o quanto os clientes do WF estão interessados ​​em ter a versão .NET Core do WF, por isso é ótimo ouvir comentários da comunidade. Se houver demanda suficiente, será útil seguirmos em frente.

Estamos no estágio inicial de avaliação da viabilidade, dependências, prioridades de recursos, etc. Portanto, será muito útil para nós saber quais cenários estão em sua mente, por que o WF no .NET Core (vs. WF no .NET completo) será útil para você e quais recursos do WF você gostaria de ver primeiro.

@galvesribeiro Em seu cenário com a construção de fluxos de trabalho em código e armazenando essas definições como JSON, o que você está (planejando?) usando para expressões? Você está usando expressões VB, expressões C# ou tem suas próprias atividades de expressões baseadas em CodeActivity para lidar com expressões?

Obrigado pela contribuição.

@jakesays está tudo bem para mim usar XAML. Só me importo com o desempenho...

@zhenlan Temos um switch de pagamento eletrônico que processa bilhões de transações com cartão de crédito/débito por dia para alguns bancos aqui no Brasil e outros no exterior. Estávamos full on-premises e estamos atualizando a tecnologia para ser totalmente cloud e oferecida como serviço no Azure. Conseguimos um Enterprise Agreement para explorar tudo o que precisamos do Azure aqui como uma plataforma de processamento de pagamentos multilocatário para nossos clientes.

Estamos investigando o uso do NanoServer for e CoreCLR para que possamos reduzir a área de cobertura, a superfície de ataque e a manutenção gasta para executar nossos serviços e notamos que o coreCLR ainda não possui (pelo menos) System.Activities portado. Em outras palavras, não há Workflow Foundation.

Nosso mecanismo de processamento principal é um mecanismo de negócios construído no top WF e contém mais de 40 atividades personalizadas focadas em nossos negócios. Este mecanismo processa em tempo real o processo/regras da transação para obter a aprovação da transação. Precisamos dimensioná-lo sobre a demanda, e faz isso com a implementação atual do WF na nuvem, digamos que não seja viável.

Portá-lo para o .net core, em vez de mantê-lo no .net full (perfil do servidor), abrirá as possibilidades de executar fluxos de trabalho do cliente, isso é algo que realmente sentimos falta em nosso negócio. Esses fluxos de trabalho do cliente podem fazer com que as pessoas desenvolvam a lógica de negócios do cliente declarativa, de forma que pequenos dispositivos como smartphones, wearables, IoT e nossos dispositivos de terminal de pagamento possam tomar algumas decisões sem escrever código repetitivo real.

Como não encontramos nenhum esforço no WF para .net Core, e mesmo que não fosse alterado por anos e ainda dependesse do XAML, decidimos iniciar nosso próprio mecanismo de fluxo de trabalho que se comporta exatamente da mesma maneira que o WF. Mesmo modelo de atividades, mesmo estilo de código, etc, mas muito mais leve e baseado em Json como sua loja de definição. Isso permite que dispositivos com pouca capacidade de computação processem os fluxos de trabalho sem a sobrecarga de lidar com XAML/XML, de modo que a maior parte de nosso código feito para WF funcione sem muitas alterações nas definições de Json em vez de fluxos de trabalho baseados em XAML. Além disso, afastar-se do XAML abrirá a possibilidade de novos designers de fluxo de trabalho... Não ficar preso no Visual Studio e em aplicativos WPF para re-hospedar o designer do VS.

O que estou tentando sugerir é uma dessas opções:

1. Porta WF (com XAML) como está para .Net core. Essas opções levarão muito mais tempo, já que o WF hoje depende do perfil do servidor .Net, o que nos fará gastar muito tempo desacoplando-o para que funcione com o .Net core.
2. Port WF reescrevendo-o para .Net core. Dessa forma, podemos obter os principais conceitos e focar no design de um motor mais leve que possa rodar em servidores, clientes, IoTs ou o que for necessário mantendo os princípios de design e os recursos que estão atualmente implementados no WF. Dessa forma, tornamos um processo realmente pequeno e sem atrito para migrar de XAML para (por exemplo) definições de fluxo de trabalho baseadas em Json. Todas as atividades atuais devem ser portadas para o novo modelo.

Não estou pedindo que você construa uma equipe ou se envolva em um novo produto. A comunidade pode fazer isso como está fazendo para ASP.Net e Entity Framework. Torná-lo um framework externo e auxiliar, não embutido no núcleo.

Obrigado

@jimcarley As expressões seriam compiladas da mesma forma que são hoje em XAML. Em um de nossos workflows temos isso (pode ser um VBValue também, acabei de receber uma amostra):
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

As expressões em XAML hoje, em sua maioria, estão retornando um booleano, ou atribuem algum valor a alguma variável, então isso seria armazenado da mesma forma que é armazenado hoje em XAML, mas em Json e poderia ser compilado seguindo as mesmas ideias que está hoje.

Se você olhar para o Azure Resource Manager (ARM), eles já fizeram isso! Eles têm a implantação de recursos feita como um Json Template, que possui dependências e um fluxo, e as variáveis ​​podem ser chamadas como expressões. Dê uma olhada neste:

"variáveis": {
"location": "[resourceGroup().location]",
"usernameAndPassword": "[concat('parameters('username'), ':', parameters('password'))]",
"authorizationHeader": "[concat('Basic', base64(variables('usernameAndPassword')))]"
}

Ok, eles estão usando funções JavaScript, mas o princípio é o mesmo. Eles possuem uma variável $schema em cima do template que orienta a estrutura do documento, etapas do processo de implantação que podemos fazer como atividades. O design é bastante semelhante ao WF, mas esse DSL se concentra na implantação do grupo de recursos. Podemos torná-lo mais geral e usar as atividades da mesma maneira que na implementação atual do WF.

Se vocês decidirem que vale a pena tentar, podemos começar a desenhar alguma documentação sobre outra questão que guiará a arquitetura do "novo WF". Se isso soa tão louco e fora de seus planos, deixe-me saber, ainda vamos desenvolvê-lo em nosso final para suportar .net core, e lançá-lo mais tarde como uma pepita para as pessoas. Estou apenas tentando atualizar este maravilhoso framework com as tecnologias atuais (próximas). Esta é realmente uma necessidade de negócios para nós. Dependemos muito do WF, mas se ele não ficar mais rápido e suportado no coreCLR, precisaremos começar a preparar esse novo framework para quando o NanoServer+coreCLR for RTM, possamos migrar para ele.

Por favor, deixe-me saber se você tiver alguma dúvida.

Obrigado

PS: Estou nos canais Gitter todos os dias se precisar de chat.

@galvesribeiro Então você está usando o TextExpressionCompiler para compilar as expressões após criar o objeto Activity a partir da definição de workflow que está armazenada no JSON. Direito?

@jimcarley ainda não temos o compilador de expressão funcionando. Ainda o projetamos usando os mesmos princípios do TextExpressionCompiler, mas sim, parece o mesmo conceito. As implementações atuais parecem estar vinculadas ao System.XAML ainda. Como não está aberto, não posso confirmar se funcionará da mesma maneira (internamente) que TextExpressionCompiler, mas sim, após a atividade ser carregada, devemos avaliar/compilar as expressões (se ainda não estiverem em um cache) e expor um objeto Expression nele para ser avaliado pelos consumidores da atividade (se necessário).

No ano passado, fiz alguns trabalhos no lado da expressão para habilitar o suporte à expressão C# em designers de WF auto-hospedados. Foi baseado em pedaços de nrefactory e roslyn. Posso desenterrar se alguém estiver interessado.

@galvesribeiro depois de pensar mais em sua abordagem json, no final acho que realmente não importaria para um novo desenvolvimento. Se o MS não abrir o suporte a xaml, isso pode funcionar.

@zhenlan Concordo com @galvesribeiro em que não estamos necessariamente procurando MS para formar uma equipe para portar WF. Isso é definitivamente algo que a comunidade poderia fazer com a orientação de sua equipe, etc.

@jakesays Eu concordo com você que o armazenamento realmente não importa se estamos criando novamente o WF para o coreclr.

O ponto é, por que continuar usando XML em vez de Json, já que temos muitos testes na web comparando o desempenho de (des)serialização de ambos e o json é muito mais rápido e consome menos recursos do que? (por exemplo, comparando o Json.Net da Newtonsoft com serializador XML regular) Se o WF for executado em um dispositivo cliente pequeno (qualquer IoT), cada byte de memória é importante.

Além disso, com json, é muito mais simples obter novos designers WF baseados na web imediatamente. A compilação e execução da expressão não é difícil de implementar. É aproximadamente um analisador da string para construir o objeto de expressão. A parte difícil (imho) é obter intellisense no VS para os tipos usados ​​ao projetar o WF, mas tenho certeza de que o Roselyn e os serviços de linguagem podem nos ajudar com isso e o VS tem infraestrutura para isso.

@galvesribeiro você mencionou que já construiu seu próprio mecanismo de fluxo de trabalho com definição e serialização de fluxo de trabalho baseada em JSON. Se o WF fosse portado para o Core, você realmente o usaria?

@dmetzgar começamos a desenvolvê-lo e testá-lo como uma prova de conceito de que podemos obter melhores resultados em um WF mais limpo, quase sem dependências do framework, o que é bom para que funcione no coreclr. Não temos pronto.

Eu adoraria não ter que construir meu próprio mecanismo e continuar usando o WF mesmo que seja baseado em XAML, mas portado para coreclr e se seguir o mesmo conceito de versões coreclr de EntityFramework e ASP.Net por exemplo (não dependa de bibliotecas de servidor e roda em todos os lugares).

O ponto é que, se ainda depender do XAML e do perfil do servidor, continuará sendo lento (exigindo muitos recursos), limitado nas escolhas do designer etc.

Minha sugestão é portá-lo para o coreclr usando Json e remover muitas dependências que ele possui hoje, deixando o usuário capaz de executá-lo em qualquer lugar que desejar da mesma maneira que você pode executar o ASP.Net vNext em um dispositivo IoT ARM (assim como suporte ARM está feito!) e não se preocupe com dependências e alto consumo de recursos.

Todos os nossos workflows hoje são criados com a versão atual com alguns deles escritos com código puro e outros com XAML mas em ambos os casos, ainda temos dependências.

IMHO, portá-lo para o coreclr como está, não traz tantos benefícios, a menos que alguém venha com um mecanismo super leve para análise/renderização XAML/XML para tempo de execução e tempo de design. Mas se vocês decidirem portar como está, continuaremos usando de qualquer maneira, pois isso fará com que meus fluxos de trabalho XAML funcionem (espero) desde o dia 0, mesmo que eu saiba que não trará nenhum benefício prático ...

Novamente, eu (provavelmente @jakesays e outros usuários do WF) posso ajudar nesta porta de duas maneiras (XAML ou JSON), independentemente de vocês decidirem. Eu só quero ter certeza de que esta porta não é apenas copiar e colar e corrigir para fazê-la funcionar e, em vez disso, traz realmente benefícios para as pessoas que a estão usando seguindo a mesma ideia do coreclr e pode ser executada em todos os lugares sem problemas.

Obrigado

@galvesribeiro Concordo que o XAML está muito bem integrado ao WF. Voltando ao livro original de Dharma sobre fluxo de trabalho, ele tinha uma amostra que criava um fluxo de trabalho do Visio. Pelo menos com a portabilidade para o núcleo, podemos dividi-lo para que o tempo de execução seja separado do XAML. Isso nos permite continuar com ou sem a portabilidade da equipe XAML para o núcleo e sempre podemos adicionar suporte ao fluxo de trabalho XAML posteriormente como um projeto GitHub/pacote NuGet separado. Definitivamente, sou a favor de tornar possível definir e persistir fluxos de trabalho em qualquer formato. Obrigado, este feedback é útil.

@dmetzgar Não tenho dúvidas de que um dia o XAML será portado para o núcleo ... Se o .net core for executado no Windows Phone ou em qualquer dispositivo móvel Windows 10, isso acontecerá em algum momento e concordo plenamente com você que podemos construir um novo núcleo e adicione a persistência das definições e do estado do fluxo de trabalho posteriormente.

Então, o que precisamos fazer para começar a portá-lo? (já assinamos o contrato de contribuidor e temos outros NDAs como empresa com MS, etc)

Obrigado

@galvesribeiro agradeço o entusiasmo! Por mais tentador que seja abrir um repositório do GitHub e começar a hackear, existem algumas etapas envolvidas. Além disso, não é apenas o System.Xaml que precisa ser esculpido. Existem outras dependências profundamente arraigadas no WF, como System.Transactions e alguns componentes compartilhados com o WCF. Estamos analisando cada um deles.

Compreendo. Bem, eu não quero pressionar vocês, só estou preocupado com o tempo. Temos uma decisão a tomar agora para avançar construindo por conta própria, ou juntar-se à comunidade aqui e portar o WF para o coreCLR para que ele possa cumprir nossa linha do tempo para nosso produto.

@dmetzgar Você considerou publicar as partes que podem ser de código aberto agora para https://github.com/Microsoft/referencesource? Acho que isso poderia ser significativamente mais simples do que criar um projeto de código aberto completo que realmente funcione.

Dessa forma, você pode aproveitar o tempo com a versão adequada e outros podem criar suas próprias versões parciais/personalizadas nesse meio tempo.

Os componentes @svick WF em .NET completos já foram publicados no github referencesource há algum tempo. Por exemplo, você pode encontrar https://github.com/Microsoft/referencesource/tree/master/System.Activities

@zhenlan sim, o problema com isso é que algumas dependências não são "resolvíveis"... Não consigo ver qual é o comportamento de algumas classes corretamente, devido à sua dependência do System.Xaml que não é público...

Sempre podemos descobrir até o nosso fim, mas isso significa que não sabemos ao certo se estamos seguindo o mesmo caminho.

@dmetzgar System.Transaction é algo que não está aberto (ainda?), mas acho que podemos lidar com isso (por enquanto). Em relação ao WCF, a árvore de dependências me mostra apenas atividades e o host de serviços de fluxo de trabalho. Nada no núcleo (IIRC) depende do WCF...

@galvesribeiro A situação com System.Transactions é mais complexa que isso. Ele é espalhado por todo o tempo de execução do WF e depende muito da instância durável, que é onde as classes base estão para persistência. WCF e WF foram fundidos na mesma equipe por volta do período de tempo do .Net 4.0, então temos coisas como System.ServiceModel.Internals usadas tanto pelo WCF quanto pelo WF. O .Net core tem muitas das grandes coisas portadas, mas há muitas coisas que estão faltando. Trabalhar em torno de peças ausentes pode exigir alterações de design ou reescritas de recursos.

Nenhum desses problemas é intransponível, só não quero banalizar o esforço. Isso vale para o código e tudo ao seu redor, como obter aprovação legal, criar ambientes, testar infraestrutura etc. Definitivamente, queremos que a comunidade ajude e estamos trabalhando para isso. Se você deve escrever sua própria porta ou esperar pela "oficial" depende do seu prazo. A execução de fluxos de trabalho no servidor Nano é um dos nossos maiores cenários e adoraria receber sua ajuda.

@dmetzgar eu entendi, sempre tinha algum atraso quando qualquer pergunta tinha que ser encaminhada para PR ou Jurídico quando eu estava do seu lado :)

Bem, se ao menos tivermos uma noção de algum prazo, podemos nos preparar e esperar. Eu odeio a ideia de implementar algo "no lugar errado" ou quando já existem alguns esforços sendo gastos em algum lugar onde podemos unir forças para fazer melhor.

Por favor, deixe-me saber se há algo que possamos fazer, ou se você tiver alguma notícia, ou me envie um ping se precisar de alguma sugestão sobre o design/porta.

Obrigado

À medida que o prazo ficar mais claro, farei atualizações neste tópico. Eu ficaria feliz em saber quais outros cenários as pessoas estão interessadas. WF no Nano é o cenário principal no momento, mas seria bom saber o que os outros estão fazendo.

Olá pessoal, além de XAML e JSON, existe uma forma LEGAL de compor atividades: metaprogramação. Dê uma olhada no meu projeto experimental: Metah.W: A Workflow Metaprogramming Language (https://github.com/knat/Metah).

@jakesays Você pode fornecer algumas orientações sobre como habilitar o suporte à expressão C# no WF auto-hospedado.

Por favor, mantenha Xaml. :) Objetos serializados JSON também seriam interessantes. Mas eu preferiria ver provedores configurados de alguma forma no framework para escolher o formato preferido.

@dmetzgar (e outras pessoas da MSFT) há alguma notícia sobre esse assunto?
Obrigado

Estamos trabalhando nisso e avançamos muito. No momento, o XAML não está disponível no Core, portanto, estamos nos concentrando no tempo de execução. Estamos analisando a abertura para outros serializadores. Portanto, em vez de escolher lados entre JSON ou XAML, preferimos permitir que você traga seu próprio serializador. Ainda há mais conformidade e coisas legais para serem aprovadas. Como não há muitos clientes pressionando por essa porta, ela tem sido uma prioridade mais baixa.

@dmetzgar querida! Eu ficaria mais do que feliz em contribuir para isso da maneira que eu puder se isso se tornar um projeto principal... seja um designer de fluxo de trabalho da Web etc. Parece que o xaml dificilmente precisa estar lá para o formato de definição... animado para ouvir sobre este trabalho!

Olá pessoal, feliz natal e feliz ano novo!

Então, temos alguma atualização nessa porta ou pelo menos a versão OSS do trabalho atual para que possamos ajudar?

Obrigado

@galvesribeiro Vou tentar explicar a situação da melhor forma possível. Em meu zelo para fazer a portabilidade do WF para o .NET Core, não levei em conta o lado comercial dessa coisa toda. WPF/XAML não é portado para .NET Core e isso representa uma parte significativa do WF. Embora o XAML não seja essencial para o tempo de execução, é como a maioria dos clientes cria fluxos de trabalho. Isso limita o público que consideraria útil o WF no Core. Um dos medos é que liberemos o WF no Core e não haja muito envolvimento da comunidade. Isso aumenta nosso custo de suporte e não melhora a situação da maioria dos clientes do WF. Embora seja legal ver o WF rodando em uma máquina Linux, é difícil provar que alguém realmente o usaria.

Estou ciente do OmniXAML e conseguimos convencer o autor a mudar para uma licença MIT. Portanto, com algum investimento, poderíamos fazer o XAML funcionar. Mas ainda há a questão de como isso beneficia os clientes WF existentes. Se um dia um grande cliente como o SharePoint ou o Dynamics aparecer e disser que está migrando para o Nano, teremos um caso convincente. Mas isso é discutível se a equipe do .NET Framework decidir fazer um pacote que possa executar o framework completo no Nano.

Se houvesse bastante interesse da comunidade e alguém disposto a defender o projeto, poderíamos tentar fazê-lo dessa maneira. Tipo como Open Live Writer. A parte complicada é que, embora minha equipe contribuísse para isso o máximo possível, esse tipo de projeto não viria com suporte da Microsoft. Suspeito que a maioria dos clientes do WF use o WF principalmente porque a Microsoft oferece suporte a ele.

Acho importante destacar que o .NET Core e o .NET Framework completo são dois produtos diferentes. O .NET Framework não está morrendo de forma alguma. Continuaremos a oferecer suporte, adicionar recursos etc. Portanto, não é como se tivéssemos que portar o WF para o .NET Core para mantê-lo ativo. WF no Core seria basicamente um novo produto. Chegar a uma justificativa de negócios sólida é difícil. Pode até ser uma questão de tempo. À medida que mais empresas adotam servidores Nano, pode haver um caso mais forte.

@dmetzgar Que tal Portable.Xaml, poderia ser uma alternativa? https://github.com/cwensley/Portable.Xaml Foi extraído para uso pelo autor do fantástico projeto Eto.Forms para Eto. É licenciado pelo MIT e (assim como as bibliotecas de classe das quais deriva no projeto mono).

@dmetzgar ,

Vou tentar explicar a situação da melhor forma possível. Em meu zelo para fazer a portabilidade do WF para o .NET Core, não levei em conta o lado comercial dessa coisa toda. WPF/XAML não é portado para .NET Core e isso representa uma parte significativa do WF. Embora o XAML não seja essencial para o tempo de execução, é como a maioria dos clientes cria fluxos de trabalho. Isso limita o público que consideraria útil o WF no Core. Um dos medos é que liberemos o WF no Core e não haja muito envolvimento da comunidade. Isso aumenta nosso custo de suporte e não melhora a situação da maioria dos clientes do WF. Embora seja legal ver o WF rodando em uma máquina Linux, é difícil provar que alguém realmente o usaria.

Acho que a maior motivação para os usuários atuais do WF é o servidor Nano e Micro Services e não o Linux. Linux irá adicionar mais usuários, mas não é a verdadeira motivação.

Mas ainda há a questão de como isso beneficia os clientes WF existentes.

Estamos em dias de nuvens. Lembre-se, "Cloud first, mobile first..." e uma das grandes tecnologias que estão crescendo são containers, Micro Services, e uma grande oferta da MS por tudo que é Nano Server.

Se um dia um grande cliente como o SharePoint ou o Dynamics aparecer e disser que está migrando para o Nano, teremos um caso convincente.

Mesmo com a maior implantação de Sharepoint ou Dynamics do mundo, nunca alcançaremos o mesmo número de usuários e eu diria até o mesmo nível de receita do que o que está sendo feito com tecnologia em nuvem.

Mas isso é discutível se a equipe do .NET Framework decidir fazer um pacote que possa executar o framework completo no Nano.

O DNX hoje (até o RC1) é composto não apenas pelo coreCLR. Ele também tem a estrutura completa (dnx451) para que possamos usar atualmente o WF no DNX e isso não é sobre o problema aqui. Estamos falando do coreCLR (dnxcore50)

Se houvesse bastante interesse da comunidade e alguém disposto a defender o projeto, poderíamos tentar fazê-lo dessa maneira. Tipo como Open Live Writer.

Não compararia com o que foi feito no Open Live Writer... Acho que é mais ou menos o que foi feito com ASP.Net, MVC, Entity Framework. Core "produtos" da família .Net e que hoje é open source.

A parte complicada é que, embora minha equipe contribuísse para isso o máximo possível, esse tipo de projeto não viria com suporte da Microsoft. Suspeito que a maioria dos clientes do WF use o WF principalmente porque a Microsoft oferece suporte a ele.

Na verdade, os clientes WF usam contratos de suporte da MS... Especialmente os clientes Dynamics e Sharepoint fazem isso, no entanto, existem muitos aplicativos fora deste mundo que ainda precisam de suporte. Dizer que as pessoas só usam por causa do suporte e o OSS não é suportado, é quase o mesmo que dizer que CoreCLR, EF, ASP.Net não terão suporte do MS. Embora esses projetos sejam OSS agora, eles são fortemente monitorados e moderados por equipes de MS.

Por exemplo, comecei como usuário no projeto MS Orleans. Ele alimenta todos os serviços de nuvem Halo por quase 7 anos. Skype, Outlook e muitos outros serviços públicos/nuvem da MS fazem uso dele de alguma forma. Alguns anos atrás, foi OSSed da MS Research e agora é mantido pela 343 Studios, algumas pessoas da MSR e outras de outros grupos dentro da MS, mas principalmente mantida pela comunidade. Hoje, eu me considero um colaborador ativo desse projeto e dou suporte a novos usuários junto com outras pessoas de MS e não MS lá. Temos até ex-funcionários (como eu) e não-MS dentro da equipe do GH para Orleans. Isso significa que não temos suporte? Bem, eu não comprei Orleans, então peço legalmente suporte dentro de meus contratos com a MS para Orleans especificamente, no entanto, posso fazer isso segmentando o framework .Net ou qualquer outro produto relacionado, então não concordo com sua afirmação.

Chegar a uma justificativa de negócios sólida é difícil.
Concordo com você se você procurar apenas clientes do Sharepoint e Dynamics.

Bem, nós, como muitas outras empresas ao redor do mundo, mantemos grandes Enterprise Agreements (EA) com a Microsoft usando a maioria dos produtos variáveis ​​nesses contratos. No nosso caso, processamos milhões de transações financeiras (cartão de crédito/débito) por dia e cada uma representa uma instância de um WF rodando no Orleans e dentro do Microsoft Azure. Não sei o que seria grande para você para servir de justificativa comercial.

Eu só acho que o core(System.Activities), sem XAML, poderia ser portado para coreCLR e designers poderiam ser criados sob demanda para XAML, Json, HTML, XML, qualquer coisa. Ao desacoplar essa dependência, outras possibilidades são abertas.

Como eu disse no início deste tópico, o trabalho mais pesado que queremos agora, é colocá-lo em OSS e alguém (pelo menos inicialmente) da MSFT, se tornar disponível para revisar o PR. O senso comum aqui é reescrever o WF e não apenas copiá-lo e colá-lo para o coreCLR, então esperamos grandes contribuições sobre isso.

Se isso é algo que não vai acontecer, acho que podemos fechar esse problema e pelo menos as pessoas começarão a procurar outros OSS ou até mecanismos de fluxo de trabalho pagos que eventualmente terão suporte ao CoreCLR. Só acho que é uma grande perda não ter dentro do CoreCLR...

Posso dar uma razão muito forte pela qual o WF deve ser portado para .Net Core.

A Microsoft está conduzindo os desenvolvedores para a plataforma UWP. UWP será a plataforma Windows do futuro. Não tem nada a ver com a ideia de portar aplicativos para Linux etc. há uma grande necessidade de ter o WF rodando em máquinas Windows 10, e UWP é o futuro para a plataforma Windows 10.

Criamos aplicativos ocasionalmente conectados. Temos um back-end .Net e um front-end UWP. Atualmente, toda a lógica de negócios é compartilhada entre .Net e UWP. Mas gostaríamos de codificar a lógica de negócios no WF. Isso funcionará bem no .Net, mas o WF não é atualmente suportado pelo UWP, portanto, o WF se torna inútil porque, a menos que o usuário esteja conectado à Internet, ele não poderá fazer chamadas validadas pela lógica do WF.

UPW tem um XamlReader, então analisar XAML não é realmente um grande problema...

@MelbourneDeveloper concorda com você com todos os motivos, no entanto, lembre-se de que UWP e .Net Core (pelo menos agora) não estão sob o mesmo apelido, o que significa que mesmo eles compartilhando as mesmas APIs de nível inferior, tendo a mesma superfície de API (e . Net Core é OSS enquanto UWP não é), eles não são a mesma coisa e não são compatíveis. Em outras palavras, você não pode adicionar um assembly .Net Core a um UWP. Essas diferenças (IMHO) acabarão por se livrar, mas por enquanto elas ainda existem ...

sim. Entendido. Foi com a suposição de trabalho que essas duas coisas serão reunidas no futuro. Se não forem, Deus nos ajude!

Além disso, o Xaml do UWP do @MelbourneDeveloper é uma versão completamente diferente e simplificada do Xaml do .NET. O UserVoice do WindowsDev está repleto de votos (o que continua a ser ignorado, como em tudo o que parece UWP - é de se admirar por que eles ainda têm um UserVoice) para melhorar seu sistema Xaml:
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9523650-add-support-for-xmlnsdefinitionattribute

Espero que eles façam a coisa certa e se unam atrás da porta Mono Xaml de @cwensley e/ou OmniXaml como sugerido. O sistema Xaml da UWP, como está, é realmente uma piada e é parte do motivo pelo qual sua taxa de adoção é tão terrível.

Junto com essa nota, tenho um caso de uso de negócios para os MSFTies considerarem: NodeJS. Quanto mais todos nós coçamos nossas bolas coletivas sobre esse problema, mais valor o NodeJS acumula valor no mercado, pois é verdadeiramente multiplataforma e verdadeiramente onipresente, algo que a tecnologia MSFT simplesmente não pode reivindicar no momento (ou no futuro próximo). O NodeJS funciona no servidor e no cliente (TODOS ELES) e permite a reutilização de código entre os dois. Uma base de código funcionará em cenários nativos (via Cordova) e web (via navegador HTML5 padrão), o que é muito mais barato do que você teria que fazer com uma solução baseada em MSFT.

Em breve chegará ao ponto em que refazer um sistema no NodeJS e abandonar completamente o MSFT se tornará mais palatável (e obviamente menos caro) do que esperar por (o que parece) equipes disfuncionais para acompanhar as realidades econômicas do mercado.

Também menciono isso, pois é mencionado que parece que a MSFT está contando com UWP para sua plataforma de cliente, mas atinge uma fração do mercado que o NodeJS faz. E quando digo fração, pode ser exagero. Estamos falando de 200 milhões (última contagem de instalação conhecida do Windows 10) vs ~ 3B (BILHÕES) de dispositivos que os aplicativos baseados em nodejs podem alcançar.

Não me interpretem mal aqui, eu amo MSFT. Investi mais de 15 anos da minha vida com suas tecnologias e estou completamente investido aqui, pessoalmente. No entanto, com esse investimento vem a paixão de ver todos acertarem e se orgulhar das decisões e dos esforços feitos aqui com a nova era de código aberto e grandiosidade entre plataformas. Eu também quero que todos estejam cientes da ameaça do mercado que está se aproximando (e também talvez para verificar/confirmar meus medos).

Finalmente, se tudo correr bem, temos outro grande problema com nosso estado atual de Xaml multiplataforma, já que Portable.Xaml é diferente de OmniXaml, então em algum momento nós, como comunidade, teremos que descobrir como reconciliar os dois bases de código... idealmente. :)

@Michael-DST concorda com você em todos os pontos. Um dos alvos para os quais queremos que o WF seja executado são os clientes (especialmente móveis e incorporados). Queremos reduzir o código do cliente para regras de negócios locais adicionando WF nele. Por clientes, não estou falando estritamente sobre UWP como dispositivos Windows (telefone, tablets e IoT) ...

Eu acredito que existem produtos importantes que dependem do WF, como o BizTalk e o Sharepoint, mas eles ainda podem confiar na versão completa do .Net, enquanto as pessoas no .Net Core (e mais tarde UWP) podem confiar nas novas APIs WF/XAML. Eu sei que isso implicará muitos #ifs na base de código, mas esse será o caminho a seguir ...

@galvesribeiro agradece a verificação/suporte. Parece que estou patinando morro acima às vezes, pois ninguém parece reconhecer esse problema muito real (existencial?) enfrentado pelo .NET. Na verdade, a liderança do .NET está ajudando a agravar esse problema ao recomendar o pareamento do .NET com o AngularJS para aplicativos da Web, basicamente desafiando as organizações a mudar para o NodeJS! (divulgação completa, eu escrevi isso. :P).

Hesito em postar muito aqui sobre NodeJS, já que o WF é mais uma tecnologia do lado do servidor, mas do jeito que eu (e outras organizações estão começando a) vê-lo, isso afeta todas as esferas e ameaça o .NET em todos os aspectos. É simplesmente mais econômico (e eficiente no alcance do mercado) usar o NodeJS como uma pilha de soluções no momento e estamos (novamente, odeio me repetir - mas não realmente) vendo isso refletir nas organizações por sua tecnologia de escolha.

Resumindo: eu tenho que colocar minha angústia _em algum lugar_ e este segmento é a vítima. :P #desculpanãodesculpa

Sobre #if defs... eca, vou citar o Manifesto MvvMCross aqui: "# é para twitter, não para código." :P

FINALMENTE, esqueci de marcar @SuperJMN , pois ele também deve estar ciente deste tópico/discussão (como o autor do OmniXaml) - sem desrespeito, cara! Estarei lidando com o problema OmniXaml vs. Portable.Xaml pessoalmente na próxima semana.

@Michael-DST sim... Na verdade, o #if é apenas uma maneira... A equipe do .Net Core adotou a abordagem de "Native Shims", onde a implementação real (específica do SO) é abstraída em uma fina camada inferior de código nativo. No caso do WF pode ser um shim para .Net Full e outro para .Net Core por exemplo...

Não sou fã de Node.js e nem de JavaScript (costumo pensar que ainda é uma linguagem de script, não de programação, mas é minha opinião), mas tenho que concordar que hoje em dia, nada se compara a isso em termos de xplat. A própria Microsoft o usa para seus agentes de compilação no VSTS (apenas para citar 1 caso, existem outros no MS), pois é executado em qualquer plataforma, por exemplo ...

Eu acho que o WF é uma peça incrível de tecnologia, cuja versão atual foi feita para ser usuários no lado do servidor, no entanto, com .Net Core, e pode perfeitamente nos clientes também ...

@galvesribeiro ... estou com você 100%. O EF Core 1.0 é da mesma forma... uma tecnologia tradicionalmente do lado do servidor que agora também pode ser usada no lado do cliente. Seria muito útil ter o WF disponível dessa maneira também.

Além disso, é bom ouvir sobre os calços. Muito aprova. :)

Finalmente, não quero desviar/sequestrar o tópico (muito) aqui, mas com certeza re: JavaScript: estou de acordo como linguagem de script. No entanto, também é uma "linguagem" muito flexível que pode ser utilizada em outras formas, principalmente em código de byte (ish). Como tenho certeza que você já viu, existe a mágica do compilador LVVM para C++. A demanda crescente/popular na comunidade de desenvolvedores .NET é fazer o mesmo para .NET (transpile .NET em JS em uma capacidade oficial). Isso realmente corrigiria todos os males atuais (principais) no atual clima de desenvolvedores da MSFT.

De qualquer forma, de volta à sua programação regular. :P Obrigado pelo diálogo e pensamentos!

Vocês estão tocando em algumas coisas com as quais tenho lidado há 9 anos. Há algo que muitas pessoas que trabalham com tecnologias da Microsoft não entendem; ou seja, o conceito de computação distribuída. Um requisito fundamental do nosso software desde o início é que ele funcione ocasionalmente no modo conectado. Com o tempo, a Microsoft fez várias tentativas para fornecer ferramentas para isso, mas nenhuma estrutura abrangente foi desenvolvida. Temos um pouco de estrutura de sincronização aqui, um pouco de banco de dados LINQ ali, mas nenhum conjunto de ferramentas abrangente para fazer tudo funcionar em conjunto.

Nos últimos 9 anos, desenvolvemos nossa própria estrutura ocasionalmente conectada. Ele agora é executado em .Net, Silverlight e UWP. Tentamos muito aproveitar as estruturas da Microsoft como EF e WF, mas nenhum suporte foi oferecido para essas tecnologias em plataformas de tecnologia de cliente como Silverlight. Nós literalmente construímos nosso próprio ORM e estrutura de sincronização para Silverlight que agora é compatível com UWP.

Quando havia muito burburinho em torno do WF em primeiro lugar, era bastante empolgante porque oferecia uma maneira de codificar a lógica de negócios sem código. Mas, com o passar do tempo, fiquei cada vez menos inclinado a pensar que algum dia haveria uma porta para uma tecnologia do lado do cliente como o Silverlight. Eu postei várias perguntas sobre isso em fóruns, mas a resposta sempre foi a mesma: WF é uma tecnologia do lado do servidor, por que você quer usá-la no Silverlight?

Como disse o galvesribeiro

"Eu acho que o WF é uma peça incrível de tecnologia, cuja versão atual foi feita para ser usuários no lado do servidor, no entanto, com .Net Core, e pode perfeitamente nos clientes também..."

E

"Um dos alvos para os quais queremos que o WF seja executado são os clientes (especialmente móveis e incorporados). Queremos reduzir o código do cliente para as regras de negócios locais adicionando o WF nele. Por clientes, não estou falando estritamente sobre UWP como dispositivos Windows (telefone, tablets e IoT)"

O que as pessoas precisam entender é que, quando se trata de computação distribuída, não há distinção entre tecnologia de cliente e de servidor. Pense na maneira como o Git funciona. O código para o Git é o mesmo, independentemente de você estar olhando para o repositório central ou para um nó na rede em algum lugar. O código é duplicado em todos os lugares. É a mesma coisa com o nosso framework. A lógica de negócios é duplicada em todos os nós. Isso porque mesmo que o usuário não esteja conectado à rede, ele ainda precisa estar sujeito à mesma lógica de negócios. Na computação distribuída, cada computador é literalmente um servidor. Ele literalmente executa o mesmo código que o servidor.

Nunca conseguimos aproveitar o WF, porque não podíamos executar o código do WF no Silverlight e agora não podemos executá-lo no UWP. É encorajador ver o EF sendo portado para UWP. Talvez este seja o começo da Microsoft entender que a computação distribuída é uma necessidade. Mas a Microsoft precisa aderir à computação distribuída e incluir o WF como parte de toda a estrutura de computação distribuída. Talvez então possamos excluir nossa estrutura de computação distribuída e não terei mais que manter esse código.

Perspectivas e pensamentos realmente ótimos @MelbourneDeveloper. Obrigado por compartilhá-los. Eu também era um grande fã do Silverlight e tenho andado com ele desde então (daí meu voto resultante e - realmente - site acima). Além disso, estou curioso para saber o que você acha dos Serviços Móveis do Azure e se você considerou usar isso em sua história offline? Eu sou um novato com computação distribuída (mas entenda o que você tem a dizer), mas estou realmente querendo entrar nisso no próximo ano (também estou ouvindo muitos microsserviços, que acredito ser o equivalente mais recente disso?) .

O que as pessoas precisam entender é que, quando se trata de computação distribuída, não há distinção entre tecnologia de cliente e de servidor.

Ponto muito bom. Neste ponto, é tudo sobre onde a tecnologia está hospedada. Ou seja, você está realmente limitado pelo host da tecnologia que está tentando "distribuir", eu diria (e novamente não sou especialista nisso). Quanto mais onipresente (ou prontamente disponível) for o host, melhor distribuído/acessível será o aplicativo. Annnnnd... Acho que você sabe onde quero chegar com isso. :P

De qualquer forma, parece que estamos todos concordando em _alguma coisa_ aqui com esta discussão e isso é uma mudança/realização bem-vinda para mim. ;)

@galvesribeiro

tenha em mente que UWP e .Net Core (pelo menos agora) não estão sob o mesmo apelido, o que significa que mesmo eles compartilham as mesmas APIs de nível inferior, tendo a mesma superfície de API (e .Net Core é OSS enquanto UWP não é) , eles não são a mesma coisa e não são compatíveis. Em outras palavras, você não pode adicionar um assembly .Net Core a um UWP. Essas diferenças (IMHO) acabarão por se livrar, mas por enquanto elas ainda existem ...

Dê uma olhada neste PR dotnet/corefx#5760, espero que isso esclareça algumas coisas.

O lado .NET do UWP _is_ .NET Core. No entanto, o .NET Core fornece vários tempos de execução. A UWP usa o tempo de execução baseado em AOT, portanto, certas funcionalidades que exigem um JIT não são suportadas (como LCG ou RefEmit). No entanto, eles compartilham os mesmos assemblies e (continuando) os mesmos pacotes NuGet. Projetamos especificamente a pilha para permitir assemblies de referência cruzada (e pacotes) de UWP e ASP.NET Core.

Claro, há ferramentas VS em cima dessas chamadas bibliotecas de classes portáteis (PCL) que tentam ajudá-lo a construir bibliotecas que funcionarão em um conjunto de plataformas. Há várias opções que você pode fazer na caixa de diálogo de direcionamento de PCL que resultam em seu binário ser compatível com .NET Core. No entanto, como a portabilidade no VS é determinada observando as plataformas, você não poderá fazer referência a um PCL de um aplicativo UWP, a menos que esse PCL diga que pode direcionar o UWP. Esse comportamento é próprio do projeto porque a ideia é que o conjunto de ferramentas PCL ajuda você a não usar acidentalmente a funcionalidade que não tem suporte em todos os lugares em que você precisa executar. Por outro lado, você só pode fazer referência a PCLs de plataformas que ele diz que tem como alvo.

Já que você menciona explicitamente os apelidos, vamos falar sobre isso por um segundo também. O design de um moniker (TFM) é que ele representa a totalidade da área de superfície. Em nossas ferramentas existem dois apelidos:

• TargetPlatformMonikers (TPM)
• TargetFrameworkMoniker (TFM)

Pense no TFM como identificando a totalidade da área de superfície gerenciada, in-box, enquanto o TPM representa o SO subjacente, ou seja, o conjunto de API fornecido pelo SO.

Como projetamos o .NET Core para ser portátil para várias plataformas, um TFM tradicional não faz muito sentido. É por isso que existe um novo conceito, chamado Standard Platform , anteriormente chamado de gerações.

Isso ajuda?

No entanto, eles compartilham os mesmos assemblies e (continuando) os mesmos pacotes NuGet.

A maioria dos assemblies tem a mesma DLL de implementação BINARY para aplicativos de destino NuGet 'netcore50' (Aplicativo de armazenamento UWP do WIndows) e 'dnxcore50' destino NuGet (ASP.NET v5 / ASP.NET Core 1.0).

No entanto, alguns pacotes NuGet, como muitos dos pacotes de biblioteca System.Net.*, têm implementações diferentes para o destino 'netcore50' versus o destino 'dnxcore50'. Por exemplo, a biblioteca System.Net.Http com 'netcore50' usa a implementação do WinRT Windows.Web.Http abaixo. A implementação 'dnxcore50' usa outra coisa (WinHTTP nativo).

No entanto, alguns pacotes NuGet, como muitos dos pacotes de biblioteca System.Net.*, têm implementações diferentes para o destino 'netcore50' versus o destino 'dnxcore50'

Sim, eu deveria ter mencionado isso. A maneira como vejo isso é que um pacote NuGet fornece um contêiner que permite ao produtor fornecer diferentes implementações para diferentes ambientes de execução, enquanto os consumidores não precisam saber disso. Nesse sentido, os pacotes NuGet são os novos assemblies.

Obrigado @terrajobst e @davidsh por compartilhar essa explicação mais profunda e questão de referência, mas o que há de errado com o que eu disse que "1 assembly de uma plataforma não pode ser referenciado por outra"?

A maneira como vejo isso é que um pacote NuGet fornece um contêiner que permite ao produtor fornecer diferentes implementações para diferentes ambientes de execução, enquanto os consumidores não precisam saber disso. Nesse sentido, os pacotes NuGet são os novos assemblies.

Esse conceito na verdade não é novo... As pessoas já criam um pacote Nuget que nada mais é do que uma referência a vários outros pacotes - os chamados "meta pacotes". Existem várias maneiras de fazer um PCL funcionar em muitas plataformas. Os mais famosos usados ​​por muitas bibliotecas populares (como o Json.Net da Newtonsoft) são Bait e Switch , onde você tem um nuget que possui uma interface pública (a superfície da API) e um assembly para cada plataforma específica (a implementação real da superfície da API) que podem até ter dependências de diferenças entre si e em tempo de execução, o assembly correto para essa plataforma será selecionado. A diferença agora é que em vez de ter vários nugets "dentro" de um único nuget de contêiner onde todos devem estar na mesma plataforma ou 1 assembly de interface que é usado apenas pelo desenvolvimento e que mudará para o específico em tempo de execução, temos uma mistura disso! 1 nuget que é um contêiner e ao mesmo tempo a interface pública para todos os nugets específicos da plataforma vinculados a ele.

Acho que estamos falando a mesma coisa, só me expressei mal em primeiro lugar :smile:

Enfim, voltando ao WF... Acho que é notório que as pessoas querem tê-lo portado para o WF não apenas "porque é legal" rodar no linux ou no Nano Server. As pessoas querem usá-lo de forma leve nos clientes também.

Mais uma vez, acho que tem bastante gente da comunidade querendo fazer esse port acontecer...

PS: Para aqueles que estão interessados ​​em computação distribuída (o real, não a história do cliente offline), por favor, dê uma olhada em nosso outro projeto Orleans , que na verdade é um bom caso de uso para WF em .Net Core e que capacita hoje grandes serviços da Microsoft como Skype, Halo5, e que eu pessoalmente uso como minha tecnologia principal da minha plataforma de processamento de transações financeiras que processa bilhões de transações de forma distribuída...

@galvesribeiro

o que há de errado com o que eu disse que "1 assembly de uma plataforma não pode ser referenciado por outra"?

Não é que sua afirmação esteja errada; é só que também não está certo :smile: Normalmente, eu não sou o tipo de pessoa que gosta de criticar, mas o que me surpreendeu foi esta parte:

Em outras palavras, você não pode adicionar um assembly .Net Core a um UWP.

Quero evitar dar a impressão de que UWP e .NET Core são plataformas .NET diferentes, como .NET Framework e Silverlight eram. Projetamos especificamente o .NET Core para que você possa criar assemblies que funcionem em todas as plataformas. Por exemplo, System.Collections.Immutable e praticamente todos os Roslyn são assemblies .NET Core que também funcionarão bem em UWP.

Para reformular: nosso objetivo é construir uma plataforma onde componentes simples baseados em MSIL possam literalmente usar o mesmo binário em todas as plataformas baseadas em .NET Core. Nos casos em que isso não é possível, por exemplo, devido a dependências nativas ou implementações diferentes, estamos fazendo exatamente o que Paul Betts descreveu tão eloquentemente como Bait and Switch PCLs : área de superfície portátil, implementações variadas por plataforma e NuGet como o contêiner e seletor.

No mundo .NET Core, as bibliotecas System não são realmente especiais. Qualquer um pode usar a mesma técnica para garantir que a maioria dos consumidores não tenha que encher sua base de código com diretivas #if .

Acho que estamos falando a mesma coisa, só me expressei mal em primeiro lugar :smile:

Acho que criamos um mundo onde é um pouco fácil demais confundir as pessoas -- o que obviamente nos inclui :smile: É por isso que me esforço tanto para ser preciso sobre como o .NET Core foi construído e quais problemas tentamos resolver.

Sim você está certo. A impressão é o que importa.

Espero que algum dia nós também chamemos .Net Core na UWP para que isso acabe... Então, ainda precisamos de system.xaml

Embora relacionado, acho que System.Xaml é um componente separado que agrega valor por si só. Eu arquivei dotnet/corefx#5766 para rastrear isso separadamente.

Obrigado Michael-DST

Além disso, estou curioso para saber o que você acha dos Serviços Móveis do Azure (https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/) e se você considerou usar isso em sua história offline?

Excelente pergunta. Isso traz uma lição de história sobre a experiência de nossa empresa com computação distribuída, também conhecida como aplicativos ocasionalmente conectados, e como isso se relaciona com os Serviços Móveis do Azure e a computação distribuída com a tecnologia da Microsoft.

Se as pessoas não viram o site mencionado acima, recomendo fortemente que o vejam. Tem um bom vídeo sobre os Serviços Móveis do Azure.

Cerca de 8 anos atrás, criamos um aplicativo para a plataforma Windows Phone original. A velha escola com .Net Compact Framework. As pessoas podem zombar disso, mas em alguns pontos-chave essa plataforma era mais avançada do que a plataforma UWP atual em relação à tecnologia ocasionalmente conectada. Embora pareça que a UWP está se recuperando. As chaves para o sucesso de aplicativos ocasionalmente conectados nessa plataforma foram:

1) Implementação completa do Banco de Dados SQL (SQL Server CE)
2) Implementação do Sync Framework entre SQL Server (backend) e SQL Server CE (dispositivo móvel). Este era o Sync Framework versão 1.

Este aplicativo foi bem sucedido. Escrevemos uma camada de dados sobre o SQL CE superior e o SQL Server que foi implantado no servidor e implantado nos dispositivos. Quase estourou a memória, mas funcionou. Os trabalhadores de campo foram capazes de fazer a captura de dados em campo, e os dados foram sincronizados de volta ao banco de dados central.

Ficamos horrorizados quando o Windows Phone 7 foi lançado porque havia um problema crucial: todos os bancos de dados no mercado eram bancos de dados não SQL. Eles foram implementados principalmente com LINQ. Isso não era compatível com nossa camada de dados e o EF não existia para o Windows Phone 7. Portanto, não conseguimos criar uma estrutura ocasionalmente offline para o Windows Phone 7, embora tenhamos conseguido criar uma solução completa para o original Plataforma Windows Phone.

Silverlight foi um divisor de águas. Novamente, encontramos um banco de dados SQL completo. Mas a Microsoft não implementou a estrutura de sincronização para o Silverlight ou para o banco de dados embutido em questão. Então, começamos a escrever nossa própria estrutura de sincronização modelada após a estrutura de sincronização da Microsoft. A estrutura de sincronização da Microsoft é baseada em carimbos de data/hora. Isso é o que implementamos em nossa estrutura de sincronização. Novamente, tivemos sucesso total com o Silverlight. Os trabalhadores de campo puderam levar tablets Windows para o campo, capturar dados e depois sincronizá-los de volta com o banco de dados central. O problema é que isso nunca está disponível para telefones. A plataforma de banco de dados não existia para o Windows Phone 7.

Como mencionei anteriormente, queríamos implementar a lógica de negócios com o WF, mas o Silverlight foi abandonado e ninguém sequer falou da possibilidade de portar o WF para o Silverlight.

Por fim, chegamos à UWP. Um wrapper para SQLite foi escrito para UWP e, com alguns hacks para o wrapper, consegui estender a interface com SQLite para nos permitir trabalhar novamente com um banco de dados SQL completo. Isso significa que nossa camada de dados é compatível com ela. Nossa camada de dados e camadas de sincronização agora funcionam em .Net, Silverlight e UWP, com SQL Server, SQLite e outra plataforma de banco de dados sem nome.

Hoje é a primeira vez que vejo qualquer sincronização ocorrendo com a tecnologia pura da Microsoft, graças ao Michael-DST. Basicamente, posso dizer que a sincronização dos Serviços Móveis do Azure é apenas o Microsoft Sync Framework renomeado. Ele tem uma interface de API um pouco diferente, mas o básico é o mesmo da estrutura de sincronização original do Windows Phone que usamos para fazer a sincronização funcionar cerca de 8 anos atrás. Eu posso ver que ele ainda usa os mesmos dois campos de carimbo de data/hora para rastrear alterações de dados. Eles foram introduzidos no SQL Server como um recurso principal no SQL Server 2008. Nossa estrutura de sincronização funciona mais ou menos da mesma maneira que a estrutura de sincronização da Microsoft.

Então, para responder à pergunta de Michael, estarei investigando essa tecnologia. Vou ver se ele pode substituir nossa estrutura de sincronização. Eu adoraria despejá-lo e deixar alguém mantê-lo. Vendo que eles mencionaram que ele suportará SQLite, parece promissor porque parece que seremos capazes de hackear o wrapper SQLite para continuar usando o banco de dados SQL completo e, portanto, continuar usando nossa camada de dados. Se for esse o caso, isso significará que mais de 5 anos de código da estrutura de sincronização irão direto para a lixeira.

De qualquer forma, a questão é que a Microsoft parece estar reconhecendo mais uma vez que a computação distribuída é importante. Se for importante, o WF deve ser portado para UWP. UWP é o futuro e, portanto, também é o futuro da computação distribuída com tecnologia Microsoft. O futuro da tecnologia distribuída precisa da WF.

Embora relacionado, acho que System.Xaml é um componente separado que agrega valor por si só. Eu arquivei dotnet/corefx#5766 para rastrear isso separadamente.

Muito obrigado @terrajobst! Eu não concordo com tudo o que você publica online/twitter, mas sou um grande fã de como você facilita o diálogo e a comunicação entre desenvolvedores/comunidade e sempre concordarei com isso. :) Isso realmente significa muito para mim pessoalmente, pois parece que mais de um ano de patinação para cima para obter qualquer coisa da MSFT (e sim, eu percebo que não é compromisso, mas neste momento qualquer coisa é significativa).

Então, para responder à pergunta de Michael, estarei investigando essa tecnologia.

Incrível @MelbourneDeveloper , feliz em ajudar! Eu sinto que o Azure realmente tem um controle sólido em seu grupo. Junto com o VSO/VSTS, eles realmente ouvem seus desenvolvedores e obtêm um *_lot *_done. Na verdade, esse parece ser o caso de todos os grupos da MSFT _exceto_ do grupo UWP, que realmente não parece fazer muito e nem parece entender sua própria tecnologia (e nem vamos entrar em sua definição de "Xam").

Atualmente usamos o WF para vários de nossos serviços principais e estamos expandindo ainda mais nosso uso porque tivemos uma ótima experiência com Workflow e temos nossa lógica de negócios em um formato tão visual e fácil de entender.

Como @MelbourneDeveloper disse

De qualquer forma, a questão é que a Microsoft parece estar reconhecendo mais uma vez que a computação distribuída é importante. Se for importante, o WF deve ser portado para UWP. UWP é o futuro e, portanto, também é o futuro da computação distribuída com tecnologia Microsoft. O futuro da tecnologia distribuída precisa da WF.

A tecnologia WF tem sido subestimada por muitos desenvolvedores .NET porque eles podem não ter visto o valor dela na época (eu não via no passado, mas agora sou um grande fã do WF porque entendo o quão poderoso ele pode seja!), mas na era da computação distribuída, agora mais do que nunca o WF pode realmente brilhar e espero que seja portado.

Acho que há pouco espaço para discordância sobre este tópico.

Certamente pode-se argumentar que a programação visual e declarativa, como o WF, não é tão eficiente quanto escrever código. Eu até tenderia a concordar. Mas, ter o WF como uma ferramenta no kit de ferramentas para completar uma plataforma configurável certamente seria uma coisa boa. Os clientes *_DO *_ querem ver fluxos de trabalho visuais, e capacitar os clientes a modificar seus próprios fluxos de trabalho é certamente uma coisa boa.

Hora de fazer isso!

Acho que há pouco espaço para discordância sobre este tópico.

Haha @MelbourneDeveloper você já conheceu um desenvolvedor de software? Ou realmente, a raça humana? ;p

Pessoalmente, sinto que o designer visual do WF e as ferramentas existentes fizeram um desserviço ao XAML, pois os arquivos excessivamente detalhados gerados para os fluxos de trabalho do MSBuild realmente deram ao Xaml um nome ruim a esse respeito. Isso é realmente o que os desenvolvedores associam ao Xaml ("arquivos inchados") e ajudaram a gerar o voo para arquivos JSON "mais simples" e arquivos de compilação "com script". Sem mencionar todo o processo misterioso, difícil e complicado (ainda não consigo fazê-lo funcionar totalmente em meus projetos) de até mesmo criar um projeto para visualizar o arquivo Xaml para começar.

Quando, na verdade, a forma como o WF funcionava era o "caminho certo" o tempo todo. Sua verdadeira doença estava em suas ferramentas.

Como tal, se a ferramenta do designer fosse um pouco mais amigável (e talvez fizesse um trabalho melhor com a serialização de arquivos de maneira mais organizada/compartimentada), isso não seria um problema (ou menos um problema).

Eu sou um grande fã do caminho que o WF pretendia, mas precisa ser um pouco apertado e suas ferramentas abordadas e aprimoradas. Realmente, no final das contas, uma tecnologia é tão boa quanto suas ferramentas de suporte - designers e tudo mais. Quanto melhores as ferramentas/designers, mais acessíveis/compreensíveis, melhor a tecnologia, melhor a adoção.

Eu definitivamente gostaria de ver o WF se tornar mais parecido com o EF e ser acessível em qualquer cenário .NET, e as ferramentas melhoradas para facilitar exatamente isso.

Meu entendimento é que uma das visões originais do WF era oferecer suporte a vários tipos de arquivos para fluxos de trabalho, não apenas XAML. No geral, além de algumas peculiaridades aqui e ali, eu realmente não tive problemas com o XAML. Demorou um pouco para entender e me sentir confortável editando-o manualmente quando necessário, o que tenho certeza que representa uma barreira à entrada para muitas pessoas. Então, embora eu ache que o XAML precisa ser mantido para compatibilidade com versões anteriores (pelo menos no curto prazo), eu adoraria ver outros tipos de arquivos de fluxo de trabalho começarem a se desenvolver (como JSON). Eu pude ver algumas contribuições legais da comunidade nessa frente! (Fluxos de trabalho escritos em Whitespace alguém? :smile: )

@Michael-DST Concordo completamente com você. Recentemente, minha equipe e eu estávamos analisando os gostos/desgostos/desejos do Workflow e quase tudo o que queríamos ver melhorado girava em torno do designer e não necessariamente do núcleo do próprio WF. Acho que a Microsoft fez um trabalho fantástico com o que eles construíram no WF e acho que algumas melhorias e algum evangelismo podemos ver uma nova vida soprada nele. Eu acho que é uma ferramenta que PRECISA existir e eu obtive muito valor do WF e quero vê-lo continuar por muito, muito tempo.

Nossa empresa fez investimentos consideráveis ​​em WF e agora é uma tecnologia fundamental para nossos negócios. Dado o compromisso recente da MIcrosoft com o código aberto e o .NET Core, portar o WF parece ser o melhor próximo passo para essa tecnologia. Nós precisamos disso!

Workflow tem sido uma ferramenta com muitos benefícios para nós como desenvolvedores dentro de nossa organização. Se a Microsoft unificar suas estruturas, facilitaria nossas vidas ter o WF na estrutura principal.

Haha @MelbourneDeveloper você já conheceu um desenvolvedor de software? Ou realmente, a raça humana? ;p

Haha, eu sou um desenvolvedor de software. A raça humana é inconsequente para mim.

Michael-DST

Pessoalmente, sinto que o designer visual do WF e as ferramentas existentes fizeram um desserviço ao XAML, pois os arquivos excessivamente detalhados gerados para os fluxos de trabalho do MSBuild realmente deram ao Xaml um nome ruim a esse respeito. Isso é realmente o que os desenvolvedores associam ao Xaml ("arquivos inchados") e ajudaram a gerar o voo para arquivos JSON "mais simples" e arquivos de compilação "com script"

Você provavelmente está certo. Mas, pessoalmente, acho que há muita ênfase no Xaml aqui. Quando testei o WF (antes de perceber que não poderíamos usá-lo porque ele não existe no Silverlight), criei um aplicativo WPF. Esse aplicativo se conectou aos nossos serviços WCF e armazenou o Xaml para o WF em uma tabela em nosso banco de dados. Foi assim que conseguimos a codificação suave do WF.

Mas, o Xaml foi manipulado inteiramente com o uso da ferramenta de designer WPF WF. O usuário nunca viu o Xaml. O xaml era irrelevante para o usuário. Pense nisso como a marcação HTML por trás de uma página da web. Pode ser extremamente complicado, mas contanto que o usuário final goste da página da web, isso realmente não importa. Eu acho que se você está manipulando o Xaml diretamente como texto, você realmente não está usando o WF da maneira pretendida ...

A raça humana é inconsequente para mim.

Agradável. B)

Mas, o Xaml foi manipulado inteiramente com o uso da ferramenta de designer WPF WF. O usuário nunca viu o Xaml.

Correto. É exatamente assim que o MSBuild funciona e os usuários finais o odeiam por causa do tamanho dos arquivos que ele gera (especialmente quando você os compara com arquivos de "script" simples que são muito básicos e lineares). Estou de acordo com você que este é um problema de ferramental/designer, e eu também diria que o ferramental/designer poderia ser muito melhorado com o WF.

Caso em questão: postagens de blog e copiar/colar código (ou realmente, copiar/colar _workflow_ :smile:). Houve várias vezes em que pesquisei on-line por WF e tropecei em uma boa postagem no blog que mostrava algumas etapas a serem executadas para inserir um componente de fluxo de trabalho (provavelmente para o MSBuild). Bem, para fazer isso, eu tive que basicamente duplicar um monte de etapas. Normalmente, em uma postagem de blog de codificação, o código está disponível para um simples copiar/colar. Não é assim com WF. Você tem que fazer passo a passo até que fique na sua máquina exatamente como está na postagem do blog. Isso é obviamente muito tedioso e propenso a erros (e parece totalmente dar um passo para trás, de uma perspectiva C#).

O outro problema que encontramos com o MSBuild é o tamanho do arquivo, não apenas em bytes, mas também no próprio designer: era muito difícil navegar em um fluxo de trabalho complexo. Isso parece algo que deve ser contabilizado de uma maneira muito abrangente (e intuitiva).

Finalmente, quero encerrar a questão do tamanho do arquivo. Não tenho certeza se você conhece o WordML e/ou o MSFT Frontpage de antigamente. Mas criaria o HTML mais inchado do mundo. Embora os usuários geralmente não coloquem as mãos na marcação resultante, eles gostam de colocar o nariz nela para ter uma ideia de como ela é "limpa". A primeira coisa que eles observam é o tamanho no disco e, em segundo lugar, abrem o arquivo para ver como ele está formatado, etc.

Novamente, estou de acordo que como esses arquivos são construídos é estritamente uma questão de ferramental/designer, mas os desenvolvedores ficam curiosos e isso também deve ser levado em conta. :)

sim. Todos os pontos positivos. Eu acho que o designer precisaria ser limpo para que ele não criasse Xaml tão detalhado.

Quem realmente tem o poder de decidir se o WF será portado para .Net Core ou UWP? É apenas o caso de algum desenvolvedor em algum lugar escrevendo o código e, em seguida, enviando esse patch para os administradores do repositório de base de código .Net Core? Quais são as políticas em torno disso? Não existe uma equipe central de desenvolvedores influenciada pela Microsoft? São funcionários da Microsoft? Eu ainda não entendi toda a configuração. Quem temos que convencer?

Na verdade, @MelbourneDeveloper apenas participando deste tópico, você está ajudando a argumentar. Há uma equipe na MS que é proprietária do WF, atualmente minha, mas não tomamos a decisão de lançar o WF no Core. Temos que fazer o caso de negócios. A discussão aqui me ajuda a fazer isso.

É realmente impressionante como as pessoas começaram 2016 apoiando este tópico :)

Além disso, o https://github.com/dotnet/corefx/issues/5766 de @terrajobst ficou muito mais ocupado esses dias :)

@dmetzgar Espero que você obtenha o máximo de feedback possível / necessário dessa discussão para que você tenha casos suficientes para OSS.

Tenho certeza que se um repositório dotnet/WF for aberto ou se for adicionado ao corefx, as pessoas definitivamente o crescerão muito rápido.

Na verdade, @MelbourneDeveloper apenas participando deste tópico, você está ajudando a argumentar

Isso me faz sentir quente e confusa.

Apenas FYI dmetzgar - Estou mais do que feliz em documentar nossas experiências e apresentar um caso persuasivo para ajudar a construir evidências para o caso de negócios portuários.

Estou aprofundado na tecnologia da Microsoft desde 2000. Tenho observado todas as principais tecnologias relevantes para esse segmento se desenvolverem e desaparecerem. Embora eu esteja imerso na tecnologia da Microsoft, ainda a vejo de um ponto de vista objetivo e acho que o WF é uma das principais tecnologias que ajudariam a desenvolver a adesão de negócios/governo às plataformas .Net Core e Windows UWP.

Nada deixa um cliente mais animado do que fluxogramas! Nenhuma coisa!

Também devo dizer que a tecnologia da Microsoft está à beira de algo grande.

Por muitos anos, eu vi uma boa tecnologia subir e cair. A principal razão pela qual a tecnologia caiu no esquecimento é por causa da mudança do cenário de dispositivos. No passado, a estratégia era construir uma plataforma para cada família de dispositivos. Não havia nada inerentemente errado com essa abordagem. Mas significa portar tecnologias entre plataformas. Isso é oneroso, e não é incomum que tecnologias caiam no esquecimento porque uma plataforma de repente se torna intragável (tosse - Silverlight).

A Microsoft agora está apoiando o .Net Core e o UWP. Embora eu ache que essas duas plataformas devam ser uma e a mesma, ainda estou muito otimista de que, quando uma determinada tecnologia for criada ou mantida, ela funcionará em muitas plataformas. Xamarin aumenta ainda mais meu otimismo.

Parece genuinamente que, pela primeira vez na história, podemos estar olhando em branco para uma coleção de tecnologias que funcionam em uma ampla variedade de CPUs e ambientes operacionais. Se a Microsoft insistir nisso, o WF fará parte disso.

Isso me faz sentir quente e confusa.

:+1: naquele @MelbourneDeveloper e @dmetzgar. Este é o tipo de engajamento e diálogo que eu pessoalmente gosto de ver na MSFT, ao invés dos apelos ignorados e chamadas não atendidas de sua base apaixonada ( isso é apenas malvado, isso é malvado, cara ).

Um aparte aleatório aqui: no meu ponto de vista do NodeJS ser o único caso de negócios/ameaça que você precisa, um artigo aleatório que encontrei recentemente .

Finalmente, para o meu ponto de "se o .NET Core é bom o suficiente para o EF, deve ser bom o suficiente para o WF" ... se o WF foi para o .NET Core, existe alguma maneira de integrá-lo ao EF para que o EF sirva como seu backend de alguma forma? Esse é um caso convincente, se assim for. Se não, ainda vale a pena pensar (veja: discussão/diálogo/brainstorming/etc). :)

Finalmente, para o meu ponto de "se o .NET Core é bom o suficiente para o EF, deve ser bom o suficiente para o WF" ... se o WF foi para o .NET Core, existe alguma maneira de integrá-lo ao EF para que o EF sirva como seu backend de alguma forma? Esse é um caso convincente, se assim for. Se não, ainda vale a pena pensar (veja: discussão/diálogo/brainstorming/etc). :)

Esse é um pensamento interessante. Qual é o seu caso de uso para integrar EF e WF? Você pode dar um exemplo? Isso é por persistência?

Você pode dar um exemplo? Isso é por persistência?

Que no mínimo poderia ser usado como o modelo de apoio com o qual o fluxo de trabalho funciona no domínio do aplicativo. No máximo, poderia servir como mecanismo de armazenamento para o próprio fluxo de trabalho (mas eu não recomendaria isso - o Xaml é muito mais adequado para isso).

Eu posso ver um paradigma WPF-esque aqui onde você pode definir fluxos de trabalho em Xaml e, em seguida, vinculá-los a propriedades de elementos de fluxo de trabalho, usando dados de entidades de modelo definidas, modificadas e armazenadas no EF.

Concedido, minha experiência com WF é limitada aqui (aqueles com vasta experiência podem entrar aqui). Mas, se funcionou para o WPF, pode funcionar para o WF. Na verdade, eu uso esse mesmo paradigma (ou seja, de desenvolvimento baseado em Xaml do tipo WPF) para um aplicativo de console que uso para meu projeto atual . É verdade que ele não usa vinculações de dados como estou sugerindo (ainda), mas elas são facilmente produzidas, como o OmniXaml/Perspex nos mostrou. :oculos escuros:

@Michael-DST Prefiro evitar muitas integrações. O WF deve ser um pacote NuGet autônomo. Integrar WF e EF juntos deve ser um projeto separado. Comece a combinar muitas coisas e você pode acabar com Oslo .

Concordo com @dmetzgar :+1:

EF é um provedor de armazenamento/persistência. Deve ser um pacote diff NuGet e injetado em tempo de execução. WF deve fornecer apenas um conjunto de interfaces e isso é tudo.

Fizemos isso muito bem com os provedores de armazenamento da Microsoft Orleans.

@dmetzgar (e @galvesribeiro) concordaram. Não estou sugerindo uma integração necessária, mas um possível caso de uso/proposta de valor. (Veja: brainstorming. :smile:)

Qual é o seu caso de uso para integrar EF e WF? Você pode dar um exemplo? Isso é por persistência?

Eu quero entrar nessa! Novamente, isso se relaciona com a experiência da minha empresa. Por fim, gostaríamos de usar o EF para persistência de dados em bancos de dados embutidos, como SQLite, para aplicativos ocasionalmente conectados. Em última análise, UWP/.Net Core teria EF, SQLite, Azure Mobile Services e WF trabalhando em harmonia. Eu estaria me repetindo se explicasse por que queremos que isso aconteça, mas posso explicar por que EF e WF funcionariam bem juntos. No entanto, encontramos uma limitação no EF que nos impediu no passado - e é a outra razão pela qual tivemos que criar nosso próprio ORM.

Temos um sistema onde o acesso a dados aciona eventos como "BeforeLoad", "BeforeSave", etc. Deixamos ganchos nesses eventos para que, quando um determinado tipo de registro for salvo, possamos colocar nele uma lógica de negócios personalizada. Atualmente, fizemos isso vinculando-se a DLLs de lógica de negócios personalizadas. Cada cliente tem seu próprio conjunto de eventos personalizados. Também implementamos chamadas para WF. Assim, por exemplo, no evento BeforeSave, poderíamos colocar alguma validação lá fazendo uma chamada ao WF que valida os campos obrigatórios. Dessa forma, a lógica de validação foi codificada por software para um determinado cliente. A longo prazo, tivemos que abandonar o WF para esse propósito porque ele nunca foi implementado no Silverlight, mas teria sido bom tê-lo lá como uma opção.

De qualquer forma, sinto que este é um requisito bastante universal para qualquer aplicativo. De um modo geral, você sempre desejará uma camada logo acima da camada de dados que valide os dados que entram no banco de dados ou faça a lógica geral de negócios. Por exemplo, temos lógica de negócios para alguns clientes que enviam emails quando um registro de um tipo específico é adicionado ao banco de dados. Isso pode ser feito no WF. Seria ótimo implementar algo assim com EF e WF trabalhando em harmonia.

Infelizmente, nunca encontrei uma maneira de fazer isso com EF mesmo em .Net. O problema que encontrei foi que o EF não informa quando um registro de um determinado tipo está prestes a ser salvo. Por exemplo, se você criar um novo objeto "Task" e persistir no banco de dados com o EF, não haverá nenhum evento disparado pelo EF que tenha algo como "RecordInserted". Isso nos permitiria construir ganchos para o acesso aos dados para que os negócios personalizados pudessem ser inseridos. Então, essa é uma das razões pelas quais nunca fomos com a EF. É uma pena porque construir nosso próprio ORM levou anos para refinar.

Falando sobre o "caso de negócios" do NodeJS: Como o NodeJS está dominando o .NET em 3 gráficos fáceis

Esperando pacientemente por esse repositório do GitHub. Acabei de perceber que o WF não havia sido portado para o .NET Core, o que praticamente acabou com sua viabilidade para o nosso produto. O que é uma pena, pois adoramos as mudanças que estão chegando ao ASP.NET Core e toda a ideia modular, simplificada e multiplataforma do .NET Core, mas precisamos do WF, pois é a base de todo o nosso produto.

Eu acho que honestamente não me importo se isso é WWF, ou se é algum outro mecanismo de fluxo de trabalho bem suportado, mas acho que para fins de extensão, algum tipo de fluxo de trabalho pode ser absolutamente enorme.

+1

Usamos geração dinâmica (com base em regras externas importadas) e carregamento de fluxos de trabalho como serviços WCF. Seria ótimo se pudéssemos usar esse modelo no .net core!
BTW - qual é o problema de importar assemblies de .Net completo? se é principalmente código IL, por que não roda em .net core?

+1

@dmetzgar É incrivelmente emocionante ver https://github.com/dmetzgar/corewf! Do readme, fiquei surpreso ao ver que um port da equipe do WF não ganhou muita força. Especialmente considerando o recente porte do Powershell com o Powershell Workflow que será limitado à estrutura completa - Linux e Mac obviamente não são um alvo importante, mas o servidor Nano, imagino que seja extremamente importante para o Powershell. Também é mencionado lá que você está explorando alternativas ao XAML que incluem outras implementações de Xaml como Portable.Xaml por exemplo já suporta o perfil 259 compatível com CoreCLR?

@watertree Portable.Xaml e outras implementações de XAML com suporte a .NET Core que eu vi até agora têm um recurso ausente. Eles não implementam o atributo x:Class="". É desnecessário para o WPF, mas crítico para o WF. Um fluxo de trabalho XAML normalmente tem

O PowerShell Workflow tem uma maneira muito legal de definir fluxos de trabalho no script. É muito mais limpo do que escrever a mesma coisa em XAML ou C#. No entanto, o PSWF converte esse script em um arquivo XAML nos bastidores. Para o PSWF funcionar no Nano, eles teriam que substituir o pipeline existente e o tempo de execução do WF para que ele não usasse XAML. E realmente não há pressão suficiente dos clientes para ter PSWF no Nano.

Em relação às alternativas ao XAML, tenho muitas opiniões sobre isso. Meu problema com o XAML é que ele está embutido no WF. Com o antigo WF lançado no .NET 3.5, houve mais incentivo da equipe do WF para converter qualquer formato que você quisesse em um fluxo de trabalho. Eles usaram o exemplo de conversão de diagramas do Visio em fluxos de trabalho. Mas quando o novo WF chegou na versão 4.0, tudo estava focado em XAML. Você já tentou escrever um fluxo de trabalho em XAML manualmente? Não acontecendo. Depois, há símbolos de depuração e viewstate. E tente comparar uma versão de um XAML com outra com uma ferramenta de comparação.

Eu realmente acho que usar XAML para definir fluxos de trabalho deve ser uma questão de incluir um pacote NuGet. A criação de outros meios de armazenamento de definições de fluxo de trabalho deve ser incentivada. Talvez você precise de algo que comprima bem. Talvez você precise de segurança e permita apenas um conjunto limitado de atividades. Eu prefiro ter opções.

Eles não implementam o atributo x:Class=""

Na verdade, o Xaml compilado (baml?) esteve visivelmente ausente em todos os sabores de Xaml que eu vi. Eu pensei em mergulhar nisso com meu tempo livre, mas tenho a sensação de que estará disponível em alguma capacidade em breve, talvez no próximo ano. Além disso, o sistema Xaml do Xamarin oferece suporte a isso, mas é fechado e não é extensível/acessível.

Você já tentou escrever um fluxo de trabalho em XAML manualmente? Não acontecendo.

Verdadeiro. Ironicamente, o WF é o benfeitor mais abrangente (de longe) de qualquer integração Xaml. A uma falha, talvez. É uma pena que o Xaml tenha sido construído para ser extremamente amigável ao designer, mas as ferramentas em torno do WF são um pouco proibitivas para cenários escritos à mão e até mesmo para o próprio designer. Parece que eles realmente pretendiam torná-la uma linguagem de programação visual, mas sem a quantidade significativa de suporte/recursos que precisaria para ter sucesso.

Eu realmente acho que usar XAML para definir fluxos de trabalho deve ser uma questão de incluir um pacote NuGet.

Eu gosto de como você pensa! 👍

BTW, se você ainda não o fez, dê um pulo até a solicitação/problema da porta System.Xaml e vote a favor do problema, se puder. Eu, pelo menos, gostaria muito de ver um novo sistema Xaml de plataforma cruzada de código aberto que levasse o melhor de todos os sistemas conhecidos e o fornecesse como um sabor oficial e oficial. Não seria legal? 😛

De qualquer forma, é até 74 votos agora. O que é bastante radical, considerando que a votação começou antes que as reações do GitHub estivessem disponíveis:
https://github.com/dotnet/corefx/issues/5766

17 corações também são muito legais. :)

Obrigado por qualquer apoio (e feedback contínuo)!

@dmetzgar Obrigado por seus esforços! Apenas comente sobre XAML -- eu costumava ter uma visão muito negativa de XAML porque a maioria dos arquivos com os quais eu lidava eram criados com dialetos de XAML de designer visual.

Tudo isso mudou quando comecei a programar com o Xamarin.Forms, que tem uma API C# declarativa muito boa, além do XAML. Não há designer visual (apenas um visualizador que veio muito depois do lançamento do XF). Surpreendentemente, prefiro trabalhar em seu dialeto de XAML do que em código C#! Eles fizeram um ótimo trabalho e você não tem uma tonelada de metadados de designer poluindo o significado da marcação. Estruturas de suporte como Prism.Forms também ajudam a inclinar drasticamente as escalas para XAML, pois ajuda a escrever código sem code-behind muito fácil.

Portanto, não acho que o XAML em si seja o problema, mas os dialetos projetados para oferecer suporte aos designers primeiro - o XF é uma prova bastante convincente para mim.

Alguma atualização sobre esse tópico?

Bem CoreWF está vivo e existe em https://github.com/dmetzgar/corewf

É preciso ver se DynamicActivity agora pode ser portado com as novas APIs de composição adicionadas ao núcleo e ao padrão .net 2.0.

Seria ótimo se tivéssemos notícias da equipe do WF.

Houve muitos comentários interessantes e úteis sobre este tópico. De minha parte, acredito que há valor apenas no tempo de execução do WF e no rastreamento de eventos (ou seja, sem XAML, Transações ou bits WCF) sendo portados para o .NET Core e estou feliz que isso tenha sido (mais ou menos) feito.

Concordo que o WF.Core precisa existir oficialmente. Se houvesse a capacidade de criar uma maneira mais flexível de definir os fluxos de trabalho que funcionam para os desenvolvedores, acredito que seria a melhor abordagem. Concordo que o XAML é um osso duro de roer se a MS disser que não vai portar o System.XAML, mas eu realmente quero ver o WF.Core em meus projetos de API Web do .NET Core.

Eu acho que o grande elefante na sala aqui é que não há tração suficiente para fazer este projeto decolar porque MS e outros têm sido muito discretos em qualquer informação sobre WF. Claro que há alguns exemplos no MSDN, mas há muito pouca informação por aí na forma de livros ou outros materiais sólidos (examinados).

Estou definitivamente disposto a dedicar tempo para ajudar a trazer isso à vida.

Portanto, OmniXAMLv2 (está em uma ramificação no repositório do github), que ainda está em desenvolvimento, deve suportar atributos x:Class (https://github.com/SuperJMN/OmniXAML/issues/12). Talvez possamos usá-lo para (Core)WF?

@ewinnington Obrigado por apontar isso!
Isso é definitivamente um grande pedaço disso. Além disso, o .NET Standard 2.0 tem vários tipos System.ComponentModel usados ​​pelo WF. System.Transactions já está no corefx. A única coisa que falta é o WCF ServiceHost.

WCF ServiceHost pode esperar IMHO. O modelo de hospedagem deve ser agnóstico como qualquer outra coisa no mundo .Net Core/Asp.Net, eu acho...

@galvesribeiro Concordo com isso, já que existem muitas outras maneiras de o WF funcionar em um mundo .NET Core, incluindo a API da Web.

Sim. No entanto, concordo com @dmetzgar que há muitos clientes que hoje usam o WCF, portanto, é necessário ter suporte, mas, novamente, pode ser atrasado ...

Na verdade, a hospedagem e a "linguagem de design" devem ser abstraídas do runtime principal...

Usamos o WCF com o WF, mas mudaríamos para algo como WebAPI se o WF estivesse no Core. Na verdade, estamos indo em frente e migrando do WCF para uma alternativa RESTful independentemente. Obtemos muito valor do Workflow e é uma das minhas tecnologias .NET favoritas!

Eu também acho que o WF no núcleo não deveria depender de xaml ou wcf, apenas ter o mecanismo wf e o modelo de objeto seria super valioso. Você então executaria isso como um middleware no núcleo asp.net, especialmente com o novo trabalho de pipeline/não http que está chegando ao Kestrel.

+1 por ter e suportar o mecanismo WF e o modelo de objeto no Core. Também podemos trabalhar com XAML e WCF.

O XAML é legal - ele permite que você faça uma configuração dinâmica - em um projeto, carregamos fluxos de trabalho xaml de arquivos e eles são representados como endpoints WCF. E esses arquivos XAML são gerados automaticamente a partir do registro de serviços disponíveis. Assim, os serviços wcf obtêm endponts:
https://[base]/wcf/[service_id1]
https://[base]/wcf/[service_id2] ...
Seria bom ter essa funcionalidade no .Net core :)
Ah... já escrevi aqui antes... :)))

Sim, como eu me familiarizei mais com a terra aqui, o suporte a Xaml no WF não é tão importante em si, mas é realmente a portabilidade do System.Xaml que é a parte importante. Como isso é claramente capturado em outro - e tenho o prazer de dizer bastante popular (mas não deixe que isso o impeça de votar, @freerider7777! :smile:) - problema, sou a favor de tornar o WF como dependência livre possível para garantir que ele entre no .NET Core. 👍

@Mike-EEE Eu votei lá há muito tempo!! :)

Vendo que os fluxos de trabalho podem ser criados por meio de código, o uso de uma API Fluent semelhante ao EF Core seria uma opção válida para dar vida ao WF Core? Então a serialização/desserialização para tempo de execução poderia ser construída posteriormente e ser muito mais fácil de implementar?

FluentAPIs... tão quente agora. Ou pelo menos, desde que foram criados. 😄

FluentAPIs, Builder Pattern, ambos são essencialmente iguais. Fornecer uma maneira baseada em código que seja encadeada e fácil de usar, acredito que deve ser um princípio sólido por trás disso.

Sem um designer é tudo inútil. Claro que podemos codificar tudo sozinhos - toda a lógica, todas as cadeias e assim por diante (com fluência ou sem ela). Mas o que é legal no WF - você pode ver visualmente o fluxo de processamento. É o elo entre gerentes (e outros 'stakeholders') e desenvolvedores! Os gerentes não entendem o código, mas esses diagramas de alto nível são compreensíveis por todos. Com o WF, você não precisa de diagramas separados (visio ou outros) se estiverem separados - eles geralmente estão fora de sincronia com o código real :)

@freerider7777 A serialização de definição de WF não está limitada a xaml (consulte https://github.com/dmetzgar/corewf de @dmetzgar ). Ele poderia ser implementado para JSON também .. e isso abriria a possibilidade de integrar/fork projetos existentes como NodeRed http://nodered.org/ , que em muitos aspectos se assemelha aos recursos do WF Designer e UX (+ também executaria em um navegador da Web, abrindo novos casos de uso para WF)

Acho que é melhor portar o WF para o .NET Standard e não apenas para o .NET Core. O tempo de execução do WF vinculado anteriormente já funciona no .NET Standard 1.3 (podemos diminuir se eliminarmos a atividade WriteLine). Com o lançamento do padrão 2.0 em breve, teremos a capacidade de preencher muitas lacunas de recursos, como metadados de cache automáticos, DynamicActivity e escopos de transação. Devemos separar os componentes em pacotes diferentes para que haja um modelo pay-for-play: se você quiser apenas o tempo de execução, poderá ficar com o padrão 1.3, mas se quiser DynamicActivity, precisará do padrão 2.0 e limitará suas plataformas.

Definitivamente, há muito espaço para melhorias no código de tempo de execução do WF. Por exemplo, eu substituiria as extensões de atividade por injeção de dependência. A API Fluent seria interessante para escrever fluxos de trabalho em código (e nesse sentido, veja https://github.com/knat/Metah por @knat), mas concordo com @freerider7777 que a capacidade de se comunicar com seu gerenciamento e BAs usando diagramas gerado a partir do que é realmente usado na produção é uma grande vantagem. @helmsb tem muita experiência com isso (confira http://dotnetrocks.com/?show=1236).

Um novo designer teria que ser um aplicativo da web. A segmentação de WPF ou UWP limitaria o público. Se o OmniXAML der certo, as pessoas poderão criar/editar fluxos de trabalho usando as mesmas ferramentas que usam hoje (VS ou solução rehospedada). O problema é que, como o designer atual está embutido no .NET Framework, quaisquer recursos ou correções teriam que esperar por uma versão do .NET Framework. É bom o suficiente para começar, mas não é uma solução a longo prazo. @erikcai8 fez alguns experimentos com um web designer, semelhante ao nodeled. Vou ver se consigo convencê-lo a compartilhar.

Para o front-end do designer de fluxo de trabalho, há uma primeira tentativa disponível no github: https://github.com/gary-b/WF4JSDesigner e você pode usá-lo ao vivo http://gary-b.github.io/WF4JSDesigner/

Isto é o que já parece:

@ewinnington : Ótimo ver o POC do designer de fluxo de trabalho da web. Eu também construí outro como abaixo da captura de tela mostrada.

AWWWW SNAP!!! É um WF POC-OFF!!! 🎉

Heh heh. Ei @erikcai8 onde está a exportação para Xaml??? Ha ha. Apenas lançando sua dor. Sorte. 👼

Ambos os esforços parecem ótimos. Bom ver os dois. Isso parece meio óbvio agora, mas quão incrível teria sido ter um designer visual baseado na web no WF original? Tudo está bloqueado e carregado, pronto para usar, basta acessar uma URL. Eu acho que isso teria realmente ajudado com branding e adoção. Infelizmente, todos parecem ter chegado ao editor baseado em TFS, que foi muito difícil de configurar e levou a um Xaml. Esta foi uma experiência ruim para o desenvolvedor típico que teve que lidar com isso e deu a qualquer coisa a ver com a experiência (WF ou Xaml) um nome ruim.

Isso, OTOH, parece uma ótima abordagem. Que comece o renascimento!

@Mike-EEE Meu experimento E2E aprimorou o Workflow Core Engine para carregar o fluxo de trabalho JSON nativamente para que o formato XAML não seja necessário. O fluxo de trabalho XAML pode ser exportado do Workflow Engine depois de carregar o fluxo de trabalho JSON.

Esse é o ponto. Não devemos vincular o tempo de execução e seu modelo de objeto ao designer e ao formato serializado como era no WF 4.5...

@galvesribeiro Entendeu o ponto. O experimento assumiu que o formato JSON era compatível como outra opção para o Workflow Core. Conforme discutido acima, o XAML ainda não é amigável para as tecnologias da Web mais recentes.

Nós adoramos o WF, por favor, transfira-o para .NetCore.

Precisamos de um designer de fluxo de trabalho baseado na web. O suporte para .NET core, para executar os fluxos de trabalho, seria duplamente incrível. vá, vá

Daniel Gerlag está trabalhando em um mecanismo de fluxo de trabalho compatível com núcleo leve muito bom aqui:

https://github.com/danielgerlag/workflow-core

Daniel's percorreu um longo caminho em um período muito curto de tempo. Eu o encorajo fortemente a olhar para ele e participar deste projeto se você encontrar mérito nele.

Com todo esse interesse, por que não construir um mecanismo compatível com Net Core do zero?

@ccpony Porque você pode usar o CoreWF no dot net core agora -> https://github.com/dmetzgar/corewf . Os componentes centrais são portados e funcionam. Algumas coisas estão esperando pelo padrão .net 2.0.

@ewinnington Obrigado por responder, mas não estou entendendo isso. O WF não foi um produto de sucesso da MS e a MS não fez nada para melhorá-lo por anos. A comunidade está repleta de testemunhos de implementações testadas e falhas. Não foi amplamente adotado na empresa. É pesado, cheio de recursos, difícil de aprender e (ainda) cheio de bugs. Sua interface é amplamente difamada. Não conseguiu se tornar uma tecnologia amigável ao usuário final. Seus internos são essencialmente uma caixa preta que não pode ser facilmente aprimorada. É LENTO com qualquer coisa além de fluxos de trabalho simples. É muito difícil testar. É baseado em tecnologias antigas (WCF, XAML). Desde que Ron Jacobs ficou doente, WF definhou e não tem nenhum amigo no MS.

Na minha opinião, o WF tentou ser tudo para todos e, na verdade, acabou sendo pouco para qualquer um. A Microsoft praticamente o abandonou. Por que desejaríamos ressuscitar algo assim? Se alguma tecnologia importante exigia uma reavaliação e uma reescrita, ISSO É ISSO.

Veja o projeto incipiente de Daniel Gerlag. É novo e imaturo. Mas é preciso uma abordagem moderna para o fluxo de trabalho que seria fácil de aprimorar. Se todos aqui parassem de tentar adaptar um projeto complexo, datado e, francamente, com engenharia excessiva e, em vez disso, colocassem seus esforços em algo novo e melhor, então teríamos uma chance de terminar em um lugar que valesse a pena - - construindo incrementalmente um mecanismo de fluxo de trabalho de classe mundial em vez de tentar reescrever um gigante desde o início. Honestamente, admiro todos aqui que querem se envolver em um esforço MUITO valioso - - criando, FINALMENTE, uma ferramenta de fluxo de trabalho multiplataforma (máquina de estado?) bem projetada, funcional, leve, fácil de aprender. Mas, lamento dizer, se todos vocês continuarem a seguir este caminho, então todos os seus esforços irão desaparecer em nada. MHO.

@ccpony Obrigado por compartilhar sua opinião. Você se importaria de detalhar quais bugs você está se referindo? Se houver algo que possamos fazer para corrigir problemas no .NET Framework, ficarei feliz em saber.

@dmetzgar Obrigado por responder, Dustin. Durante o período de tempo que estava tentando desenvolver aplicativos WF, encontrei bugs. Não apenas comportamentos inesperados, mas havia várias vezes que um WF complexo "explodiria" e geraria erros na interface do usuário XAML que eram difíceis de corrigir no código XAML. Eu nunca realmente desenvolvi uma grande confiança na tecnologia WF. Realmente, chegou ao ponto que eu senti como se estivesse lutando com um gorila de 800 libras - - para cada passo à frente, eu acabaria retrocedendo dois passos.

Eu sei que não é isso que você está procurando em seu gentil pedido para eu elaborar sobre bugs. Francamente, eu poderia contornar esses bugs. Mas acabei abandonando o WF por todas as outras razões que mencionei no meu post anterior.

Você está liderando esse esforço e eu o saúdo por isso. Mas certamente chega um ponto em que tentar adaptar uma tecnologia complexa se torna contraproducente. Seguindo este tópico inteiro, simplesmente não posso deixar de sentir que o progresso é muito lento - - se for - - e, eventualmente, nada será mostrado de tudo isso. Acho muito improvável que os fluxos de trabalho antigos sejam portáteis para o que for produzido aqui. As pessoas neste tópico estão falando sobre fluxo de trabalho baseado em cliente (ou seja, JavaScript), compatibilidade REST, redução de dependências, plataforma cruzada, etc. XAML não fará parte disso?

Então Dustin, eu preciso te perguntar isso: aqui estamos com 18 meses neste projeto e simplesmente não parece haver consenso de que o progresso real está sendo feito. Respeito seus esforços e posso ver que você é um ótimo programador - - mas aqui está minha pergunta: não faria MUITO mais sentido reunir toda essa energia e entusiasmo e criar algo novo?

@ccpony A discussão neste tópico é apoiar o WF .Net Standard e não o contrário.

Apenas curioso... Você já usou ou viu uma implantação do Sharepoint em ação? Se você fizer isso, verá que é muito pesado no WF. Você já viu uma implantação do BizTalk? O mesmo.

Esses são os principais produtos MSFT no mundo corporativo, então sim, existem usuários que se preocupam com o WF e há uso para ele. Não é um projeto abandonado/abandonado como você disse.

Com isso dito, se você olhar para o repositório @dmetzgar , verá que por mais que algumas coisas sejam semelhantes ou herdem alguns comportamentos da antiga encarnação do WF, você também verá que ele foi redesenhado para ser leve. O persistense é desacoplado e as pessoas podem facilmente criar novos. O designer está desacoplado e as pessoas já criaram vários testes.

Eu entendo sua frustração em querer algo novo. Acredite, eu quero que isso aconteça também. Mas você precisa entender @dmetzgar e sua equipe. Isso não é uma prioridade, pois 95% dos clientes são usuários do antigo WF, que basicamente o executa no BizTalk e no Sharepoint, como mencionei. Usei o antigo WF por anos em um ambiente de tps muito alto (transações bancárias e financeiras) e me atendeu muito bem.

Minha nova tecnologia está trabalhando com .Net Core, e a única razão pela qual não estou usando novamente agora é porque ainda não temos para .Net Core.

O que eu já sugeri para @dmetzgar , é trazer o repositório WF para .Net Foundation, definir marcos, colocar o código lá e adicionar tarefas como problemas e marcar como up-for-grabs para que a comunidade comece a fazer isso. No entanto, isso ainda requer algum tempo de sua equipe para realizar esse trabalho e eles possivelmente não têm esse tempo disponível (ainda).

@galvesribeiro entendi seu ponto. Sim, escrevi implantações do SharePoint. E eu VI as implantações do BizTalk em ação ( * obturador *). Eu entendo a relação entre o SharePoint e o WF. (Não sei o que você quer dizer quando sugere que o BizTalk de alguma forma depende do WF. Não.)

Mas eu tenho que discordar de você em um ponto importante: WF É um projeto abandonado/abandonado. Eu realmente entendo a preocupação dos desenvolvedores do SharePoint neste momento. Não há razão para acreditar que o MS aprimorará os recursos do WF no SharePoint. Não entendo por que você acha que os esforços de @dmetzgar terão algo a ver com o futuro do SharePoint (ou BizTalk). Não é como se a MS fosse adaptar o SharePoint com o código do @dmetzgar . Desculpe, mas o futuro do SharePoint não tem nada a ver com os esforços feitos aqui.

Então, tudo o que realmente importa é se um bom mecanismo de fluxo de trabalho sairá de tudo isso. E é minha opinião que tentar forçar um gigante como o WF no futuro não é o melhor curso de ação. Melhor construir do zero.

@ccpony Gostaria de lembrá-lo de que existem inúmeras pessoas aqui que estão buscando ativamente ver este projeto ganhar vida, e algumas estão realmente dedicando tempo para que isso aconteça. Embora você pessoalmente possa ver o WF como um produto com falha da Microsoft, ele continua a fazer parte do .NET e é usado por mais do que apenas nós aqui.

Este tópico deve ser para críticas construtivas e contribuições para tornar a transição uma realidade e não para criticar os outros ou o próprio produto. Embora suas opiniões sejam respeitadas, observe que elas são suas e que outras pessoas podem pensar de forma diferente em relação à importância do WF para elas.

Congratulamo-nos ativamente com sua opinião sobre maneiras de melhorar o produto e a melhor forma de ajudar aqueles que estão participando ativamente da tentativa.

Obrigado =^_^=

@ccpony

(Não sei o que você quer dizer quando sugere que o BizTalk de alguma forma depende do WF. Não.)

Desculpe, me expressei mal (estou no celular). Eu tinha aplicativos que usavam os dois juntos e conheço muitos outros que também funcionam.

Não há razão para acreditar que o MS aprimorará os recursos do WF no SharePoint.

Não estou dizendo que vai. Estou dizendo que a equipe que trabalha com a WF Hoje, está totalmente focada em dar suporte a implantações do Sharepoint. Mesmo a versão mais recente do Sharepoint está usando a mesma/atual versão do WF.

Não entendo por que você acha que os esforços de @dmetzgar terão algo a ver com o futuro do SharePoint (ou BizTalk).

Não estou dizendo que isso afetará o futuro do Sharepoint. Estou dizendo que a equipe está ocupada apoiando o Sharepoint se entendi corretamente. ( @dmetzgar pode me corrigir se eu estiver errado)

Não é como se a MS fosse adaptar o SharePoint com o código do @dmetzgar . Desculpe, mas o futuro do SharePoint não tem nada a ver com os esforços feitos aqui

Se a MS usará ou não o WF vNext no Sharepoint vNext, somente eles poderão dizer com certeza. Novamente, o problema é que a equipe do WF não consegue lidar com ambos.

Então, tudo o que realmente importa é se um bom mecanismo de fluxo de trabalho sairá de tudo isso. E é minha opinião que tentar forçar um gigante como o WF no futuro não é o melhor curso de ação. Melhor construir do zero.

Ninguém está portando-o como está. O repositório do @dmetzgar é uma prova de que está sendo redesenhado do zero. Novamente, o problema é o backlog e a largura de banda que a equipe tem para lidar com as duas coisas. É por isso que sugeri "abri-lo" na fundação dotnet e torná-lo um grande esforço voltado para a comunidade com orientação e curadoria da equipe do WF, para tentarmos afetar o menos possível suas agendas.

Novamente, como @InariTheFox e eu mencionamos, este tópico é um avanço para a porta, o que não significa necessariamente empurrar a antiga fersão com todos esses recursos para a nova versão. No entanto, é importante entender que as pessoas colocam muito esforço (e dinheiro) em seus produtos atuais baseados em WF, então @dmetzgar se preocupa com a maior compatibilidade possível com os fluxos de trabalho antigos, é realmente algo para cuidar.

OK. Eu vejo as paixões aqui. Na verdade, se houvesse um bom substituto para o WF que resolvesse todos os problemas que mencionei antes, não estaríamos tendo essa conversa. Para que conste, muitos de nós se afastaram do WF e esperaram ansiosamente pela próxima coisa que viesse. Isso nunca aconteceu. Até onde sei, NÃO existe nenhuma solução de máquina de estado/fluxo de trabalho atual, suportada, funcional e baseada em .Net que seja amplamente considerada. Por favor, entenda: eu mantenho minha afirmação de que o WF é uma tecnologia morta do ponto de vista da Microsoft.

Mas, tendo dito isso, por favor me ajude a entender. O repositório do @dmetzgar funciona como está? Como se escreve fluxos de trabalho com ele? Não vejo nenhum código de exemplo e não há documentação. Como eu procederia?

Eu acho que existem muitos produtos / empresas por aí que tornaram o WF central para sua estratégia de produto, não é apenas uma dependência do Sharepoint no modo de suporte: na minha empresa atual desenvolvemos uma plataforma de automação com o WF sendo a tecnologia central (e eu sei outros 2 concorrentes deste mercado que também utilizam WF em seus produtos); também discuti com pessoas que o usam em insurtech... então acredito fortemente que o público do WF ainda existe.

Dito isso, o .net core parece ser uma das áreas de foco da Microsoft e muitas inovações tecnológicas serão aplicadas no próximo período; Acho que seria uma grande perda não ter o WF como parte disso.

Do meu ponto de vista, o caminho certo para que isso aconteça é tornar o núcleo do WF independente do xaml e facilitar a (des)serialização de fluxos de trabalho em outros formatos também (ex: json). Isso também simplificaria a implementação de cenários como designers de fluxo de trabalho hospedados em navegadores da web. E com o repositório https://github.com/dmetzgar/corewf temos um ponto de partida.

Para os interessados ​​em uma visão geral sobre o estado atual do WF (que não vejo como abandonado pelo MS), há algum tempo centralizei as informações disponíveis sobre o WF em um post e uma apresentação http://andreioros.com/blog /windows-workflow-foundation-rehosted-designer/ ; Eu ainda estou mantendo-o atualizado

Nós e nossos clientes confiamos no WF e adoraríamos vê-lo funcionando tanto no cliente quanto no servidor. Um WF livre de XAML e outras dependências, projetado para ser leve, mas com a expressividade do WF existente, que também é suportado pela comunidade com o MS, seria um produto interessante e valioso.

Mais uma vez, por favor, permita-me perguntar: o que se faz com a porta do @dmetzgar para executá-la? Qual é o estado atual?

Eu não sabia que o port do @dmetzgar era realmente utilizável em sua encarnação atual ...

De @ewinnington , acima:

"Porque você pode usar CoreWF no dot net core agora -> https://github.com/dmetzgar/corewf . Os componentes centrais são portados e funcionam. Algumas coisas estão esperando pelo .net padrão 2.0."

Nesse caso eu também gostaria de ouvir sobre seu uso...

Sim, é a base da funcionalidade principal. Você pode executar fluxos de trabalho baseados em código. Os recursos ausentes de netstandard2.0 estão principalmente relacionados ao suporte a transações.

Essa é mais uma razão pela qual ainda sugiro iniciá-la aberta e fazer com que as pessoas contribuam para um lugar central. Difundir isso tornará as coisas ainda mais difíceis de alcançar em um produto final algum dia no futuro.

Vote a favor da reescrita do WF com testes e suporte para recursos modernos do Roslyn como parte do Core. Eu adoraria ver como o serverless e os contêineres podem afetar a arquitetura, especialmente a implantação e o dimensionamento de conjuntos de regras em contextos de domínio e processos de negócios distintos. Eu pessoalmente preferiria um DSL sucinto a um designer WYSIWYG. Eu pessoalmente amava o designer, mas parecia peculiar quase o tempo todo. O próprio WF tinha potencial para ser extremamente sólido, mas exigia profundo conhecimento. Na verdade, um grande lançamento do WF que incluiu o WF Manager e fluxos persistentes no SQL Server exigiu consultoria do MS e correções de bugs. Embora agora eu suporte equipes Java nos últimos anos, gosto de ficar de olho no .NET depois de pouco mais de 15 anos focando principalmente na tecnologia MS. Eu estava lendo "Code Generation with Roslyn" de Nick Harrison (não tenho vínculos com ele ou com o livro) e me perguntei sobre reaproximar o espaço do Business Rule Engine mais uma vez, o que me levou a pensar mais uma vez sobre o destino do WF... com toda a honestidade, acho que o Azure Functions compete tanto com os recursos do MS quanto com sua disposição corporativa geral de oferecer suporte a investimentos profundos em WF em qualquer lugar. Parece óbvio que eles gostariam que você usasse isso... então, talvez a solução seja focar em uma versão .NET de código aberto do OpenWhisk. Mas, em um mundo conteinerizado, ... eu posso usar o OpenWhisk como um serviço. Assim...

O PS simplesmente oferecer suporte a um método robusto de importação de expressões externalizadas pode resolver 60% dos requisitos de aplicativos que acham que podem querer o WF. Era CSharpScript? Uma maneira simples de importar configurações básicas de regras de negócios com uma API direta ajudaria muito (várias opções de persistência, recuperação e armazenamento em cache). Com infraestrutura virtual descartável (automação sobre infraestrutura, contêiner e plataforma como serviço), o WF vNext pode se concentrar na implantação de alterações de versão como um serviço em vez de tentar incorporá-las em aplicativos (ou seja, uma solução melhor para WF no WCF)

Estou extremamente interessado nesta conversa. Minha equipe também tem lidado com a frustração do XAML. Nosso dilema é que estamos criando nosso próprio designer de interface do usuário para permitir que nossos clientes criem seus próprios fluxos de trabalho sem precisar do Visual Studio ou do designer rehospedado. Precisamos da capacidade de salvar pedaços de XAML em bits reutilizáveis ​​para que o cliente nem sempre precise reescrever esses bits (pense neles como funções de fluxo de trabalho). Isso exige que saibamos como mesclar partes de XAML, o que aprendemos ser extremamente frustrante. O que estamos pensando em fazer é criar uma abstração onde simplesmente dependemos de um modelo de banco de dados de nossas várias atividades e seus vínculos e ignoramos completamente o XAML. Em seguida, criaremos as atividades etc. programaticamente cada vez que um fluxo de trabalho for executado. Ao pesquisar essa abordagem, me deparei com este tópico. Continue a conversa, estou muito interessado em ouvir as opiniões dos outros.

@erikcai8 O designer de fluxo de trabalho é uma ideia muito boa. Posso obter a fonte do seu designer de fluxo de trabalho?

Uso o WF há mais de 5 anos em meus projetos de automação e foi maravilhoso. Espero que muitos desenvolvedores apoiem essa solicitação e a façam acontecer. Sempre usei a tecnologia .Net desde que comecei a trabalhar e gostaria de continuar a fazê-lo. No entanto, ser capaz de suportar multiplataforma é a direção da empresa, portanto, estou realmente ansioso para ver o WF completo no .Net Core.

Com a chegada do net standard 2.0, seria ótimo ter uma atualização sobre os problemas do corewf:

@dmetzgar
https://github.com/dmetzgar/corewf/issues/3
https://github.com/dmetzgar/corewf/issues/4

Como a API adicionada desbloqueou o processo de portabilidade e o que podemos fazer para ajudar?

Eu acho que independentemente de netstandard2.0 , esta porta deve funcionar como estava IMHO... Com uma reescrita... Tornando-a amigável para agendadores de tarefas externas, async/await/Task e outras coisas modernas. Por mais que eu ame WF, a versão atual está bem desatualizada...

Digo isso sem nenhum desrespeito. Honestamente. Mas eu sou o único aqui que entende que este projeto é inútil? Precisamos desesperadamente de um bom mecanismo de fluxo de trabalho para .Net, mas não é isso. Não deveríamos estar mudando a conversa aqui?

Estou aberto a um novo e melhor mecanismo de fluxo de trabalho. Bottomline precisamos de um no .NET Core. Usamos o WF há anos e funcionou muito bem para nós, então é melhor do que nada se essa for a alternativa.

@kalokamgit , a fonte está disponível na fonte de referência. Está em duas montagens:
System.Activities.Presentation e System.Activities.Core.Presentation .

Infelizmente, a ferramenta que publica a fonte de referência faz apenas o código C#. Ele não inclui nenhum dos arquivos XAML. Você pode fornecer comentários sobre isso para [email protected] e/ou votar no problema de voz do usuário .

O código está no .NET Framework, portanto, você pode usá-lo em suas próprias ferramentas. Alguns exemplos são o projeto do @orosandrei e um exemplo de projeto aqui .

Digo isso sem nenhum desrespeito. Honestamente. Mas eu sou o único aqui que entende que este projeto é inútil? Precisamos desesperadamente de um bom mecanismo de fluxo de trabalho para .Net, mas não é isso. Não deveríamos estar mudando a conversa aqui?

Bem, se você _realmente_ quer dizer sem desrespeito. :) Estou curioso para saber o que todos pensam sobre o Flow ? É nisso que penso quando penso em "fluxo de trabalho" para os "dias modernos" ... também o que o Azure está vendendo muito nos dias de hoje.

Eu realmente quero dizer isso :)

Guess Flow é a resposta para o crescimento do Zapier? Não vejo como ele substituiria o WWF de forma alguma.

O WF foi descontinuado ou estou perdendo algo aqui? Isso seria muito triste!

Onde posso votar no WF?

O post principal desta edição é o melhor lugar.

Eu me pergunto o que @rjacobs (guru do WF) pensa sobre esse assunto.

Você quer dizer @ronljacobs?

@dmetzgar Provavelmente sim. Ele é o verdadeiro herói do WF

Esta é a minha resposta
https://github.com/danielgerlag/workflow-core

Ron Jacobs foi o cara que colocou seu coração e alma no WF por anos e anos. Ele contraiu a doença de Dercum e deixou a Microsoft em 2013. (aqui) Quando ele saiu, foi tudo para a WF. Mais uma vez, e espero que pela última vez: WF ESTÁ MORTO.

E mais uma vez - - eu encorajaria todos e qualquer um a olhar para o projeto de Dan Gerlag, acima. É eloquente, lindamente concebido e roda no Core. Qualquer pessoa que deseje contribuir para uma solução de fluxo de trabalho viável precisa procurá-la.

Além disso, dê uma olhada no Durable Task Framework . Isso está sendo adicionado ao Azure Functions, consulte funções duráveis .

@dmetzgar Esse framework está em fraldas para ser considerado uma alternativa ao WF. Não acho sério que a Microsoft proponha esse tipo de coisa. Não seria muito melhor em vez de reinventar a roda, migrar o WF para .NET Core e reutilizá-lo como base em todos os projetos da Microsoft? Desculpe a dureza de minhas palavras, mas acho que elas representam o sentimento de muitas pessoas que estão muito decepcionadas com a situação atual da WF.

@Suriman , ponto justo

Atualizei o leia-me no repositório corewf para ter uma descrição melhor do que está envolvido na portabilidade do WF para o .NET Core. Você se importaria de dar uma olhada?

@dmetzgar Obrigado pelos esclarecimentos e por mostrar claramente o caminho a seguir para portar WF para .NET Core. Entendo pelo que você diz que a Microsoft não fará todo esse trabalho de migração e espera que a comunidade o faça, não é? A resposta a esta pergunta é a chave, dependendo da resposta, as empresas podem optar por uma rota alternativa ou fazer o trabalho que a Microsoft deveria fazer.

A Microsoft não fará uma porta oficial do WF para .NET Core. Minha equipe e eu trabalharemos nisso em nosso tempo livre, mas não em caráter oficial ou com lançamentos programados. Todos os problemas listados estão em disputa. Existem usos para tal porta para alguns dos projetos que fazemos. É daí que vem a maior parte de nossas contribuições. Acho justo encerrar este assunto por enquanto e apontar as pessoas para o repositório corewf para acompanhar o trabalho mais recente.

Oi,
A mudança do marco Futuro para 2.1 significa que a Microsoft fará a portabilidade do WF para o .NET Core?

A alteração do marco para problemas encerrados reflete apenas durante a versão em que o problema foi encerrado.
Esse problema específico foi fechado basicamente como "Não será corrigido" - veja a explicação acima https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275

@karelz Que pena. Por um momento, parecia que a loteria tinha nos acertado.

Temos uma solução baseada em WF. Estamos criando uma etapa de atividades usando o WF e esse fluxo de trabalho será entregue a todos os assinantes e eles processarão as ações com base no WF. Nós amamos muito o WF. apoiar a plataforma cruzada é a direção da nossa empresa. Estamos muito interessados ​​em ter WF em .NET CORE.

Existe o CoreWF que é o código do Workflow Foundation parcialmente portado para o .net core. Você pode usar a plataforma cruzada do Workflow Foundation agora . Você simplesmente não pode usar fluxos de trabalho baseados em XAML neste momento.

Eu tenho uma ramificação onde trabalhei na adição de suporte para Atividade Dinâmica em cima do Net Standard 2.0 .

O processo de análise de XAML exige que a Microsoft abra System.XAML o suficiente para que possamos progredir na análise dos arquivos corretamente.

Você pode acompanhar o progresso do problema aqui: https://github.com/dmetzgar/corewf/issues/6 e em minhas várias tentativas de alertar para esse problema:
No CoreFX
Na fonte de referência

O pacote de compatibilidade .Net tem um "Talvez" na frente do System.XAML. Mas nenhuma notícia foi filtrada sobre sua inclusão. A edição Pacote de Compatibilidade do .Net Framework atualmente lista "sem planos" para System.XAML.

Talvez também o problema Customer Adoption Epic possa ser usado para contar sua história de como a adição do Workflow Foundation (e System.Xaml) permitiria que sua empresa enviasse um produto.

Minha empresa também investe na WF: Temos um produto para empresas de Energia onde nossos clientes criam fluxos de trabalho usando o Workflow Foundation.

Obrigado por sua resposta.
foi muito útil valeu.

Em 2 de novembro de 2017 18:22, "Eric Winnington" [email protected] escreveu:

Existe CoreWF https://github.com/dmetzgar/corewf que é o código de
Workflow Foundation parcialmente portado para .net core. Você pode usar o fluxo de trabalho
plataforma cruzada de fundação agora . Você simplesmente não pode usar fluxos de trabalho baseados em XAML
Neste momento.

Eu tenho uma filial onde trabalhei na adição de suporte para Atividade Dinâmica
além do Net Standard 2.0 https://github.com/ewinnington/corewf .

O processo de análise XAML requer que a Microsoft abra System.XAML
suficiente para que possamos progredir na análise dos arquivos corretamente.

Você pode acompanhar o progresso do problema aqui: dmetzgar/corewf#6
https://github.com/dmetzgar/corewf/issues/6 e em minhas várias tentativas
ao alertar sobre este assunto:
No CoreFX
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
Na fonte de referência
https://github.com/Microsoft/referencesource/issues/39

O pacote de compatibilidade .Net
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
tem um "Talvez" na frente do System.XAML. Mas nenhuma notícia foi filtrada sobre sua
inclusão. O problema Ship .Net Framework Compatibility Pack
https://github.com/dotnet/corefx/issues/24909 atualmente lista "não
planos" para System.XAML.

Talvez também o problema Customer Adoption Epic
https://github.com/dotnet/corefx/issues/24751 pode ser usado para dizer
sua história de como adicionar Workflow Foundation (e System.Xaml) permitiria
sua empresa para enviar um produto.

Minha empresa também está investida na WF: Temos um produto para empresas de Energia
onde nossos clientes criam fluxos de trabalho usando o Workflow Foundation.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

Oi,
Este é um mundo de micro serviços e todo o material é dividido em componentes. Agora, se tivermos que orquestrá-lo, teremos que depender dos aplicativos lógicos do Azure ou de algum outro fornecedor externo que cobra premium por um fluxo de trabalho. Embora muito pouco produto não .NET WF como o Netflix Conductor, gostaríamos de ter um na versão pura do .NET core. Você pode pegar as pistas do condutor da Netflix em https://github.com/Netflix/conductor e começar a construir um a partir daí. Isso será um grande benefício para os desenvolvedores de nuvem privada que não têm acesso ao Azure Stack e que não podem usar aplicativos lógicos.

Pensei em postar aqui por uma questão de conscientização. Eu estava lendo a seguinte documentação e isso me fez pensar neste tópico:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

Parece que o Dynamics365 e o PowerApps estão fazendo uma combinação mental e estão usando o Windows Workflow em alguma capacidade para lidar com o fluxo de trabalho agora. Claro que tudo isso é apenas para Windows, mas na nova era de multiplataforma, etc... quanto tempo isso vai durar?

Não sei o que devo usar. Eu gostaria que a MSFT fizesse isso. Traga clareza Microsoft.

@VenkateshSrini , você também deve olhar para Cadence: https://github.com/uber/cadence
O modelo é mais parecido com o SWF da Amazon, mas é de código aberto. Nenhum cliente .NET ainda.

Procurando um. Versão do núcleo da rede

Não vai acontecer.

De: VenkateshSrini [email protected]
Enviado: quarta-feira, 26 de setembro de 2018 00:30
Para: dotnet/corefx [email protected]
CC: Jeffrey Michelson [email protected] ; Mencione mençã[email protected]
Assunto: Re: [dotnet/corefx] Port Workflow Foundation para .NET Core (#2394)

Procurando um. Versão do núcleo da rede

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5uewLNgaJpZM4FaQMY .

Que pena

Então, o que a Microsoft está oferecendo para ifttt ou fluxo de trabalho no ecossistema não Azure. Quando eles querem habilitar coisas como ml do Azure, por que não fluxos de trabalho

Confira o trabalho de Dan Gerlag.

https://github.com/danielgerlag/workflow-core

De: VenkateshSrini [email protected]
Enviado: quarta-feira, 26 de setembro de 2018 08:34
Para: dotnet/corefx [email protected]
CC: Jeffrey Michelson [email protected] ; Mencione mençã[email protected]
Assunto: Re: [dotnet/corefx] Port Workflow Foundation para .NET Core (#2394)

Então, o que a Microsoft está oferecendo para ifttt ou fluxo de trabalho no ecossistema não Azure. Quando eles querem habilitar coisas como ml do Azure, por que não fluxos de trabalho

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY .

Existe o CoreWF, que é uma porta da base do Workflow para o .net core. Esta porta está progredindo. Estamos procurando pessoas para ajudar.

O próximo passo importante é compilar fluxos de trabalho carregados com Roslyn para que possamos usar código nos parâmetros de fluxo de trabalho, isso é necessário para fluxos de trabalho definidos por XAML. Se você definir fluxos de trabalho no núcleo Imperative, poderá usar o CoreWF agora.

Obrigado pelo seu trabalho @ewinnington e @dmetzgar ! O suporte a XAML por meio do Portable.XAML no CoreWF é um grande negócio para esse esforço. @dmetzgar Você planeja publicar uma nova versão no NuGet em breve?

Olá a todos,

Esta toda a produção está pronta. Estamos aguardando a definição do fluxo de trabalho a ser feito a partir da Ui externa. Mas o mecanismo deve ser capaz de carregar a definição e trabalhar a partir dele. Mais do tipo iffft

@VenkateshSrini , não acho necessário que a Microsoft forneça uma estrutura de fluxo de trabalho multiplataforma. Nos dias do .NET Framework, a Microsoft fornecia tudo, o que prejudicava a comunidade em geral. Eu gostaria de ver mais bibliotecas de código aberto .NET adotadas por organizações e "prontas para produção".

@watertree , estou aguardando uma nova versão do Portable.Xaml. Há uma correção crítica necessária para o suporte ao CoreWF XAML.

Qual é a alternativa para fluxos de trabalho de longa duração por enquanto (com persistência)? Só os pagos?

@freerider7777

FYI: https://github.com/danielgerlag/workflow-core

Usamos em nossa empresa com resultados muito bons.

Para aqueles que ainda seguem, o projeto CoreWf acaba de avançar um marco significativo com a integração do Roslyn para permitir a execução de fluxos de trabalho XAML carregados dinamicamente. Se você ainda precisa do Workflow Foundation no dotnet core, confira.

Oi ,
Isso significa que posso pegar o fluxo de trabalho XAML existente e usá-lo como está. Temos alguma limitação

Temos alguma limitação

O armazenamento de instâncias ainda não foi portado, o designer não está no núcleo e o serviço WCF não está disponível porque o servidor WCF ainda não está no núcleo.

Por favor, faça um problema no repositório CoreWf e liste os requisitos que você possui. Podemos continuar a conversa por lá.

O nuget atual para corewf está desatualizado e não inclui a execução Xaml de tempo de execução baseada em Roslyn que acabou de ser mesclada. Ainda estamos procurando feedback para ver o que funciona e o que não funciona.

Isso significa que isso nunca vai acontecer?

Isso não vai acontecer. Isso nunca iria acontecer - - sem ofensa para aqueles que se esforçaram ao máximo. Confira o projeto de Dan Gerlag (https://github.com/danielgerlag/workflow-core) ou morda a bala e embarque no trem do Azure LogicApps.

Olá, esta é a chamada de outubro de 2020. Alguma notícia/atualização/lançamento no Workflow Foundation no .NET Core?

ou devemos todos nos mudar para Elsa? https://elsa-workflows.github.io/elsa-core/

@wstaelens Acho que a resposta do MS foi bem clara : o WF não será oficialmente portado para o .Net Core. A alternativa sugerida é CoreWF .