Runtime: Migrar Workflow Foundation a .NET Core

CC: @terrajobst , @joshfree , @weshaggard

Necesitamos que System.Xaml esté abierto antes de que se pueda hacer un esfuerzo serio en la portabilidad.

Entiendo a @jakesays .

El punto es que WF puede tener sus definiciones de flujo de trabajo hechas en clases de C# en lugar de XAML (por ahora) y muchas personas ni siquiera usan la representación XAML de este. Más tarde, cuando se abre System.Xaml, también podemos integrar el diseñador visual y las definiciones XAML. Además, estamos trabajando en un motor de flujo de trabajo que sigue estrictamente el uso/implementación de WF, pero en lugar de usar XAML como almacenamiento base para las definiciones de flujo de trabajo, lo tenemos basado en Json para la tienda, lo que abre muchas oportunidades para los nuevos diseñadores de flujo de trabajo en cualquier plataformas (no solo VS o el componente de diseño alojado para WPF/WForms) y tienen varios beneficios como lectura/escritura más rápida, simplicidad del esquema, carga/compilación más rápida y operaciones de tiempo de ejecución. Incluso se puede utilizar para potenciar los flujos de trabajo de los clientes, para guiar los flujos de la interfaz de usuario de la aplicación en las aplicaciones de Windows Phone/Store, por ejemplo, debido a su tiempo de ejecución ligero.

Realmente creo que WF es un componente REALMENTE poderoso en la plataforma .Net, pero para las tecnologías actuales, XAML sigue siendo un "limitador" pero, si por una decisión estratégica de MS, podemos mantenerlo como está y migrarlo a CoreCLR.

Gracias

@zhenlan puede hablar sobre el pensamiento actual en torno a WF

@galvesribeiro muchas personas pueden no usar xaml, pero muchas lo hacen, y de hecho se considera una parte central de WF. Usamos xaml ampliamente, por lo que vería que WF sin soporte xaml apenas vale la pena usar.

Preferiría que siguiéramos presionando a Microsoft para que abra System.Xaml.

Y usar JSON como reemplazo simplemente no es atractivo en lo más mínimo.

@galvesribeiro @jakesays Realmente nos gusta saber cuánto están interesados ​​los clientes de WF en tener la versión .NET Core de WF, por lo que es genial escuchar los comentarios de la comunidad. Si hay suficiente demanda, será útil para nosotros seguir adelante.

Estamos en una etapa temprana de evaluación de la viabilidad, las dependencias, las prioridades de las funciones, etc. Por lo tanto, será muy útil para nosotros saber qué escenarios tiene en mente, por qué WF en .NET Core (vs. WF en .NET completo) será útil para usted y qué características de WF le gustaría ver primero.

@galvesribeiro En su escenario con la creación de flujos de trabajo en código y el almacenamiento de esas definiciones como JSON, ¿qué está (¿planeando?) usar para las expresiones? ¿Utiliza expresiones VB, expresiones C# o tiene sus propias actividades de expresiones basadas en CodeActivity para tratar con expresiones?

Gracias por el aporte.

@jakesays está bien que use XAML. Solo me importa el rendimiento...

@zhenlan Tenemos un interruptor de pago electrónico que procesa miles de millones de transacciones con tarjeta de crédito/débito al día para algunos bancos aquí en Brasil y algunos otros en el extranjero. Estábamos completamente en las instalaciones y estamos actualizando la tecnología para que sea completamente en la nube y se ofrezca como un servicio en Azure. Obtuvimos un Acuerdo Enterprise para explorar todo lo que necesitamos de Azure aquí como una plataforma de procesamiento de pagos de múltiples inquilinos para nuestros clientes.

Estamos investigando el uso de NanoServer para y CoreCLR para que podamos reducir el espacio ocupado, la superficie de ataque y el mantenimiento gastado para ejecutar nuestros servicios y notamos que coreCLR no tiene (al menos) System.Activities portado todavía. En otras palabras, no hay Workflow Foundation.

Nuestro motor de procesamiento central es un motor comercial construido sobre WF superior y contiene más de 40 actividades personalizadas enfocadas en nuestro negocio. Este motor procesa en tiempo real el proceso/reglas de la transacción para obtener la aprobación de la transacción. Necesitamos escalarlo sobre la demanda, y lo hacemos con la implementación actual de WF en la nube, digamos que no es factible.

Portarlo a .net core, en lugar de mantenerlo en .net completo (perfil de servidor), abrirá las posibilidades de ejecutar flujos de trabajo de clientes, eso es algo que realmente extrañamos en nuestro negocio. Esos flujos de trabajo de clientes pueden hacer que las personas desarrollen una lógica de negocio de cliente declarativa, de manera que dispositivos pequeños como teléfonos inteligentes, dispositivos portátiles, IoT y nuestros dispositivos de terminales de pago puedan tomar algunas decisiones sin escribir código repetitivo real.

Dado que no encontramos ningún esfuerzo en WF para .net Core, e incluso no cambió durante años y aún depende de XAML, decidimos iniciar nuestro propio motor de flujo de trabajo que se comporta exactamente de la misma manera que WF. Mismo modelo de actividades, mismo estilo de código, etc., pero mucho más ligero y basado en Json como su almacén de definiciones. Esto permite que los dispositivos con poca potencia informática procesen los flujos de trabajo sin la sobrecarga de tratar con XAML/XML, por lo que la mayor parte de nuestro código creado para WF funciona sin muchos cambios en las definiciones de Json en lugar de los flujos de trabajo basados ​​en XAML. Además, alejarse de XAML abrirá la posibilidad de que los nuevos diseñadores de flujo de trabajo... No se queden atascados en Visual Studio y en las aplicaciones WPF para volver a hospedar el diseñador de VS.

Lo que estoy tratando de sugerir es una de esas opciones:

1. Puerto WF (con XAML) tal cual para .Net core. Estas opciones llevarán mucho más tiempo ya que WF hoy en día depende del perfil del servidor de .Net, lo que hará que dediquemos mucho tiempo a desacoplarlo para que funcione con .Net core.
2. Port WF reescribiéndolo a .Net core. De esta forma, podemos obtener los conceptos básicos y centrarnos en diseñar un motor más liviano que pueda ejecutarse en servidores, clientes, IoT o lo que sea necesario, manteniendo los principios de diseño y las funciones que se implementan actualmente en WF. De esta manera, hacemos que sea realmente un esfuerzo pequeño y un proceso sin fricciones para migrar de XAML a (por ejemplo) definiciones de flujo de trabajo basadas en Json. Todas las actividades actuales deben ser portadas al nuevo modelo.

No te estoy pidiendo que construyas un equipo o que te involucres en un nuevo producto. La comunidad puede hacerlo como lo está haciendo con ASP.Net y Entity Framework. Conviértalo en un marco externo y auxiliar, no incrustado en el núcleo.

Gracias

@jimcarley Las expresiones se compilarían de la misma manera que hoy en XAML. En uno de nuestros flujos de trabajo tenemos esto (también puede ser un VBValue, acabo de recibir una muestra):
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

Las expresiones en XAML hoy en día, en su mayoría devuelven un booleano, o asignan algún valor a alguna variable, por lo que esto se almacenaría de la misma manera que se almacena hoy en día en XAML, pero en Json y se podría compilar siguiendo las mismas ideas. hoy dia.

Si observa Azure Resource Manager (ARM), ¡ya lo hicieron! Tienen el despliegue de recursos hecho como una plantilla Json, que tiene dependencias y un flujo, y las variables se pueden llamar como expresiones. Mira esto:

"variables": {
"ubicación": "[grupo de recursos().ubicación]",
"nombredeusuarioYContraseña": "[concat('parámetros('nombre de usuario'), ':', parámetros('contraseña'))]",
"authorizationHeader": "[concat('Basic', base64(variables('usernameAndPassword')))]"
}

Ok, están usando funciones de JavaScript pero el principio es el mismo. Tienen una variable $schema en la parte superior de la plantilla que guía la estructura del documento, pasos en el proceso de implementación que podemos realizar como actividades. El diseño es bastante similar al de WF, pero este DSL se centra en la implementación del grupo de recursos. Podemos hacerlo más general y usar actividades de la misma manera que lo hacen en la implementación actual de WF.

Si ustedes deciden que vale la pena intentarlo, podemos comenzar a dibujar alguna documentación sobre otro tema que guiará la arquitectura del "nuevo WF". Si suena tan loco y está fuera de sus planes, hágamelo saber, aún lo desarrollaremos de nuestra parte para admitir .net core y lo lanzaremos más tarde como un nuget para las personas. Solo estoy tratando de actualizar este maravilloso marco con las tecnologías actuales (próximas). Esta es realmente una necesidad comercial para nosotros. Dependemos mucho de WF, pero si no se vuelve más rápido y compatible con coreCLR, tendremos que comenzar a preparar este nuevo marco para que cuando NanoServer+coreCLR sean RTM, podamos movernos por él.

Por favor, hágamelo saber si tiene alguna pregunta.

Gracias

PD: Estoy en los canales de gitter todos los días si necesitas chatear.

@galvesribeiro Entonces, está utilizando TextExpressionCompiler para compilar las expresiones después de crear el objeto Actividad a partir de la definición del flujo de trabajo que se almacena en el JSON. ¿Correcto?

@jimcarley , aún no tenemos funcionando el compilador de expresiones. Todavía lo diseñamos usando los mismos principios de TextExpressionCompiler pero sí, parece el mismo concepto. Las implementaciones actuales parecen estar vinculadas a System.XAML todavía. Dado que no está abierto, no puedo confirmar si funcionará de la misma manera (internamente) que TextExpressionCompiler, pero sí, después de cargar la actividad, debemos evaluar/compilar las expresiones (si aún no están en un caché) y exponer un objeto Expression en él para ser evaluado por los consumidores de la actividad (si se requiere).

El año pasado trabajé un poco en el lado de la expresión para habilitar el soporte de expresión de C# en los diseñadores de WF autohospedados. Estaba basado en fragmentos de nrefactory y roslyn. Puedo desenterrarlo si alguien está interesado.

@galvesribeiro después de pensar más en su enfoque json, al final creo que realmente no importaría para el nuevo desarrollo. Si MS no abre el soporte xaml, entonces esto podría funcionar.

@zhenlan Estoy de acuerdo con @galvesribeiro en que no necesariamente buscamos MS para formar un equipo para portar WF. Esto definitivamente es algo que la comunidad podría hacer con la orientación de su equipo, etc.

@jakesays Estoy de acuerdo con usted en que el almacenamiento en realidad no importa si estamos creando nuevamente WF para coreclr.

El punto es, ¿por qué seguir usando XML en lugar de Json, ya que tenemos muchas pruebas en la web que comparan el rendimiento de (des) serialización de ambos y json es mucho más rápido y consume menos recursos que él? (por ejemplo, comparando Json.Net de Newtonsoft con serializador XML normal) Si WF se ejecutara en un dispositivo cliente de tamaño reducido (cualquier IoT), cada byte de memoria es importante.

Además, con json, es mucho más sencillo obtener nuevos diseñadores de WF basados ​​en la web de inmediato. La expresión compilación y ejecución no es difícil de implementar. Es aproximadamente un analizador de la cadena para construir el objeto de expresión. La parte difícil (en mi humilde opinión) es obtener intellisense en VS para los tipos utilizados al diseñar el WF, pero estoy bastante seguro de que Roselyn y los servicios de idiomas pueden ayudarnos con eso y VS tiene infraestructura para ello.

@galvesribeiro menciona que ya ha creado su propio motor de flujo de trabajo con definición y serialización de flujo de trabajo basadas en JSON. Si WF fuera portado a Core, ¿realmente lo usarías?

@dmetzgar comenzamos a desarrollarlo y probarlo como una prueba de concepto de que podemos lograr un mejor resultado en un WF más limpio casi sin dependencias del marco, lo cual es bueno para que funcione en coreclr. No lo tenemos listo.

Me encantaría no tener que construir mi propio motor y seguir usando WF incluso si está basado en XAML pero adaptado a coreclr y si sigue el mismo concepto de las versiones coreclr de EntityFramework y ASP.Net, por ejemplo (no dependa de bibliotecas de servidor y se ejecuta en todas partes).

El punto es que, si aún depende de XAML y del perfil del servidor, seguirá siendo lento (requiriendo demasiados recursos), limitado en las opciones del diseñador, etc.

Mi sugerencia es portarlo a coreclr usando Json, y eliminando muchas dependencias que tiene hoy, dejando al usuario capaz de ejecutarlo en cualquier lugar que desee de la misma manera que puede ejecutar ASP.Net vNext en un dispositivo IoT ARM (tan pronto como soporte ARM ¡ya está hecho!) y no se preocupe por las dependencias y el alto consumo de recursos.

Todos nuestros flujos de trabajo de hoy se crean con la versión actual, algunos de ellos se escribieron con código puro y otros con XAML, pero en ambos casos aún tenemos dependencias.

En mi humilde opinión, portarlo a coreclr tal como está, no brinda tantos beneficios a menos que alguien venga con un motor súper nuevo y liviano para el análisis/renderizado XAML/XML tanto para el tiempo de ejecución como para el tiempo de diseño. Pero si deciden portar tal cual, seguiremos usándolo de todos modos, ya que hará que mis flujos de trabajo XAML funcionen (espero) desde el día 0, incluso si sé que no traerá ningún beneficio práctico...

Una vez más, yo (probablemente @jakesays y otros usuarios de WF) puedo ayudar en este puerto de ambas formas (XAML o JSON), independientemente de lo que decidan ustedes. Solo quiero asegurarme de que este puerto no es solo copiar, pegar y arreglar para que funcione, y en cambio, brinda beneficios reales para las personas que lo usan siguiendo la misma idea de coreclr y puede ejecutarse en todas partes sin problemas.

Gracias

@galvesribeiro Estoy de acuerdo en que XAML está demasiado integrado en WF. Volviendo al libro original de Dharma sobre el flujo de trabajo, tenía una muestra que creaba un flujo de trabajo de Visio. Al menos con la migración al núcleo, podemos dividirlo para que el tiempo de ejecución sea independiente de XAML. Eso nos permite continuar con o sin la migración del equipo XAML al núcleo y siempre podemos agregar la compatibilidad con el flujo de trabajo XAML más adelante como un proyecto de GitHub/paquete NuGet independiente. Definitivamente estoy a favor de hacer posible definir y persistir flujos de trabajo en cualquier formato. Gracias, este comentario es útil.

@dmetzgar No tengo dudas de que algún día XAML se trasladará al núcleo... Si .net core se va a ejecutar en un teléfono con Windows o en cualquier dispositivo móvil con Windows 10, sucederá en algún momento y estoy completamente de acuerdo con usted en que podemos construir un nuevo núcleo, y agregue la persistencia de ambas definiciones y el estado del flujo de trabajo más tarde también.

Entonces, ¿qué debemos hacer para comenzar a portarlo? (ya firmamos el acuerdo de colaborador y tenemos otros NDA como empresa con EM, etc.)

Gracias

@galvesribeiro agradezco el entusiasmo! Tan tentador como es abrir un repositorio de GitHub y comenzar a piratear, hay algunos pasos involucrados. Además, no es solo System.Xaml lo que debe ser tallado. Hay otras dependencias profundamente arraigadas en WF como System.Transactions y algunos componentes compartidos con WCF. Estamos investigando cada uno de estos.

Entiendo. Bueno, no quiero presionarlos, solo me preocupa el tiempo. Tenemos que tomar una decisión ahora para avanzar en la construcción por nuestra cuenta, o unirnos a la comunidad aquí y transferir WF a coreCLR para que pueda cumplir con nuestra línea de tiempo para nuestro producto.

@dmetzgar ¿Ha considerado publicar las partes que pueden ser de código abierto ahora mismo en https://github.com/Microsoft/referencesource? Creo que podría ser significativamente más simple que crear un proyecto de código abierto completo que realmente funcione.

De esa manera, puede tomarse su tiempo con la versión adecuada y otros pueden crear sus propias versiones parciales/personalizadas mientras tanto.

Los componentes de @svick WF en .NET completo ya se publicaron en la fuente de referencia de github hace un tiempo. Por ejemplo, puede encontrar https://github.com/Microsoft/referencesource/tree/master/System.Activities

@zhenlan sí, el problema es que algunas dependencias no se pueden "resolver"... No puedo ver cuál es el comportamiento de algunas clases correctamente, debido a su dependencia en System.Xaml que no es público...

Siempre podemos averiguar por nuestro final, pero significará que no sabemos con certeza si estamos siguiendo el mismo camino.

@dmetzgar System.Transaction es algo que no está abierto (¿todavía?), pero creo que podemos solucionarlo (por ahora). Con respecto a WCF, el árbol de dependencia solo me muestra actividades y el host de servicios de flujo de trabajo. Nada en el núcleo (IIRC) depende de WCF...

@galvesribeiro La situación con System.Transactions es más compleja que eso. Está esparcido por todo el tiempo de ejecución de WF y depende en gran medida de la creación de instancias duraderas, que es donde están las clases base para la persistencia. WCF y WF se fusionaron en el mismo equipo alrededor del período de tiempo de .Net 4.0, por lo que tenemos elementos como System.ServiceModel.Internals utilizados tanto por WCF como por WF. .Net core tiene muchas de las cosas importantes portadas, pero faltan muchas. Trabajar alrededor de las piezas que faltan puede requerir cambios de diseño o reescrituras de características.

Ninguno de estos problemas es insuperable, simplemente no quiero trivializar el esfuerzo. Eso se aplica al código y todo lo que lo rodea, como obtener la aprobación legal, crear entornos, probar la infraestructura, etc. Definitivamente queremos que la comunidad ayude y estamos trabajando para lograrlo. Si debe escribir su propio puerto o esperar al "oficial" depende de su marco de tiempo. La ejecución de flujos de trabajo en el servidor Nano es uno de nuestros escenarios más importantes y me encantaría contar con su ayuda.

@dmetzgar Lo entendí, siempre tenía algún retraso cuando cualquier pregunta tenía que enviarse a relaciones públicas o legal cuando estaba de tu lado :)

Bueno, si al menos tenemos una noción de algún marco de tiempo, podemos prepararnos y esperarlo. Odio la idea de implementar algo en "el lugar equivocado" o cuando ya se están realizando algunos esfuerzos en algún lugar en el que podemos unir fuerzas para hacerlo mejor.

Avíseme si hay algo que podamos hacer, o si tiene alguna noticia, o envíeme un mensaje si necesita alguna sugerencia con respecto al diseño/puerto.

Gracias

A medida que el calendario se aclare, haré actualizaciones en este hilo. Me encantaría saber qué otros escenarios les interesan a las personas. WF en Nano es el escenario principal en este momento, pero sería bueno saber qué están haciendo los demás.

Hola chicos, además de XAML y JSON, hay una manera GENIAL de componer actividades: la metaprogramación. Eche un vistazo a mi proyecto experimental: Metah.W: un lenguaje de metaprogramación de flujo de trabajo (https://github.com/knat/Metah).

@jakesays ¿Puede brindar alguna orientación sobre cómo habilitar la compatibilidad con expresiones de C# en WF autohospedado?

Conserve Xaml. :) Los objetos serializados JSON también serían interesantes. Pero preferiría ver proveedores que estén configurados de alguna manera en el marco para elegir el formato preferido.

@dmetzgar (y otras personas de MSFT) ¿hay alguna noticia sobre este tema?
Gracias

Hemos estado trabajando en esto y hemos avanzado mucho. Actualmente, XAML no está disponible en Core, por lo que nos centramos en el tiempo de ejecución. Estamos considerando abrirnos a otros serializadores. Entonces, en lugar de elegir entre JSON o XAML, preferimos permitirle traer su propio serializador. Todavía hay más asuntos legales y de cumplimiento para ser aprobados. Dado que no muchos clientes están presionando por este puerto, ha sido una prioridad menor.

@dmetzgar dulce! Estaría más que feliz de contribuir a él como pueda si esto se convierte en un proyecto central... ya sea un diseñador de flujo de trabajo web, etc. Parece que xaml apenas necesita estar allí para el formato de definición... emocionado de escuchar sobre este trabajo!

¡Hola chicos, feliz navidad y próspero año nuevo!

Entonces, ¿tenemos alguna actualización sobre ese puerto o al menos una versión OSS del trabajo actual para que podamos ayudar en eso?

Gracias

@galvesribeiro Intentaré explicar la situación lo mejor que pueda. En mi afán por migrar WF a .NET Core, no tuve en cuenta el lado comercial de todo esto. WPF/XAML no está portado a .NET Core y eso representa una parte importante de WF. Si bien XAML no es esencial para el tiempo de ejecución, es la forma en que la mayoría de los clientes crean flujos de trabajo. Esto limita la audiencia que encontraría útil WF en Core. Uno de los temores es que lancemos WF en Core y no haya mucha participación de la comunidad. Esto se suma a nuestro costo de soporte y no mejora la situación de la mayoría de los clientes de WF. Si bien es genial ver que WF se ejecuta en una máquina Linux, es difícil probar que alguien realmente lo usaría.

Conozco OmniXAML y hemos logrado convencer al autor para que cambie a una licencia MIT. Entonces, con algo de inversión, potencialmente podríamos hacer que XAML funcione. Pero aún queda la pregunta de cómo esto beneficia a los clientes existentes de WF. Si un día aparece un gran cliente como SharePoint o Dynamics y dice que se cambiará a Nano, entonces tendríamos un caso convincente. Sin embargo, todo eso es discutible si el equipo de .NET Framework decide crear un paquete que pueda ejecutar el marco completo en Nano.

Si hubiera suficiente interés de la comunidad y alguien dispuesto a defender el proyecto, podríamos intentar hacerlo de esa manera. Algo así como Open Live Writer. La parte complicada es que, si bien mi equipo contribuiría a esto tanto como fuera posible, ese tipo de proyecto no contaría con el soporte de Microsoft. Sospecho que la mayoría de los clientes de WF usan WF principalmente porque Microsoft lo admite.

Creo que es importante resaltar que .NET Core y .NET Framework completo son dos productos diferentes. .NET Framework no se está muriendo de ninguna manera. Continuaremos apoyándolo, agregando funciones, etc. Por lo tanto, no es como si tuviéramos que migrar WF a .NET Core para mantenerlo vivo. WF on Core sería básicamente un nuevo producto. Llegar a una justificación comercial sólida es difícil. Incluso podría ser una cuestión de tiempo. A medida que más empresas adopten servidores Nano, puede haber un caso más sólido.

@dmetzgar ¿Qué hay de Portable.Xaml, podría ser una alternativa? https://github.com/cwensley/Portable.Xaml Ha sido extraído para uso del autor del fantástico proyecto Eto.Forms para Eto. Tiene licencia MIT y (al igual que las bibliotecas de clases de las que se deriva en el proyecto mono).

@dmetzgar ,

Intentaré explicar la situación lo mejor que pueda. En mi afán por migrar WF a .NET Core, no tuve en cuenta el lado comercial de todo esto. WPF/XAML no está portado a .NET Core y eso representa una parte importante de WF. Si bien XAML no es esencial para el tiempo de ejecución, es la forma en que la mayoría de los clientes crean flujos de trabajo. Esto limita la audiencia que encontraría útil WF en Core. Uno de los temores es que lancemos WF en Core y no haya mucha participación de la comunidad. Esto se suma a nuestro costo de soporte y no mejora la situación de la mayoría de los clientes de WF. Si bien es genial ver que WF se ejecuta en una máquina Linux, es difícil probar que alguien realmente lo usaría.

Creo que la mayor motivación para los usuarios actuales de WF es Nano server y Micro Services y no Linux. Linux agregará más usuarios, pero no es la verdadera motivación.

Pero aún queda la pregunta de cómo esto beneficia a los clientes existentes de WF.

Estamos en días de nubes. Recuerde, "Primero la nube, primero los dispositivos móviles..." y una de las grandes tecnologías que están creciendo son los contenedores, los microservicios y una gran oferta de MS para todo es Nano Server.

Si un día aparece un gran cliente como SharePoint o Dynamics y dice que se cambiará a Nano, entonces tendríamos un caso convincente.

Incluso con la mayor implementación de Sharepoint o Dynamics en la tierra, nunca alcanzaremos la misma cantidad de usuarios e incluso diría el mismo nivel de ingresos que el que se realiza con tecnología en la nube.

Sin embargo, todo eso es discutible si el equipo de .NET Framework decide crear un paquete que pueda ejecutar el marco completo en Nano.

DNX hoy (hasta el RC1) se compone no solo de coreCLR. También tiene el marco completo (dnx451), por lo que actualmente podemos usar WF en DNX y ese no es el problema aquí. Estamos hablando de coreCLR (dnxcore50)

Si hubiera suficiente interés de la comunidad y alguien dispuesto a defender el proyecto, podríamos intentar hacerlo de esa manera. Algo así como Open Live Writer.

No lo compararía con lo que se hizo en Open Live Writer... Creo que esto es más o menos lo que se hizo con ASP.Net, MVC, Entity Framework. "Productos" principales de la familia .Net y que hoy en día son de código abierto.

La parte complicada es que, si bien mi equipo contribuiría a esto tanto como fuera posible, ese tipo de proyecto no contaría con el soporte de Microsoft. Sospecho que la mayoría de los clientes de WF usan WF principalmente porque Microsoft lo admite.

De hecho, los clientes de WF usan contratos de soporte de MS... Especialmente los clientes de Dynamics y Sharepoint lo hacen, sin embargo, hay muchas aplicaciones fuera de este mundo que aún requieren soporte. Decir que la gente solo lo usa debido al soporte y que el OSS no es compatible, es casi lo mismo que decir que CoreCLR, EF, ASP.Net no tendrán soporte de MS. Aunque ahora esos proyectos son OSS, los equipos de MS los supervisan y moderan en gran medida.

Por ejemplo, comencé como usuario en el proyecto MS Orleans. Impulsa todos los servicios en la nube de Halo durante casi 7 años. Skype, Outlook y muchos otros servicios públicos/en la nube de MS lo utilizan de alguna manera. Hace unos años, fue OSSed de MS Research y ahora es mantenido por 343 Studios, algunas personas de MSR y algunos otros de otros grupos dentro de MS, pero en su mayoría mantenido por la Comunidad. Hoy, me considero un colaborador activo de ese proyecto y apoyo a los nuevos usuarios junto con otras personas con y sin EM allí. Incluso tenemos personas que son ex empleados (como yo) y que no son empleados de MS dentro del equipo de GH para Orleans. ¿Significa esto que no tenemos soporte? Bueno, no compré Orleans, por lo que legalmente solicito soporte dentro de mis contratos con MS para Orleans específicamente; sin embargo, puedo hacerlo apuntando a .Net Framework o cualquier otro producto relacionado, así que realmente no estoy de acuerdo con su declaración.

Llegar a una justificación comercial sólida es difícil.
Estoy de acuerdo con usted si busca solo clientes de Sharepoint y Dynamics.

Bueno, nosotros, como muchas otras empresas en todo el mundo, mantenemos grandes Acuerdos Empresariales (EA) con Microsoft utilizando la mayoría de los productos variables en esos contratos. En nuestro caso, procesamos millones de transacciones financieras (tarjetas de crédito/débito) por día y cada una representa una instancia de un WF que se ejecuta sobre Orleans y dentro de Microsoft Azure. No sé qué sería grande para ti para actuar como una justificación comercial.

Solo creo que el núcleo (System.Activities), sin XAML, podría trasladarse a coreCLR y los diseñadores podrían crearse a pedido para XAML, Json, HTML, XML, cualquier cosa. Al desacoplar esta dependencia se abren otras posibilidades.

Como dije al comienzo de este hilo, el trabajo más pesado que queremos ahora es obtener un OSSed y alguien (al menos inicialmente) de MSFT, esté disponible para revisar el PR. El sentido común aquí es reescribir WF y no solo copiarlo y pegarlo para coreCLR, por lo que esperamos grandes contribuciones al respecto.

Si eso es algo que no va a suceder, creo que podemos cerrar este problema y al menos la gente comenzará a buscar otros OSS o incluso motores de flujo de trabajo pagados que eventualmente obtendrán soporte para CoreCLR. Simplemente creo que es una gran pérdida no tenerlo dentro de CoreCLR ...

Puedo dar una razón muy sólida por la que WF debería ser portado a .Net Core.

Microsoft está guiando a los desarrolladores hacia la plataforma UWP. UWP será la plataforma Windows del futuro. No tiene nada que ver con la aireada idea de portar aplicaciones a Linux, etc. Es muy necesario que WF se ejecute en máquinas con Windows 10, y UWP es el futuro de la plataforma Windows 10.

Creamos aplicaciones ocasionalmente conectadas. Tenemos un back-end .Net y un front-end UWP. Actualmente, toda la lógica empresarial se comparte entre .Net y UWP. Pero, nos gustaría codificar lógica de negocios en WF. Esto funcionará bien en .Net, pero WF actualmente no es compatible con UWP, por lo que WF se vuelve inútil porque, a menos que el usuario esté conectado a Internet, no puede realizar llamadas validadas por la lógica de WF.

UPW tiene un XamlReader, por lo que analizar XAML no es realmente un gran problema...

@MelbourneDeveloper está de acuerdo con usted en todos los motivos, sin embargo, tenga en cuenta que UWP y .Net Core (al menos ahora) no tienen el mismo nombre, lo que significa que incluso comparten las mismas API de nivel inferior, tienen la misma superficie de API (y . Net Core es OSS mientras que UWP no lo es), no son lo mismo y no son compatibles. En otras palabras, no puede agregar un ensamblado de .Net Core a uno de UWP. Esas diferencias (en mi humilde opinión) eventualmente desaparecerán, pero por ahora, todavía existen...

Si. Comprendido. Fue con la suposición de trabajo de que esas dos cosas se unirán en el futuro. Si no lo son, ¡que Dios nos ayude!

Además, Xaml de @MelbourneDeveloper UWP es una versión completamente diferente y simplificada de Xaml de .NET. UserVoice de WindowsDev está salpicado de (lo que continúa siendo ignorado, como con todo lo que parece UWP, no es de extrañar por qué incluso tienen un UserVoice para empezar) votos para mejorar su 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

Esperemos que hagan lo correcto y apoyen el puerto Mono Xaml y/u OmniXaml de @cwensley como se sugiere. El sistema Xaml de UWP tal como está es realmente una broma y es parte de la razón por la cual su tasa de adopción es tan terrible.

Junto con esa nota, tengo un caso de uso comercial para que los MSFTies lo consideren: NodeJS. Cuanto más nos rasquemos las nueces colectivas sobre este tema, más valor acumulará NodeJS en el mercado, ya que es verdaderamente multiplataforma y verdaderamente ubicuo, algo que la tecnología de MSFT simplemente no puede reclamar en este momento (o en el futuro previsible). NodeJS funciona en el servidor y el cliente (TODOS) y permite la reutilización del código entre los dos. Una base de código funcionará en escenarios nativos (a través de Cordova) y web (a través del navegador HTML5 estándar), que es mucho más económico que lo que tendría que hacer con una solución basada en MSFT.

Pronto llegará al punto en que rehacer un sistema en NodeJS y deshacerse de MSFT por completo será más aceptable (y obviamente menos costoso) que esperar a que (lo que se siente) equipos disfuncionales se pongan al día con las realidades económicas del mercado.

También menciono esto porque se menciona que parece que MSFT cuenta con UWP para su plataforma de cliente, pero llega a una fracción del mercado que alcanza NodeJS. Y cuando digo fracción, eso podría estar exagerando. Estamos hablando de 200 millones (último recuento de instalación conocido de Windows 10) frente a ~3B (BILLONES) de dispositivos a los que pueden llegar las aplicaciones basadas en nodejs.

No me malinterpreten, me encanta MSFT. He invertido más de 15 años de mi vida en sus tecnologías y estoy completamente involucrado aquí, personalmente. Sin embargo, con esa inversión viene la pasión de ver que todos lo hagan bien y estar orgullosos de las decisiones y los esfuerzos realizados aquí con la nueva era de genialidad multiplataforma y de código abierto. También quiero que todos estén al tanto de la amenaza que se avecina en el mercado (y también quizás para verificar/confirmar mis temores).

Finalmente, si todo va bien, tenemos otro gran problema con nuestro estado actual de Xaml multiplataforma, ya que Portable.Xaml es diferente a OmniXaml, por lo que en algún momento, como comunidad, tendremos que averiguar cómo conciliar los dos. bases de código... idealmente. :)

@Michael-DST está de acuerdo contigo en todos los puntos. Uno de los objetivos a los que queremos que se ejecute WF son los clientes (especialmente móviles e integrados). Queremos reducir el código de cliente para las reglas comerciales locales al agregarle WF. Por clientes, no me refiero estrictamente a UWP como dispositivos Windows (teléfonos, tabletas e IoT)...

Creo que hay productos importantes que dependen de WF como BizTalk y Sharepoint, pero aún pueden confiar en la versión completa de .Net, mientras que las personas en .Net Core (y UWP posterior) pueden confiar en las nuevas API de WF/XAML. Sé que implicará una gran cantidad de #ifs en torno a la base de código, pero ese será el camino a seguir...

@galvesribeiro gracias por la verificación/apoyo. Se siente como si estuviera patinando cuesta arriba a veces, ya que nadie parece reconocer este problema muy real (¿existencial?) que enfrenta .NET. De hecho, el liderazgo de .NET está ayudando a exacerbar este problema al recomendar emparejar .NET con AngularJS para aplicaciones web, ¡básicamente desafiando a las organizaciones a cambiar a NodeJS por completo! (divulgación completa, yo escribí eso. :P).

Dudo en publicar mucho aquí con respecto a NodeJS, ya que WF es más una tecnología del lado del servidor, pero de la forma en que yo (y otras organizaciones estamos empezando) a verlo, esto afecta todas las esferas y amenaza a .NET en todos los ámbitos. Es simplemente más rentable (y eficiente en cuanto a alcance de mercado) usar NodeJS como una pila de soluciones en la actualidad y estamos (nuevamente, odio repetirme, pero no realmente) viendo esto reflejado en las organizaciones por su tecnología de elección.

En pocas palabras: tengo que colocar mi angustia _en algún lugar_ y este hilo es la víctima. :P #lo siento, no lo siento

Con respecto a #if defs... puaj, citaré el Manifiesto MvvMCross aquí: "# es para Twitter, no para código". :PAGS

FINALMENTE, olvidé etiquetar a @SuperJMN , ya que él también debería estar al tanto de este hilo/discusión (como autor de OmniXaml). ¡Sin intención de faltarle el respeto, amigo! Abordaré personalmente el problema OmniXaml vs. Portable.Xaml en la próxima semana más o menos.

@Michael-DST, sí... En realidad, el #si es solo de una manera... El equipo de Net Core adoptó el enfoque de "Native Shims", donde la implementación real (específica del sistema operativo) se abstrae en una delgada capa inferior de código nativo. En el caso de WF podría ser un shim para .Net Full y otro para .Net Core por ejemplo...

No soy fanático de Node.js ni de JavaScript (suelo pensar que todavía es un lenguaje de scripting, no de programación, pero esa es mi opinión), pero debo admitir que hoy en día, nada se compara con él. en términos de xplat. Microsoft mismo lo usa para sus agentes de compilación en VSTS (solo para nombrar 1 caso, hay otros en MS) ya que se ejecuta en cualquier plataforma, por ejemplo...

Creo que WF es una pieza de tecnología increíble cuya versión actual estaba destinada a los usuarios del lado del servidor, sin embargo, con .Net Core, y también puede funcionar perfectamente en los clientes...

@galvesribeiro ... estoy contigo al 100%. EF Core 1.0 es de la misma manera... una tecnología tradicionalmente del lado del servidor que ahora también se puede usar en el lado del cliente. Sería muy útil tener WF disponible de esa manera también.

Además, es bueno escuchar acerca de las cuñas. Mucho aprobar. :)

Finalmente, no quiero descarrilar/secuestrar el hilo (mucho) aquí, pero para estar seguro, re: JavaScript: estoy de acuerdo como lenguaje de secuencias de comandos. Sin embargo, también es un "lenguaje" muy flexible que se puede utilizar de otras formas, sobre todo el código de bytes (más o menos). Como estoy seguro de que ha visto, existe la magia del compilador LVVM para C++. La pregunta creciente/popular en la comunidad de desarrolladores de .NET es hacer lo mismo para .NET (transpilar .NET en JS a título oficial). Esto realmente corregiría todos los males actuales (principales) en el clima actual de los desarrolladores de MSFT.

De todos modos, de vuelta a su programación habitual. :P ¡Gracias por el diálogo y los pensamientos!

Ustedes están tocando algunas cosas con las que he estado lidiando durante 9 años. Hay algo que mucha gente que trabaja con tecnologías de Microsoft no entiende; es decir, el concepto de computación distribuida. Un requisito fundamental de nuestro software desde el principio es que funcione en modo ocasionalmente conectado. Con el tiempo, Microsoft ha intentado varias veces proporcionar herramientas para esto, pero nunca se ha desarrollado un marco integral. Tenemos un poco de marco de sincronización por aquí, un poco de una base de datos LINQ por allá, pero no hay un conjunto completo de herramientas para hacer que todo funcione en conjunto.

Durante los últimos 9 años hemos estado desarrollando nuestro propio marco ocasionalmente conectado. Ahora se ejecuta en .Net, Silverlight y UWP. Hicimos todo lo posible para aprovechar los marcos de trabajo de Microsoft como EF y WF, pero no se ofreció soporte para estas tecnologías en plataformas de tecnología cliente como Silverlight. Literalmente, creamos nuestro propio ORM y marco de sincronización para Silverlight que ahora es compatible con UWP.

Cuando hubo mucho revuelo en torno a WF en primer lugar, fue bastante emocionante porque ofrecía una forma de codificar la lógica empresarial sin código. Pero, a medida que pasaba el tiempo, me volví cada vez menos inclinado a pensar que alguna vez habría un puerto para una tecnología del lado del cliente como Silverlight. Publiqué numerosas preguntas sobre esto en los foros, pero la respuesta siempre fue la misma: WF es una tecnología del lado del servidor, ¿por qué querrías usarla en Silverlight?

como dijo galvesribeiro

"Creo que WF es una pieza de tecnología increíble cuya versión actual estaba destinada a los usuarios del lado del servidor, sin embargo, con .Net Core, y también puede funcionar perfectamente en los clientes..."

Y

"Uno de los objetivos en los que queremos que se ejecute WF son los clientes (especialmente móviles e integrados). Queremos reducir el código del cliente para las reglas comerciales locales agregando WF. Por clientes, no estoy hablando estrictamente de UWP como los dispositivos Windows. (teléfono, tabletas e IoT)"

Lo que la gente tiene que entender es que cuando se trata de computación distribuida, no hay distinción entre la tecnología del cliente y la del servidor. Piensa en la forma en que funciona Git. El código para Git es el mismo independientemente de si está mirando el repositorio central o un nodo en la red en algún lugar. El código está duplicado en todas partes. Es lo mismo con nuestro marco. La lógica empresarial se duplica en todos los nodos. Esto se debe a que incluso si el usuario no está conectado a la red, aún debe estar sujeto a la misma lógica comercial. En la computación distribuida, cada computadora ES literalmente un servidor. Literalmente ejecuta el mismo código que el servidor.

Nunca pudimos aprovechar WF porque no podíamos ejecutar el código WF en Silverlight y ahora no podemos ejecutarlo en UWP. Es alentador ver que EF se transfiere a UWP. Quizás este sea el comienzo de que Microsoft comprenda que la computación distribuida es una necesidad. Pero, Microsoft necesita incorporarse a la computación distribuida e incluir WF como parte de todo el marco de computación distribuida. Tal vez entonces podamos eliminar nuestro marco informático distribuido y ya no tendré que mantener ese código.

Realmente una gran perspectiva y pensamientos @MelbourneDeveloper. Gracias por compartirlos. También era un gran admirador de Silverlight y he estado manoseándolo desde entonces (de ahí mi voto resultante y, en realidad, el sitio de arriba). Además, tengo curiosidad por saber qué piensa de Azure Mobile Services y si ha considerado usar eso en su historia fuera de línea. Soy un novato con computación distribuida (pero entiendo lo que tienes que decir), pero realmente estoy buscando entrar en esto el próximo año (también estoy escuchando muchos microservicios, ¿cuál creo que es el último equivalente de esto?) .

Lo que la gente tiene que entender es que cuando se trata de computación distribuida, no hay distinción entre la tecnología del cliente y la del servidor.

Muy buen punto. En este punto, se trata de dónde se aloja la tecnología. Es decir, usted está realmente limitado por el host de la tecnología que está tratando de "distribuir", diría (y nuevamente, no soy un experto en esto). Cuanto más omnipresente (o fácilmente disponible) sea el host, mejor distribuida/accesible será la aplicación. Annnnnd.... Creo que sabes a dónde voy con eso. :PAGS

En cualquier caso, en realidad se siente como si todos estuviéramos de acuerdo en _algo_ aquí con esta discusión y ese es un cambio/logro bienvenido para mí. ;)

@galvesribeiro

tenga en cuenta que UWP y .Net Core (al menos ahora) no tienen el mismo nombre, lo que significa que incluso comparten las mismas API de nivel inferior, tienen la misma superficie de API (y .Net Core es OSS mientras que UWP no lo es) , no son lo mismo y no son compatibles. En otras palabras, no puede agregar un ensamblado de .Net Core a uno de UWP. Esas diferencias (en mi humilde opinión) eventualmente desaparecerán, pero por ahora, todavía existen...

Eche un vistazo a este PR dotnet/corefx#5760, espero que esto aclare algunas cosas.

El lado .NET de UWP _is_ .NET Core. Sin embargo, .NET Core proporciona múltiples tiempos de ejecución. UWP usa el tiempo de ejecución basado en AOT, por lo que no se admiten ciertas funciones que requieren un JIT (como LCG o RefEmit). Sin embargo, comparten los mismos ensamblajes y (en adelante) los mismos paquetes de NuGet. Diseñamos específicamente la pila para permitir ensamblados (y paquetes) de referencias cruzadas de UWP y ASP.NET Core.

Por supuesto, hay herramientas de VS además de estas llamadas bibliotecas de clases portátiles (PCL) que intentan ayudarlo a crear bibliotecas que funcionarán en un conjunto de plataformas. Hay varias opciones que puede realizar en el cuadro de diálogo de orientación de PCL que dan como resultado que su binario sea compatible con .NET Core. Sin embargo, dado que la portabilidad en VS se determina al observar las plataformas, no podrá hacer referencia a una PCL desde una aplicación para UWP a menos que la PCL indique que puede apuntar a UWP. Este comportamiento es por diseño porque la idea es que las herramientas de PCL lo ayuden a no usar accidentalmente una funcionalidad que no se admite en todos los lugares donde debe ejecutarse. Por el contrario, solo puede hacer referencia a las PCL de las plataformas a las que dice apuntar.

Ya que mencionas explícitamente los apodos, hablemos de esto por un segundo también. El diseño de un moniker (TFM) es que representa la totalidad de la superficie. En nuestras herramientas hay dos apodos:

• TargetPlatformMonikers (TPM)
• TargetFrameworkMoniker (TFM)

Piense en el TFM como una identificación de la totalidad del área de superficie administrada en la caja, mientras que el TPM representa el sistema operativo subyacente, es decir, el conjunto de API proporcionado por el sistema operativo.

Dado que diseñamos .NET Core para que sea portátil a varias plataformas, un TFM tradicional realmente no tiene mucho sentido. Es por eso que existe un nuevo concepto, llamado Standard Platform , antes llamado generaciones.

¿Esto ayuda?

Sin embargo, comparten los mismos ensamblajes y (en adelante) los mismos paquetes de NuGet.

La mayoría de los ensamblajes tienen la misma DLL de implementación BINARIA para las aplicaciones de destino NuGet 'netcore50' (aplicación de Windows UWP Store) y NuGet Target 'dnxcore50' (ASP.NET v5/ASP.NET Core 1.0).

Sin embargo, algunos paquetes de NuGet, como muchos de los paquetes de la biblioteca System.Net.*, tienen diferentes implementaciones para el objetivo 'netcore50' frente al objetivo 'dnxcore50'. Por ejemplo, la biblioteca System.Net.Http con 'netcore50' usa la implementación WinRT Windows.Web.Http debajo. La implementación 'dnxcore50' usa algo más (WinHTTP nativo).

Sin embargo, algunos paquetes de NuGet como muchos de los paquetes de la biblioteca System.Net.* tienen diferentes implementaciones para el objetivo 'netcore50' frente al objetivo 'dnxcore50'.

Sí, debería haber mencionado eso. La forma en que veo esto es que un paquete NuGet proporciona un contenedor que permite al productor proporcionar diferentes implementaciones para diferentes entornos de ejecución, mientras que los consumidores no necesitan saber eso. En ese sentido, los paquetes NuGet son los nuevos ensamblajes.

Gracias @terrajobst y @davidsh por compartir esta explicación más profunda y el problema de referencia, pero ¿qué hay de malo en lo que dije que "no se puede hacer referencia a 1 ensamblaje de una plataforma en otra"?

La forma en que veo esto es que un paquete NuGet proporciona un contenedor que permite al productor proporcionar diferentes implementaciones para diferentes entornos de ejecución, mientras que los consumidores no necesitan saber eso. En ese sentido, los paquetes NuGet son los nuevos ensamblajes.

Este concepto en realidad no es nuevo... La gente ya crea un paquete Nuget que no es más que una referencia a un montón de otros paquetes, los llamados "meta paquetes". Hay varias formas de hacer que una PCL funcione en muchas plataformas. Las más famosas utilizadas por muchas bibliotecas populares (como Json.Net de Newtonsoft) son Bait and Switch , donde tiene un nuget que tiene una interfaz pública (la superficie API) y un ensamblaje para cada plataforma específica (la implementación real de la superficie API) que incluso pueden tener dependencias diferentes entre sí y en tiempo de ejecución, se seleccionará el ensamblado correcto para esa plataforma. La diferencia ahora es que en lugar de tener varios nugets "dentro" de un solo contenedor nuget donde todos deberían estar en la misma plataforma o 1 ensamblaje de interfaz que solo usa el desarrollo y que cambiará al específico en tiempo de ejecución, tenemos una mezcla de eso! 1 nuget que es un contenedor y, al mismo tiempo, la interfaz pública para todos los nugets específicos de la plataforma vinculados a él.

creo que estamos hablando lo mismo, solo que me exprese mal al principio :smile:

De todos modos, volviendo a WF... Creo que es notorio que la gente quiera tenerlo portado a WF no solo "porque es genial" para ejecutarlo en Linux o en Nano Server. La gente también quiere usarlo de una manera ligera en los clientes.

Una vez más, creo que hay suficientes personas de la comunidad dispuestas a hacer que este puerto suceda...

PD: Para aquellos que estén interesados ​​en la informática distribuida (la real, no la historia del cliente fuera de línea), echen un vistazo a nuestro otro proyecto Orleans , que en realidad es un buen caso de uso para WF en .Net Core y que potencia hoy en día los grandes servicios de Microsoft. como Skype, Halo5, y que yo personalmente uso como mi tecnología central de mi plataforma de procesamiento de transacciones financieras que procesa miles de millones de transacciones de manera distribuida...

@galvesribeiro

¿Qué tiene de malo lo que dije que "1 ensamblaje de una plataforma no puede ser referenciado por otro"?

No es que su declaración esté equivocada; es solo que tampoco está bien :smile: Normalmente, no soy el tipo de persona a la que le gusta criticar, pero lo que me desconcertó fue esta parte:

En otras palabras, no puede agregar un ensamblado de .Net Core a uno de UWP.

Quiero evitar dar la impresión de que UWP y .NET Core son plataformas .NET diferentes, como lo fueron .NET Framework y Silverlight. Diseñamos específicamente .NET Core para que pueda crear ensamblajes que funcionen en todas las plataformas. Por ejemplo, System.Collections.Immutable y casi todo Roslyn son ensamblados de .NET Core que también funcionarán bien en UWP.

Para reformular: nuestro objetivo es crear una plataforma en la que los componentes simples basados ​​en MSIL puedan usar literalmente el mismo binario en todas las plataformas basadas en .NET Core. En los casos en que eso no sea posible, por ejemplo, debido a dependencias nativas o diferentes implementaciones, estamos haciendo exactamente lo que Paul Betts describió con tanta elocuencia como PCL de cebo y cambio : área de superficie portátil, implementaciones variables por plataforma y NuGet como contenedor y selector.

En el mundo de .NET Core, las bibliotecas System no son realmente especiales. Cualquiera puede usar la misma técnica para asegurarse de que la mayoría de los consumidores no tengan que ensuciar su base de código con directivas #if .

creo que estamos hablando lo mismo, solo que me exprese mal al principio :smile:

Creo que hemos creado un mundo en el que es demasiado fácil confundir a la gente, lo que obviamente nos incluye a nosotros :smile: Es por eso que me esfuerzo tanto en ser preciso sobre cómo se creó .NET Core y qué problemas tratamos de resolver.

Sí, tiene usted razón. La impresión es lo que importa.

Espero que algún día también llamemos a .Net Core en UWP para que esto termine... Entonces, todavía necesitamos system.xaml

Si bien está relacionado, creo que System.Xaml es un componente separado que agrega valor por sí mismo. Presenté dotnet/corefx#5766 para rastrear esto por separado.

Gracias Michael-DST

Además, tengo curiosidad por saber qué piensa de Azure Mobile Services (https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/) y si ha considerado usar eso en su historia fuera de línea?

Excelente pregunta. Esto genera una pequeña lección de historia sobre la experiencia de nuestra empresa con la computación distribuida, también conocida como aplicaciones ocasionalmente conectadas, y cómo se relaciona con Azure Mobile Services y la computación distribuida con la tecnología de Microsoft.

Si la gente no ha visto el sitio web mencionado anteriormente, le recomiendo que lo mire. Tiene un buen video sobre Azure Mobile Services.

Hace aproximadamente 8 años creamos una aplicación para la plataforma original de Windows Phone. El de la vieja escuela con .Net Compact Framework. La gente puede burlarse de eso, pero en algunos puntos clave esta plataforma era más avanzada que la plataforma UWP actual en lo que respecta a la tecnología conectada ocasionalmente. Aunque, parece que UWP se está poniendo al día. Las claves del éxito de las aplicaciones ocasionalmente conectadas en esa plataforma fueron:

1) Implementación completa de la base de datos SQL (SQL Server CE)
2) Implementación de Sync Framework entre SQL Server (backend) y SQL Server CE (dispositivo móvil). Esta fue la versión 1 de Sync Framework.

Esta aplicación fue exitosa. Escribimos una capa de datos que se ubicaba sobre la parte superior de SQL CE y SQL Server que se implementó en el servidor y se implementó en los dispositivos. Casi maximizó la memoria, pero funcionó. Los trabajadores de campo pudieron capturar datos en el campo y los datos se sincronizaron con la base de datos central.

Nos horrorizamos cuando se lanzó Windows Phone 7 porque había un problema crucial: todas las bases de datos en el mercado eran bases de datos que no eran SQL. Se implementaron principalmente con LINQ. Esto no era compatible con nuestra capa de datos y EF no existía para Windows Phone 7. Por lo tanto, no pudimos crear un marco ocasionalmente fuera de línea para Windows Phone 7 a pesar de que pudimos crear una solución completa para el original. Plataforma Windows Phone.

Silverlight fue un cambio de juego. Una vez más, nos encontramos con una base de datos SQL completa. Pero Microsoft no había implementado el marco de sincronización para Silverlight o para la base de datos en línea en cuestión. Entonces, comenzamos a escribir nuestro propio marco de sincronización modelado a partir del marco de sincronización de Microsoft. El marco de sincronización de Microsoft se basa en marcas de tiempo. Esto es lo que implementamos en nuestro marco de sincronización. Una vez más, tuvimos un éxito total con Silverlight. Los trabajadores de campo pudieron llevar las tabletas de Windows al campo, capturar datos y luego sincronizarlos con la base de datos central. El problema era que esto nunca estuvo disponible para teléfonos. La plataforma de base de datos no existía para Windows Phone 7.

Como mencioné anteriormente, queríamos implementar la lógica comercial con WF, pero Silverlight se abandonó y nadie habló siquiera de la posibilidad de migrar WF a Silverlight.

Finalmente, llegamos a UWP. Se ha escrito un contenedor para SQLite para UWP y, con algunos ajustes al contenedor, pude ampliar la interfaz con SQLite para permitirnos trabajar de nuevo con una base de datos SQL completa. Eso significa que nuestra capa de datos es compatible con ella. Nuestra capa de datos y las capas de sincronización ahora funcionan en .Net, Silverlight y UWP, con SQL Server, SQLite y otra plataforma de base de datos sin nombre.

Hoy es la primera vez que veo una sincronización con tecnología pura de Microsoft gracias a Michael-DST. Básicamente, puedo decir que la sincronización de Azure Mobile Services es simplemente Microsoft Sync Framework renombrada. Tiene una interfaz API un poco diferente, pero los conceptos básicos son los mismos que el marco de sincronización original de Windows Phone que usamos para que la sincronización funcionara hace unos 8 años. Puedo ver que incluso usa los mismos dos campos de marca de tiempo para rastrear los cambios de datos. Estos se introdujeron en SQL Server como una función central en SQL Server 2008. Nuestro marco de sincronización funciona más o menos de la misma manera que el marco de sincronización de Microsoft.

Entonces, para responder a la pregunta de Michael, investigaré esta tecnología. Veré si puede reemplazar nuestro marco de sincronización. Me encantaría tirarlo y dejar que alguien más lo mantenga. Al ver que mencionaron que admitirá SQLite, suena prometedor porque parece que podremos piratear el envoltorio de SQLite para continuar usando la base de datos SQL completa y, por lo tanto, poder continuar usando nuestra capa de datos. Si ese es el caso, significará que más de 5 años de código del marco de sincronización irán directamente a la papelera.

De todos modos, el punto es que parece que Microsoft está reconociendo una vez más que la computación distribuida es importante. Si es importante, WF debe migrarse a UWP. UWP es el futuro y, por lo tanto, también es el futuro de la computación distribuida con tecnología de Microsoft. El futuro de la tecnología distribuida necesita WF.

Si bien está relacionado, creo que System.Xaml es un componente separado que agrega valor por sí mismo. Presenté dotnet/corefx#5766 para rastrear esto por separado.

¡Muchas gracias @terrajobst! No estoy de acuerdo con todo lo que publicas en línea/twitter, pero soy un gran admirador de cómo facilitas el diálogo y la comunicación entre los desarrolladores/la comunidad y siempre estaré de acuerdo con eso. :) Esto realmente significa mucho para mí personalmente, ya que parece más de un año de patinar cuesta arriba para obtener algo de MSFT (y sí, me doy cuenta de que no es un compromiso, pero en este punto todo tiene sentido).

Entonces, para responder a la pregunta de Michael, investigaré esta tecnología.

Impresionante @MelbourneDeveloper , ¡feliz de ayudar! Siento que Azure realmente tiene un control sólido sobre su grupo. Junto con VSO/VSTS, realmente escuchan a sus desarrolladores y hacen *_mucho *_done. De hecho, este parece ser el caso con todos los grupos en MSFT _excepto_ para el grupo UWP, que realmente no parece hacer mucho y ni siquiera parece entender su propia tecnología (y ni siquiera entremos en su definición de "Xaml").

Actualmente usamos WF para varios de nuestros servicios principales e incluso ahora estamos ampliando nuestro uso porque hemos tenido una gran experiencia con Workflow y tenemos nuestra lógica comercial en un formato tan visual y fácil de entender.

Como dijo @MelbourneDeveloper

De todos modos, el punto es que parece que Microsoft está reconociendo una vez más que la computación distribuida es importante. Si es importante, WF debe migrarse a UWP. UWP es el futuro y, por lo tanto, también es el futuro de la computación distribuida con tecnología de Microsoft. El futuro de la tecnología distribuida necesita WF.

WF ha sido una tecnología subestimada por muchos desarrolladores de .NET porque es posible que no hayan visto su valor en ese momento (yo no lo vi en el pasado, pero ahora soy un gran admirador de WF porque entiendo lo poderoso que puede be!) pero en la era de la computación distribuida, ahora más que nunca WF realmente puede brillar y espero que finalmente sea portado.

Creo que hay poco espacio para el desacuerdo sobre este tema.

Ciertamente se puede argumentar que la programación visual declarativa como WF no es tan eficiente como escribir código. Incluso tendería a estar de acuerdo. Pero tener WF como una herramienta en el conjunto de herramientas para completar una plataforma configurable sin duda sería algo bueno. Los clientes *_DO *_ quieren ver flujos de trabajo visuales, y capacitar a los clientes para que modifiquen sus propios flujos de trabajo es ciertamente algo bueno.

¡Es hora de hacer esto!

Creo que hay poco espacio para el desacuerdo sobre este tema.

Jaja @MelbourneDeveloper , ¿alguna vez has conocido a un desarrollador de software? ¿O realmente, la raza humana? ;pags

Personalmente, creo que el diseñador visual de WF y las herramientas existentes han hecho un flaco favor a XAML, ya que los archivos demasiado detallados generados para los flujos de trabajo de MSBuild realmente le han dado a Xaml una mala reputación en este sentido. Eso es realmente lo que los desarrolladores asocian con Xaml ("archivos inflados") y han ayudado a generar el vuelo hacia archivos JSON "más simples" y archivos de compilación "con script". Sin mencionar, todo el proceso arcano, difícil y engorroso (todavía ni siquiera puedo hacer que funcione completamente en mis proyectos) de incluso crear un proyecto para ver el archivo Xaml para empezar.

Cuando, de hecho, la forma en que WF funcionó fue la "manera correcta" todo el tiempo. Su verdadera enfermedad estaba en sus herramientas.

Como tal, si la herramienta de diseño fuera un poco más amigable (y tal vez hizo un mejor trabajo al serializar archivos de una manera más organizada/compartamentalizada), esto no sería un problema (o menos).

Soy un gran admirador del camino que buscaba WF, pero debe ajustarse un poco y sus herramientas deben abordarse y mejorarse. Realmente, al final del día, una tecnología es tan buena como sus herramientas de soporte, diseñadores y todo. Cuanto mejores sean las herramientas/diseñadores, más accesible/comprensible cuanto mejor sea la tecnología, mejor será la adopción.

Definitivamente me gustaría ver que WF se parezca más a EF y sea accesible en cualquier escenario de .NET, y que se mejoren las herramientas para facilitar exactamente esto.

Tengo entendido que una de las visiones originales de WF era admitir varios tipos de archivos para flujos de trabajo, no solo XAML. En general, aparte de algunas peculiaridades aquí y allá, realmente no he tenido problemas con XAML. Solo me tomó un tiempo entenderlo y sentirme cómodo editándolo manualmente cuando era necesario, lo que estoy seguro presenta una barrera de entrada para muchas personas. Entonces, aunque creo que XAML debe mantenerse para la compatibilidad con versiones anteriores (al menos a corto plazo), me encantaría ver que otros tipos de archivos de flujo de trabajo comiencen a desarrollarse (como JSON). ¡Pude ver algunas contribuciones geniales de la comunidad en ese frente! (¿Alguien tiene flujos de trabajo escritos en espacios en blanco? :smile: )

@ Michael-DST Estoy completamente de acuerdo contigo. Recientemente, mi equipo y yo estuvimos revisando los gustos, disgustos y deseos de Workflow y casi todo lo que queríamos ver mejorado estaba relacionado con el diseñador y no necesariamente con el núcleo de WF en sí. Creo que Microsoft ha hecho un trabajo fantástico con lo que ha construido en WF y creo que con algunas mejoras y algo de evangelización podríamos ver cómo se le insufla nueva vida. Creo que es una herramienta que NECESITA existir y obtuve mucho valor de WF y quiero que continúe por MUCHO MUCHO tiempo.

Nuestra empresa ha realizado inversiones considerables en WF y ahora es una tecnología fundamental para nuestro negocio. Dado el reciente compromiso de Microsoft con el código abierto y .NET Core, la migración de WF parece el mejor paso a seguir para esta tecnología. ¡Necesitamos esto!

Workflow ha sido una herramienta con muchos beneficios para nosotros como desarrolladores dentro de nuestra organización. Si Microsoft va a unificar sus marcos, nos facilitaría la vida tener WF en el marco central.

Jaja @MelbourneDeveloper , ¿alguna vez has conocido a un desarrollador de software? ¿O realmente, la raza humana? ;pags

Jaja, soy un desarrollador de software. La raza humana es intrascendente para mí.

Michael-DST

Personalmente, creo que el diseñador visual de WF y las herramientas existentes han hecho un flaco favor a XAML, ya que los archivos demasiado detallados generados para los flujos de trabajo de MSBuild realmente le han dado a Xaml una mala reputación en este sentido. Eso es realmente lo que los desarrolladores asocian con Xaml ("archivos inflados") y han ayudado a generar el vuelo a archivos JSON "más simples" y archivos de compilación "con script".

Probablemente tengas razón. Pero, personalmente, creo que hay demasiado énfasis en el Xaml aquí. Cuando probé WF (antes de darme cuenta de que no podíamos usarlo porque no existe en Silverlight), creé una aplicación WPF. Esa aplicación se conectó a nuestros servicios WCF y almacenó el Xaml para WF en una tabla en nuestra base de datos. Así es como logramos la codificación suave de WF.

Sin embargo, el Xaml se manipuló por completo con el uso de la herramienta de diseño WPF WF. El usuario nunca vio el Xaml. El xaml era irrelevante para el usuario. Piense en ello como el marcado HTML detrás de una página web. Podría ser extremadamente complicado, pero mientras al usuario final le guste la página web, en realidad no importa. Creo que si está manipulando el Xaml directamente como texto, de todos modos no está usando WF de la manera prevista ...

La raza humana es intrascendente para mí.

Bonito. B)

Sin embargo, el Xaml se manipuló por completo con el uso de la herramienta de diseño WPF WF. El usuario nunca vio el Xaml.

Correcto. Así es exactamente como funciona MSBuild y los usuarios finales lo odian por el tamaño de los archivos que genera (especialmente cuando los compara con archivos de "script" simples que son muy básicos y lineales). Estoy de acuerdo con usted en que este es un problema de herramientas/diseñador, y también diría que las herramientas/diseñador podrían mejorarse enormemente con WF.

Caso en cuestión: publicaciones de blog y copiar/pegar código (o en realidad, copiar/pegar _workflow_ :smile:). Ha habido varias ocasiones en las que he realizado algunas búsquedas en línea para WF, y me he topado con una buena publicación de blog que mostraba algunos pasos a seguir para instalar un componente de flujo de trabajo (muy probablemente para MSBuild). Bueno, para hacer esto, básicamente tuve que duplicar un montón de pasos. Por lo general, en una publicación de blog de codificación, el código está disponible para copiar y pegar. No es así con WF. Debe hacerlo paso a paso hasta que se vea en su máquina exactamente como se ve en la publicación del blog. Obviamente, esto es muy tedioso y propenso a errores (y se siente totalmente como dar un paso atrás, desde una perspectiva de C#).

El otro problema con el que nos encontramos con MSBuild es el tamaño del archivo, no solo en bytes sino también en el propio diseñador: era realmente difícil navegar por un flujo de trabajo complejo. Esto parece algo que debe tenerse en cuenta de una manera muy completa (e intuitiva).

Finalmente, quiero concluir con el tema del tamaño del archivo. No estoy seguro de si conoce WordML y/o MSFT Frontpage en el pasado. Pero crearía el HTML más inflado del mundo. Aunque los usuarios generalmente no ponen sus manos en el marcado resultante, les gusta poner su nariz en él para tener una idea de cuán "limpio" es. Lo primero que miran es el tamaño en el disco, y luego abren el archivo para ver cómo está formateado, etc.

Nuevamente, estoy de acuerdo en que la forma en que se construyen estos archivos es estrictamente un problema de herramientas/diseñador, pero los desarrolladores sienten curiosidad y esto también debe tenerse en cuenta. :)

Si. Todos los buenos puntos. Creo que sería necesario limpiar el diseñador para que no cree un Xaml tan detallado.

¿Quién tiene realmente el poder de tomar la decisión de si WF se porta a .Net Core o UWP? ¿Es solo el caso de algún desarrollador en algún lugar que escribe el código y luego envía ese parche a los administradores del repositorio de base de código .Net Core? ¿Cuáles son las políticas en torno a esto? ¿No hay un equipo central de desarrolladores influenciados por Microsoft? ¿Son empleados de Microsoft? Todavía no entiendo realmente la configuración completa. ¿A quién tenemos que convencer?

En realidad, @MelbourneDeveloper con solo participar en este hilo, está ayudando a presentar el argumento. Hay un equipo en MS que posee WF, actualmente mío, pero no tomamos la decisión de lanzar WF en Core. Tenemos que hacer el caso de negocios. La discusión aquí me ayuda a hacer eso.

Es realmente impresionante cómo la gente comenzó 2016 apoyando este hilo :)

También el https://github.com/dotnet/corefx/issues/5766 de @terrajobst estuvo mucho más ocupado estos días :)

@dmetzgar Espero que obtenga todos los comentarios que pueda/necesite de esas discusiones para que tenga suficientes casos para OSS.

Estoy bastante seguro de que si se abre un repositorio dotnet/WF o si se agrega a corefx, la gente definitivamente lo hará crecer muy rápido.

En realidad, @MelbourneDeveloper con solo participar en este hilo, está ayudando a presentar el argumento.

Eso me hace sentir cálido y confuso.

Solo para su información, dmetzgar: estoy más que feliz de documentar nuestras experiencias y presentar un caso persuasivo para ayudar a generar evidencia para el caso comercial del puerto.

He estado inmerso hasta las rodillas en la tecnología de Microsoft desde el año 2000. He visto cómo se desarrollaban y desaparecían todas las principales tecnologías relevantes para este hilo. Si bien estoy inmerso en la tecnología de Microsoft, todavía lo veo desde un punto de vista objetivo y creo que WF es una de las tecnologías clave que ayudaría a desarrollar la compra de empresas/gobierno en las plataformas .Net Core y Windows UWP.

¡Nada emociona más a un cliente que los diagramas de flujo! ¡Nada!

También debo decir que la tecnología de Microsoft está en la cúspide de algo grande.

Durante tantos años, he visto el ascenso y la caída de la buena tecnología. La razón principal por la que la tecnología se ha quedado en el camino es por el panorama cambiante de los dispositivos. En el pasado, la estrategia era construir una plataforma para cada familia de dispositivos. No había nada intrínsecamente malo con este enfoque. Pero, significa portar tecnologías entre plataformas. Eso es oneroso, y no es raro que las tecnologías se queden en el camino porque una plataforma de repente se vuelve desagradable (tos, Silverlight).

Microsoft ahora está detrás de .Net Core y UWP. Si bien creo que estas dos plataformas deberían ser la misma, sigo siendo muy optimista de que cuando se crea o se mantiene una tecnología determinada, funcionará en muchas plataformas. Xamarin mejora aún más mi optimismo.

Realmente parece que, por primera vez en la historia, podemos estar mirando a quemarropa a una colección de tecnologías que funcionan en una amplia gama de CPU y entornos operativos. Si Microsoft presiona con fuerza, WF será parte de eso.

Eso me hace sentir cálido y confuso.

:+1: en eso @MelbourneDeveloper y @dmetzgar. Este es el tipo de compromiso y diálogo que personalmente me gusta ver en MSFT, en lugar de las súplicas ignoradas y las llamadas sin respuesta de su base apasionada ( eso es simplemente malo, eso es malo, hombre ).

Un aparte aleatorio aquí: a mi punto de que NodeJS es el único caso comercial/amenaza que necesita, un artículo aleatorio que encontré últimamente .

Finalmente, a mi punto de "si .NET Core es lo suficientemente bueno para EF, debería ser lo suficientemente bueno para WF"... si WF fue a .NET Core, ¿hay alguna forma de integrarlo con EF para que EF sirva? como su backend de alguna manera? Ese es un caso convincente allí mismo, si es así. Si no, vale la pena pensarlo (ver: discusión/diálogo/lluvia de ideas/etc). :)

Finalmente, a mi punto de "si .NET Core es lo suficientemente bueno para EF, debería ser lo suficientemente bueno para WF"... si WF fue a .NET Core, ¿hay alguna forma de integrarlo con EF para que EF sirva? como su backend de alguna manera? Ese es un caso convincente allí mismo, si es así. Si no, vale la pena pensarlo (ver: discusión/diálogo/lluvia de ideas/etc). :)

Ese es un pensamiento interesante. ¿Cuál es su caso de uso para integrar EF y WF? ¿Puede dar un ejemplo? ¿Esto es para la persistencia?

¿Puede dar un ejemplo? ¿Esto es para la persistencia?

Que, como mínimo, podría usarse como modelo de respaldo con el que trabaja el flujo de trabajo en el dominio de la aplicación. A lo sumo, en realidad podría servir como mecanismo de almacenamiento para el flujo de trabajo en sí (pero no lo recomendaría; Xaml es mucho más adecuado para esto).

Puedo ver un paradigma WPF-esque aquí donde puede definir flujos de trabajo en Xaml y luego vincularlos a propiedades de elementos de flujo de trabajo, usando datos de entidades de modelo definidas, modificadas y almacenadas en EF.

Por supuesto, mi experiencia con WF es limitada aquí (aquellos con una amplia experiencia pueden intervenir aquí). Pero, si funcionó para WPF, podría funcionar para WF. De hecho, uso este mismo paradigma (es decir, el desarrollo basado en Xaml similar a WPF) para una aplicación de consola que uso para mi proyecto actual . Por supuesto, no utiliza enlaces de datos como sugiero (todavía), pero se producen fácilmente, como nos ha demostrado OmniXaml/Perspex. :Gafas de sol:

@ Michael-DST Preferiría evitar demasiadas integraciones. WF debe ser un paquete NuGet independiente. Integrar WF y EF juntos debería ser un proyecto separado. Comience a combinar demasiadas cosas y podría terminar con Oslo .

Estoy de acuerdo con @dmetzgar :+1:

EF es un proveedor de almacenamiento/persistencia. Debe ser un paquete NuGet diff e inyectado en tiempo de ejecución. WF solo debe proporcionar un conjunto de interfaces y eso es todo.

Lo hicimos bastante bien con los proveedores de almacenamiento en Microsoft Orleans.

@dmetzgar (y @galvesribeiro) estuvieron de acuerdo. No estoy sugiriendo una integración requerida, sino un posible caso de uso/propuesta de valor. (Ver: lluvia de ideas. :sonrisa:)

¿Cuál es su caso de uso para integrar EF y WF? ¿Puede dar un ejemplo? ¿Esto es para la persistencia?

¡Quiero participar en esto! Una vez más, esto se relaciona con la experiencia de mi empresa. En última instancia, nos gustaría usar EF para la persistencia de datos en bases de datos en línea como SQLite para aplicaciones conectadas ocasionalmente. En última instancia, UWP/.Net Core tendría EF, SQLite, Azure Mobile Services y WF trabajando en armonía. Me estaría repitiendo si explicara por qué queremos que esto suceda, pero puedo explicar por qué EF y WF funcionan bien juntos. Aunque, hemos encontrado una limitación en EF que nos detuvo en seco en el pasado, y es la otra razón por la que tuvimos que crear nuestro propio ORM.

Tenemos un sistema en el que el acceso a los datos activa eventos como "BeforeLoad", "BeforeSave", etc. Dejamos ganchos en estos eventos para que cuando se guarde un tipo de registro dado, podamos poner una lógica comercial personalizada allí. Actualmente, lo hemos hecho mediante la vinculación a DLL de lógica empresarial personalizada. Cada cliente tiene su propio conjunto de eventos personalizados. También implementamos llamadas a WF. Entonces, por ejemplo, en el evento BeforeSave, podríamos validar allí haciendo una llamada a WF que valida los campos obligatorios. De esta forma, la lógica de validación fue codificada en software para un cliente determinado. A la larga, tuvimos que abandonar WF para este propósito porque nunca se implementó en Silverlight, pero hubiera sido bueno tenerlo allí como una opción.

De todos modos, siento que este es un requisito bastante universal para cualquier aplicación. En términos generales, siempre querrá una capa justo encima de la capa de datos que valide los datos que ingresan a la base de datos o que haga una lógica comercial general. Por ejemplo, tenemos una lógica comercial para algunos clientes que envían correos electrónicos cuando se agrega un registro de un tipo particular a la base de datos. Esto podría hacerse en WF. Sería genial implementar algo como esto con EF y WF trabajando en armonía.

Por desgracia, nunca encontré una manera de hacer esto con EF, incluso en .Net. El problema que encontré fue que EF no le dice cuándo se va a guardar un registro de un tipo determinado. Entonces, por ejemplo, si crea un nuevo objeto "Tarea" y lo conserva en la base de datos con EF, no hay ningún evento activado por EF que tenga algo como "RecordInserted". Esto nos permitiría crear enlaces en el acceso a los datos para que se pudieran insertar negocios personalizados. Por lo tanto, esta es una de las razones por las que nunca elegimos EF. Es una pena porque la construcción de nuestro propio ORM tomó años para refinar.

Hablando del "caso de negocios" de NodeJS: Cómo NodeJS está dominando .NET en 3 Easy Charts

Esperando pacientemente ese repositorio de GitHub. Recién me di cuenta de que WF no había sido portado a .NET Core, lo que prácticamente eliminó su viabilidad para nuestro producto. Lo cual es una pena, ya que nos encantan los cambios que llegan al núcleo de ASP.NET y toda la idea modular, simplificada y multiplataforma de .NET Core, pero necesitamos WF, ya que es la base de todo nuestro producto.

Supongo que, sinceramente, no me importa si se trata de WWF o si se trata de algún otro motor de flujo de trabajo bien soportado, pero sí creo que para fines de extensibilidad, el flujo de trabajo de algún tipo podría ser absolutamente enorme.

+1

Usamos generación dinámica (basada en reglas externas importadas) y carga de flujos de trabajo como servicios WCF. ¡Sería genial si pudiéramos usar ese modelo en .net core!
Por cierto, ¿cuál es el problema de importar ensamblajes de .Net completo? si se trata principalmente de código IL, ¿por qué no se ejecuta en .net core?

+1

@dmetzgar ¡Es increíblemente emocionante ver https://github.com/dmetzgar/corewf! Desde el archivo Léame, me sorprendió ver que un puerto del equipo de WF no ganó mucha tracción. Especialmente dado el puerto de Powershell reciente que tiene el flujo de trabajo de Powershell que se limitará al marco completo: Linux y Mac obviamente no son un objetivo importante, pero me imagino que el servidor Nano será muy importante para Powershell. También se menciona allí que está explorando alternativas a XAML. ¿Eso incluye otras implementaciones de Xaml como Portable.Xaml, por ejemplo, ya es compatible con el perfil 259 compatible con CoreCLR?

@watertree Portable.Xaml y otras implementaciones XAML compatibles con .NET Core que he visto hasta ahora tienen una función que falta. No implementan el atributo x:Class="". Es innecesario para WPF pero fundamental para WF. Un flujo de trabajo XAML normalmente tiene

PowerShell Workflow tiene una forma realmente agradable de definir flujos de trabajo en script. Es mucho más limpio que escribir lo mismo en XAML o C#. Sin embargo, PSWF convierte ese script en un archivo XAML en segundo plano. Para que PSWF funcione en Nano, tendrían que reemplazar su canalización existente y el tiempo de ejecución de WF para que no use XAML. Y realmente no hay suficiente presión por parte de los clientes para tener PSWF en Nano.

En cuanto a las alternativas a XAML, tengo muchas opiniones al respecto. Mi problema con XAML es que está incrustado en WF. Con el antiguo WF lanzado en .NET 3.5, el equipo de WF lo animó más a convertir cualquier formato que quisiera en un flujo de trabajo. Utilizaron el ejemplo de convertir diagramas de Visio en flujos de trabajo. Pero cuando llegó el nuevo WF en 4.0, todo se centró en XAML. ¿Alguna vez ha intentado escribir un flujo de trabajo en XAML a mano? No esta pasando. Luego están los símbolos de depuración y el estado de vista. E intente comparar una versión de un XAML con otra con una herramienta de diferenciación.

Realmente creo que usar XAML para definir flujos de trabajo debería ser una cuestión de incluir un paquete NuGet. Se debe fomentar la creación de otros medios para almacenar definiciones de flujo de trabajo. Tal vez necesites algo que se comprima bien. Tal vez necesite seguridad y solo permita un conjunto limitado de actividades. Prefiero tener opciones.

No implementan el atributo x:Class=""

De hecho, Xaml compilado (¿baml?) Ha estado notoriamente ausente en todos los sabores de Xaml que he visto. He pensado en sumergirme en esto con mi tiempo libre, pero tengo la sensación de que pronto estará disponible de alguna manera, tal vez el próximo año. Además, el sistema Xaml de Xamarin admite esto, pero está cerrado y no es extensible/accesible en absoluto.

¿Alguna vez ha intentado escribir un flujo de trabajo en XAML a mano? No esta pasando.

Verdadero. Irónicamente, WF es el benefactor más completo (por mucho) de cualquier integración de Xaml. A una falla, tal vez. Es una pena que Xaml se haya creado para ser extremadamente amigable con el diseñador, pero las herramientas en torno a WF son un poco prohibitivas para escenarios escritos a mano, e incluso para el propio diseñador. Parece que realmente intentaron convertirlo en un lenguaje de programación visual, pero sin la cantidad significativa de soporte/recursos que necesitaría para tener éxito.

Realmente creo que usar XAML para definir flujos de trabajo debería ser una cuestión de incluir un paquete NuGet.

¡Me gusta como piensas! 👍

Por cierto, si aún no lo ha hecho, vaya a la solicitud/problema del puerto System.Xaml y vote a favor del problema si puede. Por mi parte, realmente me gustaría ver un nuevo sistema Xaml multiplataforma de código abierto que tome lo mejor de todos los sistemas conocidos y lo proporcione como un sabor oficial y autorizado. ¿No sería eso bueno? 😛

De todos modos, son hasta 74 votos ahora. Lo cual es bastante genial teniendo en cuenta que la votación comenzó antes de que estuvieran disponibles las reacciones de GitHub:
https://github.com/dotnet/corefx/issues/5766

17 corazones también son geniales. :)

¡Gracias por cualquier apoyo (y comentarios continuos)!

@dmetzgar ¡ Gracias por sus esfuerzos! Solo comente sobre XAML: solía tener una visión muy negativa de XAML porque la mayoría de los archivos con los que traté se crearon con dialectos de XAML de diseñador visual.

Todo eso cambió cuando comencé a programar con Xamarin.Forms, que tiene una API de C# declarativa muy agradable además de XAML. No hay diseñador visual (solo una vista previa que llegó mucho más tarde que el lanzamiento de XF). Sorprendentemente, ¡prefiero trabajar en su dialecto de XAML que en el código C#! Hicieron un gran trabajo al respecto, y no tienes una tonelada de metadatos de diseñador que contaminan el significado del marcado. Los marcos de trabajo compatibles como Prism.Forms también ayudan a inclinar la balanza drásticamente hacia XAML, ya que ayuda a escribir código sin código subyacente muy fácilmente.

Por lo tanto, no creo que XAML per se sea el problema, pero los dialectos diseñados para admitir primero a los diseñadores: XF es una prueba bastante convincente para mí.

¿Alguna actualización sobre ese tema?

Bueno, CoreWF está vivo y existe en https://github.com/dmetzgar/corewf

Debe verse si DynamicActivity ahora se puede portar con las nuevas API de composición agregadas al núcleo y el estándar .NET 2.0.

Sería genial si tuviéramos noticias del equipo de WF.

Se han hecho muchos comentarios interesantes y útiles sobre este tema. Por mi parte, creo que hay valor en solo el tiempo de ejecución de WF y el seguimiento de eventos (es decir, sin bits de XAML, transacciones o WCF) que se transfieran a .NET Core y me alegro de que esto se haya hecho (más o menos).

Acepto que WF.Core debe existir oficialmente. Si existiera la posibilidad de crear una forma más flexible de definir los flujos de trabajo que funcionan para los desarrolladores, creo que sería el mejor enfoque. Estoy de acuerdo en que XAML es un hueso duro de roer si MS dice que no van a portar System.XAML, pero realmente quiero ver WF.Core en mis proyectos de API web de .NET Core.

Creo que el enorme elefante en la sala aquí es que no hay suficiente tracción para hacer despegar este proyecto porque MS y otros han sido muy discretos sobre cualquier información sobre WF. Seguro que hay algunos ejemplos en MSDN, pero hay muy poca información disponible en forma de libros u otros materiales sólidos (examinados).

Definitivamente estoy dispuesto a dedicar tiempo para ayudar a que esto cobre vida.

Entonces, OmniXAMLv2 (está en una rama en el repositorio de github), que aún está en desarrollo, debería ser compatible con los atributos x:Class (https://github.com/SuperJMN/OmniXAML/issues/12). ¿Tal vez podamos usarlo para (Core) WF?

@ewinton ¡ Gracias por señalarlo!
Eso es definitivamente una gran parte de eso. Además, .NET Standard 2.0 tiene un montón de tipos System.ComponentModel utilizados por WF. System.Transactions ya está en corefx. Lo único que falta es WCF ServiceHost.

WCF ServiceHost puede esperar en mi humilde opinión. El modelo de alojamiento debe ser agnóstico como cualquier otra cosa en el mundo .Net Core/Asp.Net, creo...

@galvesribeiro Estoy de acuerdo con esto, dado que hay muchas otras formas en que WF puede funcionar en un mundo .NET Core, incluida la API web.

Sip. Sin embargo, estoy de acuerdo con @dmetzgar en que hay un montón de clientes que hoy en día usan WCF, por lo que tenerlo compatible es imprescindible, pero nuevamente, puede retrasarse...

De hecho, el alojamiento y el "lenguaje de diseño" deben abstraerse del tiempo de ejecución principal...

Usamos WCF con WF, pero con gusto cambiaríamos a algo como WebAPI si WF estuviera en Core. De hecho, seguimos adelante y nos mudamos de WCF a una alternativa RESTful a pesar de todo. ¡Obtenemos una TONELADA de valor de Workflow y es una de mis tecnologías .NET favoritas!

También creo que WF en el núcleo no debería tener que depender de xaml o wcf, solo tener el motor wf y el modelo de objetos sería muy valioso. Luego, ejecutaría eso como un middleware en el núcleo de asp.net, especialmente con el nuevo trabajo de canalización/no http que está llegando a Kestrel.

+1 por tener y admitir el motor WF y el modelo de objetos en Core. También podemos solucionar XAML y WCF.

XAML es genial: le permite realizar una configuración dinámica; en un proyecto, cargamos flujos de trabajo xaml desde archivos y se representan como puntos finales de WCF. Y estos archivos XAML se generan automáticamente a partir del registro de servicios disponibles. Entonces, los servicios wcf obtienen puntos finales:
https://[base]/wcf/[servicio_id1]
https://[base]/wcf/[servicio_id2] ...
Sería bueno tener esa funcionalidad en .Net core :)
Oh... lo he escrito aquí antes... :)))

Sí, como me he vuelto más familiar con la tierra aquí, el soporte de Xaml en WF no es tan importante en sí mismo, sino que realmente se está transfiriendo System.Xaml, esa es la parte importante. Dado que eso está claramente capturado en otro problema, y ​​me complace decir que es bastante popular (¡pero no dejes que eso te impida votar, @freerider7777! :smile:) -- problema, estoy a favor de hacer de WF una dependencia libre como sea posible para garantizar que llegue a .NET Core. 👍

@ Mike-EEE ¡He votado allí hace mucho tiempo! :)

Al ver que los flujos de trabajo se pueden crear a través del código, ¿el uso de una API fluida similar a EF Core sería una opción válida para dar vida a WF Core? Entonces, ¿la serialización/deserialización para el tiempo de ejecución podría construirse después y ser mucho más fácil de implementar?

FluentAPIs... tan caliente en este momento. O al menos, desde que fueron creados. 😄

FluentAPIs, Builder Pattern, ambos son esencialmente iguales. Proporcionar una forma basada en código que sea encadenable y fácil de usar, creo que debería ser un principio sólido detrás de esto.

Sin un diseñador todo es inútil. Por supuesto, podemos codificar todo nosotros mismos: toda la lógica, todas las cadenas, etc. (con fluidez o sin ella). Pero lo que es genial en WF: puede ver visualmente el flujo de procesamiento. ¡Es el vínculo entre los gerentes (y otras 'partes interesadas') y los desarrolladores! Los gerentes no entienden el código, pero estos diagramas de alto nivel son comprensibles para todos. Con WF, no necesita diagramas separados (visio u otros) si están separados; por lo general, no están sincronizados con el código real :)

@freerider7777 La serialización de definiciones de WF no se limita a xaml (consulte https://github.com/dmetzgar/corewf de @dmetzgar ). También podría implementarse para JSON... y esto abriría la posibilidad de integrar/bifurcar proyectos existentes como NodeRed http://nodered.org/ , que en muchos sentidos se asemeja a las funciones y UX de WF Designer (+ también se ejecutaría en un navegador web, abriendo nuevos casos de uso para WF)

Creo que es mejor migrar WF a .NET Standard y no solo a .NET Core. El tiempo de ejecución de WF vinculado anteriormente ya funciona en .NET Standard 1.3 (podemos bajar si eliminamos la actividad WriteLine). Con el lanzamiento del estándar 2.0 pronto, tendremos la capacidad de llenar una gran cantidad de vacíos de funciones, como metadatos de caché automáticos, DynamicActivity y alcances de transacciones. Deberíamos separar los componentes en diferentes paquetes para que haya un modelo de pago por juego: si solo quiere tiempo de ejecución, puede seguir con el estándar 1.3, pero si quiere DynamicActivity necesitará el estándar 2.0 y limita sus plataformas.

Definitivamente hay mucho margen de mejora en el código de tiempo de ejecución de WF. Por ejemplo, reemplazaría las extensiones de actividad con inyección de dependencia. Fluent API sería interesante para escribir flujos de trabajo en código (y, en ese sentido, mire https://github.com/knat/Metah by @knat) pero estoy de acuerdo con @freerider7777 en que la capacidad de comunicarse con su administración y BAs usando diagramas generado a partir de lo que realmente se usa en la producción es una gran ventaja. @helmsb tiene mucha experiencia con esto (consulte http://dotnetrocks.com/?show=1236).

Un nuevo diseñador tendría que ser una aplicación web. Dirigirse a WPF o UWP limitaría la audiencia. Si OmniXAML funciona, las personas pueden crear/editar flujos de trabajo con las mismas herramientas que usan hoy (VS o solución rehospedada). El problema es que, dado que el diseñador actual está integrado en .NET Framework, cualquier característica o corrección tendría que esperar a que se publique .NET Framework. Es lo suficientemente bueno para empezar, pero no es una solución a largo plazo. @erikcai8 hizo algunos experimentos con un diseñador web, similar a nodered. Veré si puedo convencerlo de compartir.

Para el front-end del diseñador de flujo de trabajo, hay un primer intento disponible en github: https://github.com/gary-b/WF4JSDesigner y puede usarlo en vivo http://gary-b.github.io/WF4JSDesigner/

Esto es lo que ya se ve:

@ewinton : Genial ver el POC del diseñador de flujo de trabajo web. También he construido otro como se muestra a continuación.

¡¡¡AWWWWW SNAP!!! ¡¡¡ES UN POC-OFF DE WF!!! 🎉

Je je. Oye , @erikcai8 , ¿dónde está Exportar a Xaml? Jaja. Solo volteándote el dolor. más o menos 👼

Ambos esfuerzos se ven muy bien. Es bueno verlos a los dos. Esto parece bastante obvio ahora, pero ¿qué tan increíble hubiera sido tener un diseñador visual basado en la web en el WF original? Todo está bloqueado y cargado, listo para usar, solo visita una URL. Creo que eso realmente habría ayudado con la marca y la adopción. Lamentablemente, todo el mundo parece haber aterrizado en el editor basado en TFS, que fue muy difícil de configurar y condujo a un Xaml muy detallado. Esta fue una mala experiencia para el desarrollador típico que tenía que lidiar con eso y le dio una mala reputación a cualquier cosa que tuviera que ver con la experiencia (WF o Xaml).

Esto, OTOH, parece un gran enfoque. ¡Que comience el renacimiento!

@ Mike-EEE Mi experimento E2E mejoró Workflow Core Engine para cargar el flujo de trabajo JSON de forma nativa para que no se requiera el formato XAML. Sin embargo, el flujo de trabajo XAML podría exportarse desde Workflow Engine una vez que cargara el flujo de trabajo JSON.

Ese es el punto. No deberíamos vincular el tiempo de ejecución y su modelo de objeto al diseñador y el formato serializado de la forma en que estaba en WF 4.5...

@galvesribeiro Entendí el punto. Sin embargo, el experimento asumió que el formato JSON era compatible como otra opción para Workflow Core. Como se discutió anteriormente, XAML aún no es compatible con las tecnologías web más recientes.

Nos encanta WF, transpórtelo a .NetCore.

Necesitamos un diseñador de flujo de trabajo basado en web. La compatibilidad con .NET Core, para ejecutar los flujos de trabajo, sería doblemente increíble. ve ve

Daniel Gerlag está trabajando aquí en un motor de flujo de trabajo compatible con el núcleo, liviano y realmente bueno:

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

Daniel's ha recorrido un largo camino en muy poco tiempo. Le recomiendo encarecidamente que lo mire y participe en este proyecto si encuentra mérito en él.

Con todo este interés, ¿por qué no construir un motor compatible con Net Core desde cero?

@ccpony Porque puedes usar CoreWF en dot net core ahora mismo -> https://github.com/dmetzgar/corewf . Los componentes centrales están portados y funcionan. Algunas cosas están a la espera de .net estándar 2.0.

@ewinton Gracias por responder, pero no entiendo esto. WF no fue un producto exitoso de MS y MS no ha hecho nada para mejorarlo durante años. La comunidad está repleta de testimonios de implementaciones probadas y fallidas. No ha sido ampliamente adoptado en la empresa. Es difícil de manejar, tiene demasiadas funciones, es difícil de aprender y (todavía) tiene errores. Su interfaz es ampliamente difamada. No logró convertirse en una tecnología amigable para el usuario final. Sus componentes internos son esencialmente una caja negra que no se puede mejorar fácilmente. Es LENTO con cualquier cosa que no sean flujos de trabajo simples. Es muy difícil de probar. Se basa en tecnologías antiguas (WCF, XAML). Desde que Ron Jacobs se enfermó, WF languideció y no tiene ningún amigo en MS.

En mi opinión, WF intentó ser todo para todos y, de hecho, resultó ser poco para cualquiera. Microsoft casi lo ha dejado caer. ¿Por qué querríamos resucitar algo así? Si alguna tecnología importante requería un replanteamiento y una reescritura, ES ESTO.

Mira el proyecto incipiente de Daniel Gerlag. Es nuevo e inmaduro. Pero requiere un enfoque moderno del flujo de trabajo que sería fácil de mejorar. Si todos aquí dejaran de tratar de modernizar un proyecto complejo, anticuado y, francamente, sobrediseñado y, en cambio, pusieran sus esfuerzos en algo nuevo y mejor, entonces tendríamos una oportunidad de terminar en un lugar que vale la pena: construir gradualmente un motor de flujo de trabajo de clase mundial en lugar de intentar reescribir un gigante desde el principio. Honestamente, admiro a todos aquí que quieren participar en un esfuerzo MUY valioso: crear, FINALMENTE, una herramienta de flujo de trabajo multiplataforma (¿máquina de estado?) bien diseñada, funcional, liviana, fácil de aprender. Pero, lamento decirlo, si todos continúan siguiendo este camino, entonces todos sus esfuerzos simplemente se desvanecerán en nada. MHO.

@ccpony Gracias por compartir tu opinión. ¿Te importaría explicar a qué errores te refieres? Si hay algo que podamos hacer para solucionar problemas en .NET Framework, me encantaría saberlo.

@dmetzgar Gracias por responder, Dustin. Durante el período de tiempo que estaba tratando de desarrollar aplicaciones WF, encontré errores. No solo comportamientos inesperados, sino que en varias ocasiones un WF complejo "estalló" y generó errores en la interfaz de usuario de XAML que eran difíciles de corregir en el código XAML. Realmente nunca desarrollé una gran confianza en la tecnología WF. Realmente, llegué al punto en que sentí que estaba luchando contra un gorila de 800 libras: por cada paso hacia adelante, terminaría retrocediendo dos pasos.

Sé que eso no es lo que está buscando en su amable solicitud de que explique los errores. Francamente, podría evitar esos errores. Pero eventualmente abandoné WF por todas las otras razones a las que me referí en mi publicación anterior.

Estás encabezando este esfuerzo y te felicito por ello. Pero seguramente llega un punto en el que tratar de adaptar una tecnología compleja se vuelve contraproducente. Siguiendo todo este hilo, simplemente no puedo evitar sentir que el progreso es muy lento, si es que lo hace, y eventualmente no se verá nada de todo esto. Me parece muy poco probable que los flujos de trabajo antiguos sean transferibles a lo que sea que se produzca aquí. Las personas en este hilo hablan sobre el flujo de trabajo basado en el cliente (es decir, JavaScript), compatibilidad con REST, reducción de dependencias, multiplataforma, etc. Por ejemplo, XAML es una parte tan importante de la antigua tecnología WF, ¿de qué sirve trasladar WF al núcleo? ¿XAML no será parte de esto?

Entonces, Dustin, necesito preguntarte esto: aquí estamos 18 meses en este proyecto y simplemente no parece haber consenso de que se está logrando un progreso real. Respeto tus esfuerzos y puedo ver que eres un gran programador, pero esta es mi pregunta: ¿no tendría MUCHO más sentido reunir toda esta energía y entusiasmo y crear algo nuevo?

@ccpony La discusión en este tema es para admitir WF .Net Standard y no al revés.

Solo curiosidad... ¿Alguna vez ha usado o visto una implementación de Sharepoint en acción? Si lo haces, verás que está muy basado en WF. ¿Ha visto alguna vez una implementación de BizTalk? Lo mismo.

Esos son los principales productos de MSFT en el mundo empresarial, así que sí, hay usuarios que se preocupan por WF y hay uso para él. No es un proyecto abandonado/abandonado como dijiste.

Dicho esto, si observa el repositorio de @dmetzgar , verá que algunas cosas son similares o heredan algunos comportamientos de la antigua encarnación de WF, también verá que fue rediseñado para ser liviano. El persistente es desacoplado y la gente puede crear fácilmente otros nuevos. El diseñador está desacoplado y la gente ya creó varias pruebas.

Entiendo tu frustración por querer algo nuevo. Créeme, yo también quiero que eso suceda. Pero hay que entender a @dmetzgar y su equipo. Esto no es una prioridad, ya que el 95 % de los clientes son usuarios de la antigua WF, que básicamente funciona en BizTalk y Sharepoint, como mencioné. Usé el antiguo WF durante años en un entorno de tps muy alto (transacciones bancarias y financieras) y me sirvió muy bien.

Mi nueva tecnología funciona con .Net Core, y la única razón por la que no la uso de nuevo en este momento es porque aún no la tenemos para .Net Core.

Lo que ya le sugerí a @dmetzgar es llevar el repositorio de WF a .Net Foundation, definir hitos, colocar el código allí y agregar tareas como Problemas y etiquetarlo como up-for-grabs para que la comunidad comience a hacerlo. Sin embargo, eso todavía requiere algo de tiempo de su equipo para hacer este trabajo y posiblemente no tengan ese tiempo disponible (todavía).

@galvesribeiro entiendo tu punto. Sí, he escrito implementaciones de SharePoint. Y HE visto implementaciones de BizTalk en acción ( * obturador *). Entiendo la relación entre SharePoint y WF. (No sé a qué se refiere cuando sugiere que BizTalk de alguna manera se basa en WF. No lo hace).

Pero tengo que discrepar contigo en un punto importante: WF ES un proyecto abandonado/abandonado. Realmente entiendo la preocupación de los desarrolladores de SharePoint en este momento. No hay razón para creer que MS mejorará las capacidades de WF en SharePoint. No entiendo por qué cree que los esfuerzos de @dmetzgar tendrán algo que ver con el futuro de SharePoint (o BizTalk). No es como si MS adaptara SharePoint con el código de @dmetzgar . Lo siento, pero el futuro de SharePoint no tiene nada que ver con los esfuerzos que se están haciendo aquí.

Entonces, lo que realmente importa es si de todo esto saldrá un buen motor de flujo de trabajo. Y es mi argumento que tratar de forzar a un gigante como WF en el futuro no es el mejor curso de acción. Es mejor construir desde cero.

@ccpony Me gustaría recordarles que hay muchas personas aquí que están buscando activamente que este proyecto cobre vida, y algunas de hecho están dedicando tiempo a hacerlo realidad. Si bien usted personalmente puede ver a WF como un producto fallido de Microsoft, continúa siendo parte de .NET y lo usamos más que nosotros aquí.

Este hilo debe ser para críticas constructivas y aportes para hacer realidad la transición y no para criticar a otros o al producto en sí. Si bien se respetan sus puntos de vista, tenga en cuenta que son suyos y que otros pueden pensar de manera diferente con respecto a la importancia de WF para ellos.

Damos la bienvenida activamente a sus comentarios sobre las formas de mejorar el producto y la mejor manera de ayudar a aquellos que participan activamente en el intento.

Gracias =^_^=

@ccpony

(No sé a qué se refiere cuando sugiere que BizTalk de alguna manera se basa en WF. No lo hace).

Perdón, me expresé mal (estoy en el móvil). Tenía una aplicación que usaba ambos juntos y conozco muchas otras que también lo hacen.

No hay razón para creer que MS mejorará las capacidades de WF en SharePoint.

No estoy diciendo que lo hará. Estoy diciendo que el equipo que trabaja con WF Today está totalmente enfocado en admitir implementaciones de Sharepoint. Incluso la última versión de Sharepoint está utilizando la misma versión actual de WF.

No entiendo por qué cree que los esfuerzos de @dmetzgar tendrán algo que ver con el futuro de SharePoint (o BizTalk).

No estoy diciendo que afectará el futuro de Sharepoint. Estoy diciendo que el equipo está ocupado apoyando a Sharepoint si entendí correctamente. ( @dmetzgar puede corregirme si me equivoco)

No es como si MS adaptara SharePoint con el código de @dmetzgar . Lo siento, pero el futuro de SharePoint no tiene nada que ver con los esfuerzos que se están haciendo aquí.

Si MS usará o no WF vNext en Sharepoint vNext, solo ellos pueden asegurarlo. Nuevamente, el problema es que el equipo de WF no puede lidiar con ambos.

Entonces, lo que realmente importa es si de todo esto saldrá un buen motor de flujo de trabajo. Y es mi argumento que tratar de forzar a un gigante como WF en el futuro no es el mejor curso de acción. Es mejor construir desde cero.

Nadie lo está portando como es. El repositorio de @dmetzgar es una prueba de que se está rediseñando desde cero. Nuevamente, el problema es la acumulación y el ancho de banda que el equipo tiene para lidiar con ambas cosas. Es por eso que sugerí "abrirlo" en la fundación dotnet y convertirlo en un gran esfuerzo impulsado por la comunidad con la orientación y la curación del equipo de WF para que intentemos afectar lo menos posible sus horarios.

Una vez más, como mencionamos @InariTheFox y yo mismo, este hilo es un impulso para el puerto, lo que no necesariamente significa forzar el empuje de la antigua fersion con todas estas características a la nueva versión. Sin embargo, es importante entender que las personas ponen mucho esfuerzo (y dinero) en sus productos actuales basados ​​en WF, por lo que @dmetzgar se preocupa por la mayor compatibilidad posible con los flujos de trabajo anteriores, es algo que hay que cuidar.

Está bien. Veo las pasiones aquí. En realidad, si hubiera un buen reemplazo de WF que abordara todos los problemas que mencioné antes, no estaríamos teniendo esta conversación. Para que conste, muchos de nosotros nos hemos alejado de WF y hemos esperado en vano a que llegara lo siguiente. Nunca lo hizo. Que yo sepa, NO existe una solución de flujo de trabajo/máquina de estado actual, compatible, funcional y basada en .Net que sea ampliamente reconocida. Por favor, comprenda: mantengo mi afirmación de que WF es una tecnología muerta desde la perspectiva de Microsoft.

Pero, habiendo dicho eso, por favor ayúdame a entender. ¿El repositorio de @dmetzgar funciona tal cual? ¿Cómo se escriben flujos de trabajo con él? No veo ningún código de ejemplo y no hay ninguna documentación. ¿Cómo procedería?

Creo que hay muchos productos/empresas que hicieron de WF el centro de su estrategia de producto, no es solo una dependencia de Sharepoint en modo de soporte: en mi empresa actual desarrollamos una plataforma de automatización con WF como tecnología central (y sé otros 2 competidores de este mercado que también utilizan WF en sus productos); también lo he discutido con personas que lo usan en insurtech... así que creo firmemente que la audiencia de WF todavía está allí.

Dicho esto, .net core parece ser una de las áreas de enfoque de Microsoft y mucha innovación tecnológica se incorporará en el próximo período; Creo que sería una gran pérdida no tener a WF como parte de esto.

Desde mi perspectiva, el camino correcto para que esto suceda es hacer que el núcleo de WF sea independiente de xaml y facilitar la (des) serialización de los flujos de trabajo también en otros formatos (por ejemplo, json). Esto también simplificaría la implementación de escenarios como diseñadores de flujo de trabajo alojados en navegadores web. Y con el repositorio https://github.com/dmetzgar/corewf tenemos un punto de partida.

Para aquellos interesados ​​en una descripción general sobre el estado actual de WF (que no veo como abandonado por MS), hace un tiempo centralicé la información disponible sobre WF en una publicación y una presentación http://andreioros.com/blog /windows-workflow-foundation-rehosted-diseñador/ ; Todavía lo estoy manteniendo actualizado

Nosotros y nuestros clientes confiamos en WF y nos encantaría verlo funcionar tanto en el cliente como en el servidor. Un WF libre de XAML y otras dependencias, diseñado para ser liviano pero con la expresividad del WF existente que también es compatible con la comunidad con MS, sería un producto emocionante y valioso.

Una vez más, permítanme preguntar: ¿qué se hace con el puerto de @dmetzgar para ejecutarlo? ¿Cuál es el estado actual?

No sabía que el puerto de @dmetzgar era realmente utilizable en su encarnación actual...

De @ewinton , arriba:

"Porque puede usar CoreWF en dot net core ahora mismo -> https://github.com/dmetzgar/corewf . Los componentes centrales están portados y funcionan. Algunas cosas están esperando el estándar .net 2.0".

En cuyo caso a mí también me gustaría saber de su uso...

Sí, es la base de la funcionalidad principal. Puede ejecutar flujos de trabajo basados ​​en código. Las características que faltan de netstandard2.0 están relacionadas principalmente con el soporte de transacciones.

Esa es más una de las razones por las que sigo sugiriendo abrirlo y hacer que la gente contribuya a un lugar central. Difundirlo hará que las cosas sean aún más difíciles de alcanzar en un producto final algún día en el futuro.

Vote a favor de la reescritura de WF con pruebas y compatibilidad con las características modernas de Roslyn como parte de Core. Me encantaría ver cómo la arquitectura sin servidor y los contenedores podrían afectar la arquitectura, especialmente la implementación y escalado de conjuntos de reglas dentro de distintos contextos de dominio y procesos comerciales. Personalmente prefiero un DSL sucinto sobre un diseñador WYSIWYG. Personalmente, amaba al diseñador, pero se sentía peculiar casi todo el tiempo. WF en sí tenía potencial para ser extremadamente sólido, pero requería una gran experiencia. De hecho, una gran implementación de WF que incluía WF Manager y flujos persistentes en SQL Server requería consultoría de MS y corrección de errores. Aunque ahora apoyo a los equipos de Java en los últimos años, me gusta estar atento a .NET después de poco más de 15 años de centrarme principalmente en la tecnología de MS. Estaba leyendo "Generación de código con Roslyn" de Nick Harrison (no tengo vínculos con él ni con el libro) y me preguntaba si volvería a abordar el espacio del motor de reglas comerciales, lo que me llevó a preguntarme sobre el destino de WF una vez más... con toda honestidad, creo que Azure Functions compite tanto con los recursos de MS como con su voluntad corporativa general de respaldar inversiones profundas en WF en cualquier lugar. Parece obvio que querrían que lo use... así que, quizás la solución sea centrarse en una versión .NET de código abierto de OpenWhisk. Pero, en un mundo en contenedores,... solo puedo usar OpenWhisk como un servicio. Entonces...

PS simplemente apoyando un método robusto de importación de expresiones externalizadas podría resolver el 60% de los requisitos de la aplicación que piensan que podrían querer WF. ¿Fue CSharpScript? Una forma sencilla de importar configuraciones básicas de reglas comerciales con una API directa sería muy útil (varias opciones de persistencia, recuperación y almacenamiento en caché). Con una infraestructura virtual desechable (automatización sobre infraestructura, contenedor y plataforma como servicio), WF vNext podría centrarse en implementar cambios de versión como un servicio en lugar de intentar incorporarlos en aplicaciones (es decir, una mejor solución para WF en WCF)

Estoy muy interesado en esta conversación. Mi equipo también ha estado lidiando con la frustración de XAML. Nuestro dilema es que estamos creando nuestro propio diseñador de interfaz de usuario para permitir que nuestros clientes creen sus propios flujos de trabajo sin necesidad de Visual Studio o el diseñador reubicado. Necesitamos la capacidad de guardar fragmentos de XAML en bits reutilizables para que el cliente no siempre tenga que volver a escribir esos bits (piense en ellos como funciones de flujo de trabajo). Esto requiere que sepamos cómo fusionar fragmentos de XAML, lo que hemos aprendido es extremadamente frustrante. Lo que estamos pensando hacer es crear una abstracción en la que simplemente confiemos en un modelo de base de datos de nuestras diversas actividades y sus vínculos e ignoremos XAML por completo. Luego crearemos las actividades, etc. programáticamente cada vez que se ejecute un flujo de trabajo. Mientras investigaba este enfoque, me topé con este hilo. Sigan con la conversación, estoy muy interesado en escuchar las opiniones de los demás.

@erikcai8 El diseñador de flujo de trabajo es una idea muy buena. ¿Puedo obtener la fuente de su diseñador de flujo de trabajo?

He estado usando WF durante más de 5 años en mis proyectos de automatización y fue maravilloso. Espero que muchos desarrolladores apoyen esta solicitud y la hagan realidad. Siempre he usado la tecnología .Net desde que comencé a trabajar y me gustaría continuar haciéndolo. Sin embargo, ser compatible con varias plataformas es la dirección de la empresa, por lo que estoy ansioso por ver WF completo en .Net Core.

Con la llegada del estándar de red 2.0, sería genial tener una actualización sobre los problemas de corewf:

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

¿Cómo ha desbloqueado la API añadida el proceso de portabilidad y qué podemos hacer para ayudar?

Creo que, independientemente de netstandard2.0 , este puerto debería ir como iba en mi humilde opinión... Con una reescritura... Haciéndolo amigable para programadores de tareas externas, async/await/Task, y otras cosas modernas. Por mucho que ame WF, la versión actual está bastante desactualizada...

Lo digo sin faltar al respeto en absoluto. Honestamente. Pero, ¿soy el único aquí que entiende que este proyecto no tiene remedio? Necesitamos desesperadamente un buen motor de flujo de trabajo para .Net, pero simplemente no lo es. ¿No deberíamos estar cambiando la conversación aquí?

Estoy abierto a un nuevo y mejor motor de flujo de trabajo. En pocas palabras, necesitamos uno en .NET Core. Hemos usado WF durante años y nos ha funcionado muy bien, así que es mejor que nada si esa es la alternativa.

@kalokamgit , la fuente está disponible en la fuente de referencia. Está en dos montajes:
System.Activities.Presentation y System.Activities.Core.Presentation .

Desafortunadamente, la herramienta que publica la fuente de referencia solo hace el código C#. No incluye ninguno de los archivos XAML. Puede enviar comentarios sobre esto a [email protected] y/o votar sobre el problema de la voz del usuario .

El código está en .NET Framework, por lo que puede usarlo en sus propias herramientas. Algunos ejemplos son el proyecto de @orosandrei y un proyecto de ejemplo aquí .

Lo digo sin faltar al respeto en absoluto. Honestamente. Pero, ¿soy el único aquí que entiende que este proyecto no tiene remedio? Necesitamos desesperadamente un buen motor de flujo de trabajo para .Net, pero simplemente no lo es. ¿No deberíamos estar cambiando la conversación aquí?

Bueno, si _de verdad_ no quieres faltarte el respeto. :) Tengo curiosidad por saber qué piensan todos sobre Flow . Eso es lo que pienso cuando pienso en el "flujo de trabajo" para el "día moderno"... también en lo que Azure está promocionando bastante en estos días.

REALMENTE lo digo en serio :)

¿Guess Flow es la respuesta al crecimiento de Zapier? No veo cómo reemplazaría a WWF de ninguna manera.

¿Se suspendió WF o me estoy perdiendo algo aquí? ¡Sería muy triste!

¿Dónde puedo votar por WF?

La publicación principal de este número es el mejor lugar.

Me pregunto qué piensa @rjacobs (gurú de WF) de este asunto.

¿Te refieres a @ronljacobs?

@dmetzgar Probablemente sí. Él es el verdadero héroe de WF.

Esta es mi respuesta
https://github.com/danielgerlag/workflow-core

Ron Jacobs fue el tipo que puso su corazón y alma en WF durante años y años. Contrajo la enfermedad de Dercum y dejó Microsoft en 2013. (aquí) Cuando se fue, eso fue todo para WF. Una vez más, y con suerte por última vez: WF HA MUERTO.

Y una vez más, animo a todos y a cualquiera a ver el proyecto de Dan Gerlag, arriba. Es elocuente, bellamente concebido y se ejecuta en Core. Cualquiera que desee contribuir a una solución de flujo de trabajo viable debe buscarla.

También eche un vistazo a Durable Task Framework . Esto se está agregando a Azure Functions, consulte Durable Functions .

@dmetzgar Este marco está en pañales para ser considerado una alternativa a WF. No creo que sea grave que Microsoft proponga este tipo de cosas. ¿No sería mucho mejor en lugar de reinventar la rueda, migrar WF a .NET Core y reutilizarlo como base en todos los proyectos de Microsoft? Perdón por la dureza de mis palabras, pero creo que representan el sentimiento de muchas personas que están muy decepcionadas con la situación actual de WF.

@Suriman , punto justo

Actualicé el archivo Léame en el repositorio de corewf para tener una mejor descripción de lo que implica migrar WF a .NET Core. ¿Le importaría echar un vistazo?

@dmetzgar Gracias por las aclaraciones y por mostrar claramente el camino a seguir para migrar WF a .NET Core. Entiendo por lo que dices que Microsoft no va a hacer todo este trabajo de migración y que espera que la comunidad lo haga, ¿o sí? La respuesta a esta pregunta es la clave, dependiendo de la respuesta, las empresas pueden optar por una ruta alternativa o hacer el trabajo que debe hacer Microsoft.

Microsoft no realizará una migración oficial de WF a .NET Core. Mi equipo y yo trabajaremos en esto en nuestro tiempo libre, pero no de manera oficial ni con lanzamientos programados. Todos los temas enumerados están en juego. Hay usos para dicho puerto para algunos de los proyectos que hacemos. De ahí será de donde provengan la mayoría de nuestras contribuciones. Creo que es justo cerrar este problema por ahora y dirigir a las personas al repositorio de corewf para seguir el trabajo más reciente.

Hola,
El cambio del hito futuro a 2.1, ¿significa que Microsoft transferirá WF a .NET Core?

El cambio de hito para problemas cerrados solo refleja durante qué versión se cerró el problema.
Este problema en particular se cerró básicamente como "No se solucionará". Consulte la explicación anterior https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275

@karelz Que pena. Por un momento, parecía que nos había tocado la lotería.

Tenemos una Solución basada en WF. Estamos creando pasos de actividades usando WF y este flujo de trabajo se entregará a todos los suscriptores y procesarán las acciones basadas en WF. Amamos mucho a WF. apoyar multiplataforma es la dirección de nuestra empresa. Estamos muy interesados ​​en tener WF en .NET CORE.

Hay CoreWF, que es el código de Workflow Foundation parcialmente portado a .net core. Ahora puede usar la base de Workflow multiplataforma. Simplemente no puede usar flujos de trabajo basados ​​en XAML en este momento.

Tengo una sucursal en la que he trabajado para agregar compatibilidad con Dynamic Activity además de Net Standard 2.0 .

El proceso de análisis de XAML requiere que Microsoft abra System.XAML lo suficiente para que podamos avanzar en el análisis de los archivos correctamente.

Puede seguir el progreso del problema aquí: https://github.com/dmetzgar/corewf/issues/6 y en mis diversos intentos de notificar este problema:
En CoreFX
En fuente de referencia

El paquete de compatibilidad de .Net tiene un "Quizás" en el frente de System.XAML. Pero no se ha filtrado ninguna noticia sobre su inclusión. El problema Enviar paquete de compatibilidad de .Net Framework actualmente enumera "sin planes" para System.XAML.

Tal vez también se podría usar el tema Customer Adoption Epic para contar su historia de cómo agregar Workflow Foundation (y System.Xaml) le permitiría a su empresa enviar un producto.

Mi empresa también está invertida en WF: tenemos un producto para empresas de energía donde nuestros clientes crean flujos de trabajo utilizando Workflow Foundation.

Gracias por su respuesta.
fue muy útil se lo agradezco.

El 2 de noviembre de 2017 a las 18:22, "Eric Winnington" [email protected] escribió:

Hay CoreWF https://github.com/dmetzgar/corewf que es el código de
Workflow Foundation parcialmente portado a .net core. Puede utilizar el flujo de trabajo
fundación plataforma cruzada ahora . Simplemente no puede usar flujos de trabajo basados ​​en XAML
en este momento.

Tengo una sucursal en la que he trabajado para agregar soporte para Dynamic Activity
sobre Net Standard 2.0 https://github.com/ewintonton/corewf .

El proceso de análisis de XAML requiere que Microsoft abra System.XAML
suficiente para que podamos avanzar analizando los archivos correctamente.

Puede seguir el progreso del problema aquí: dmetzgar/corewf#6
https://github.com/dmetzgar/corewf/issues/6 y en mis varios intentos
al dar aviso de este problema:
En CoreFX
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
En fuente de referencia
https://github.com/Microsoft/referencesource/issues/39

El paquete de compatibilidad .Net
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
tiene un "Quizás" en el frente de System.XAML. Pero no se ha filtrado ninguna noticia sobre su
inclusión. El problema Envío del paquete de compatibilidad de .Net Framework
https://github.com/dotnet/corefx/issues/24909 actualmente enumera "no
planes" para System.XAML.

Tal vez también el problema Épica de adopción del cliente
https://github.com/dotnet/corefx/issues/24751 podría usarse para decir
su historia de cómo agregar Workflow Foundation (y System.Xaml) permitiría
su empresa para enviar un producto.

Mi empresa también está invertida en WF: tenemos un producto para empresas de energía
donde nuestros clientes crean flujos de trabajo utilizando Workflow Foundation.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

Hola,
Este es un mundo de microservicios y todo se divide en componentes. Ahora bien, si tenemos que orquestarlo, tendremos que depender de las aplicaciones lógicas de Azure o de algún otro proveedor externo que cobre una prima por un flujo de trabajo. Aunque hay muy pocos productos que no sean .NET WF como Netflix Conductor, nos encantaría tener uno en versión .NET core pura. Puede tomar las pistas del conductor de Netflix en https://github.com/Netflix/conductor y comenzar a construir uno desde allí. Esto será de gran ayuda para los desarrolladores de nube privada que no tienen acceso a Azure Stack y que no pueden usar Logic Apps.

Pensé que publicaría aquí por el bien de la conciencia. Estaba leyendo la siguiente documentación y me hizo pensar en este hilo:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

Parece que Dynamics365 y PowerApps están haciendo una fusión mental y están usando Windows Workflow de alguna manera para el manejo de su flujo de trabajo ahora. Por supuesto, todo esto es solo para Windows, pero en la nueva era de multiplataforma, etc... ¿cuánto durará esto?

No sé lo que se supone que debo usar. Ojalá MSFT hiciera esto. Aporta claridad Microsoft.

@VenkateshSrini , también debe consultar Cadence: https://github.com/uber/cadence
El modelo se parece más al SWF de Amazon, pero es de código abierto. Sin embargo, todavía no hay un cliente .NET.

En busca de una. Versión de núcleo neto

No va a pasar.

De: VenkateshSrini [email protected]
Enviado: miércoles, 26 de septiembre de 2018 00:30
Para: dotnet/corefx [email protected]
CC: Jeffrey Michelson [email protected] ; Mencionar [email protected]
Asunto: Re: [dotnet/corefx] Port Workflow Foundation a .NET Core (#2394)

En busca de una. Versión de núcleo neto

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5uewLNgaJpZM4FaQMY .

Demasiado

Entonces, ¿qué ofrece Microsoft para ifttt o flujo de trabajo en un ecosistema que no sea de Azure? Cuando quieren habilitar cosas como ml fuera de Azure, ¿por qué no flujos de trabajo?

Mira el trabajo de Dan Gerlag.

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

De: VenkateshSrini [email protected]
Enviado: miércoles, 26 de septiembre de 2018 8:34 a. m.
Para: dotnet/corefx [email protected]
CC: Jeffrey Michelson [email protected] ; Mencionar [email protected]
Asunto: Re: [dotnet/corefx] Port Workflow Foundation a .NET Core (#2394)

Entonces, ¿qué ofrece Microsoft para ifttt o flujo de trabajo en un ecosistema que no sea de Azure? Cuando quieren habilitar cosas como ml fuera de Azure, ¿por qué no flujos de trabajo?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY .

Hay CoreWF, que es un puerto de Workflow Foundation para .NET Core. Este puerto está progresando. Estamos buscando personas para ayudar.

El siguiente paso importante es compilar flujos de trabajo cargados con Roslyn para que podamos usar código en los parámetros de flujo de trabajo, esto es necesario para los flujos de trabajo definidos por XAML. Si define flujos de trabajo en el núcleo imperativo, puede usar CoreWF ahora.

¡Gracias por su trabajo @ewinton y @dmetzgar ! La compatibilidad con XAML a través de Portable.XAML en CoreWF es muy importante para ese esfuerzo. @dmetzgar ¿Planea publicar una nueva versión en NuGet pronto?

Hola a todos,

¿Está todo listo para la producción? Estamos retrasando la definición del flujo de trabajo para que se realice desde una interfaz de usuario externa. Pero el motor debería poder cargar la definición y trabajar desde su inicio. Más de un tipo iffft

@VenkateshSrini , no creo que sea necesario que Microsoft proporcione un marco de flujo de trabajo multiplataforma. En los días de .NET Framework, Microsoft proporcionó todo, lo que fue en detrimento de la comunidad en general. Me gustaría ver más bibliotecas de código abierto de .NET adoptadas por organizaciones y "listas para la producción".

@watertree , estoy esperando una nueva versión de Portable.Xaml. Se necesita una solución crítica para la compatibilidad con CoreWF XAML.

¿Cuál es la alternativa para los flujos de trabajo de ejecución prolongada por ahora (con persistencia)? Solo los de pago?

@freerider7777

Para tu información: https://github.com/danielgerlag/workflow-core

Lo usamos en nuestra empresa con muy buenos resultados.

Para aquellos que aún lo siguen, el proyecto CoreWf acaba de avanzar un hito significativo con la integración de Roslyn para permitir la ejecución de flujos de trabajo XAML cargados dinámicamente. Si aún necesita Workflow Foundation en dotnet core, compruébelo.

Hola ,
¿Eso significa que puedo tomar el flujo de trabajo XAML existente y usarlo tal como es? ¿Tenemos alguna limitación?

¿Tenemos alguna limitación?

El almacén de instancias aún no se ha portado, el diseñador no está en el núcleo y el servicio WCF no está disponible debido a que el servidor WCF aún no está en el núcleo.

Haga un problema en el repositorio de CoreWf y enumere los requisitos que tiene. Podemos continuar la conversación allí.

El nuget actual para corewf está desactualizado y no incluye la ejecución de Xaml en tiempo de ejecución basada en Roslyn que se acaba de fusionar. Todavía estamos buscando comentarios para ver qué funciona y qué no.

¿Significa esto que nunca va a suceder?

No va a suceder. Nunca iba a suceder - - sin ofender a aquellos que pusieron sus mejores esfuerzos. Consulte el proyecto de Dan Gerlag (https://github.com/danielgerlag/workflow-core) o muerda la bala y súbase al tren de Azure LogicApps.

Hola, esta es la llamada de octubre de 2020. ¿Alguna noticia, actualización o lanzamiento de Workflow Foundation en .NET Core?

¿O deberíamos pasarnos todos a Elsa? https://elsa-workflows.github.io/elsa-core/

@wstaelens Creo que la respuesta de MS fue bastante clara : WF no se transferirá oficialmente a .Net Core. La alternativa sugerida es CoreWF .