Runtime: Workflow Foundation을 .NET Core로 이식

참조: @terrajobst , @joshfree , @weshaggard

이식에 진지한 노력을 기울이기 전에 System.Xaml을 열어야 합니다.

@jakesays 를 이해합니다.

요점은 WF가 XAML 대신 C# 클래스에서 워크플로 정의를 만들 수 있으며(현재로서는) 많은 사람들이 XAML 표현을 사용하지도 않는다는 것입니다. 나중에 System.Xaml이 열리면 비주얼 디자이너와 XAML 정의도 통합할 수 있습니다. 또한 우리는 WF 사용/구현을 엄격히 준수하지만 XAML을 워크플로 정의를 위한 기본 저장소로 사용하는 대신 저장소용 Json을 기반으로 하는 워크플로 엔진에 대해 작업하고 있습니다. 플랫폼(VS 또는 WPF/WForms용 호스트된 디자이너 구성 요소 뿐만 아니라) 및 더 빠른 읽기/쓰기, 스키마 단순성, 더 빠른 로드/컴파일 및 런타임 작업과 같은 여러 이점이 있습니다. 예를 들어 가벼운 런타임으로 인해 Windows Phone/Store 앱에서 애플리케이션 UI 흐름을 안내하기 위해 클라이언트 워크플로를 강화하는 데 사용할 수도 있습니다.

저는 WF가 .Net 플랫폼에서 정말 강력한 구성 요소라고 생각하지만 오늘날 기술의 경우 XAML은 여전히 ​​"제한기"이지만 MS의 전략 결정을 위해 그대로 유지하고 CoreCLR로 이식할 수 있습니다.

감사 해요

@zhenlan 은 WF에 대한 현재 생각에 대해 이야기할 수 있습니다.

@galvesribeiro 많은 사람들이 xaml을 사용하지 않을 수 있지만 많은 사람들이 사용하며 실제로 WF의 핵심 부분으로 간주됩니다. 우리는 xaml을 광범위하게 사용하므로 xaml 지원이 없는 WF는 거의 사용할 가치가 없습니다.

System.Xaml을 열도록 Microsoft에 계속 로비를 하고 싶습니다.

그리고 JSON을 대체물로 사용하는 것은 그다지 매력적이지 않습니다.

@galvesribeiro @jakesays 우리는 WF 고객이 .NET Core 버전의 WF에 얼마나 관심이 있는지 알고 싶어 커뮤니티에서 피드백을 듣는 것이 좋습니다. 수요가 충분하다면 앞으로 나아가는 데 도움이 될 것입니다.

우리는 타당성, 종속성, 기능 우선 순위 등을 평가하는 초기 단계에 있습니다. 따라서 어떤 시나리오가 마음에 드는지, .NET Core의 WF(전체 .NET의 WF)가 필요한 이유를 배우는 것은 매우 도움이 될 것입니다. 사용자에게 유용하고 가장 먼저 보고 싶은 WF 기능.

@galvesribeiro 코드로 워크플로를 구축하고 해당 정의를 JSON으로 저장하는 시나리오에서 표현식에 무엇을 사용하시겠습니까? VB 식, C# 식을 사용하고 있습니까, 아니면 CodeActivity를 기반으로 하여 식을 처리하는 고유한 식 활동이 있습니까?

입력해 주셔서 감사합니다.

@jakesays 는 XAML을 사용하는 것이 좋습니다. 성능만 신경쓰는데...

@zhenlan 우리는 브라질의 일부 ​​은행과 해외의 일부 은행에서 하루에 수십억 건의 신용/직불 카드 거래를 처리하는 전자 결제 스위치를 보유하고 있습니다. 우리는 완전한 온프레미스였으며 완전한 클라우드가 되도록 기술을 업데이트하고 있으며 Azure에서 서비스로 제공하고 있습니다. Azure에서 고객을 위한 다중 테넌트 지불 처리 플랫폼으로 필요한 모든 것을 살펴보기 위해 기업계약을 체결했습니다.

서비스를 실행하는 데 소요되는 공간, 공격 표면 및 유지 관리를 줄이기 위해 NanoServer 및 CoreCLR의 사용을 조사하고 있으며 coreCLR에는 (적어도) System.Activities가 아직 이식되지 않은 것으로 나타났습니다. 즉, Workflow Foundation이 없습니다.

우리의 핵심 처리 엔진은 최고의 WF를 기반으로 하는 비즈니스 엔진이며 우리의 비즈니스에 중점을 둔 40개 이상의 사용자 지정 활동이 포함되어 있습니다. 이 엔진은 트랜잭션 승인을 얻기 위해 트랜잭션 프로세스/규칙을 실시간으로 처리합니다. 필요에 따라 확장해야 하며 현재 클라우드에서 구현된 WF로 확장해야 합니다.

.net 전체(서버 프로필)로 유지하는 대신 .net 코어로 이식하면 클라이언트 워크플로를 실행할 수 있는 가능성이 열리며, 이는 우리가 비즈니스에서 정말 놓치고 있는 부분입니다. 이러한 클라이언트 워크플로는 스마트폰, 웨어러블, IoT 및 결제 터미널 장치와 같은 소형 장치가 실제 반복 코드를 작성하지 않고도 일부 결정을 내릴 수 있는 방식으로 클라이언트-비즈니스 로직을 선언적으로 개발하도록 만들 수 있습니다.

.net Core용 WF에 대한 노력을 찾지 못했고 심지어 몇 년 동안 변경되지 않았고 여전히 XAML에 의존하고 있기 때문에 WF와 정확히 동일한 방식으로 작동하는 자체 워크플로 엔진을 시작하기로 결정했습니다. 동일한 활동 모델, 동일한 코드 스타일 등이지만 훨씬 가볍고 Json을 정의 저장소로 기반으로 합니다. 이를 통해 컴퓨팅 성능이 작은 장치에서 XAML/XML을 처리하는 오버헤드 없이 워크플로를 처리할 수 있으므로 WF용으로 만든 대부분의 코드는 XAML 기반 워크플로 대신 Json 정의에 대한 많은 변경 없이 작동합니다. 또한 XAML에서 벗어나면 새로운 워크플로 디자이너에게 가능성이 열립니다. Visual Studio 및 WPF 응용 프로그램에서 VS 디자이너를 다시 호스팅하지 않아도 됩니다.

내가 제안하려는 것은 그 옵션 중 하나입니다.

1. 포트 WF(XAML 포함)는 .Net 코어에 있는 그대로입니다. 이 옵션은 오늘날 WF가 .Net의 서버 프로필에 의존하기 때문에 훨씬 더 많은 시간이 소요됩니다. 따라서 .Net 코어와 함께 작동하도록 하기 위해 분리하는 데 많은 시간을 할애해야 합니다.
2. Port WF는 이를 .Net 코어로 다시 작성합니다. 이런 식으로 우리는 핵심 개념을 얻고 서버, 클라이언트, IoT 또는 현재 WF에 구현된 디자인 원칙과 기능을 유지하는 데 필요한 모든 것에서 실행할 수 있는 보다 가벼운 엔진을 디자인하는 데 집중할 수 있습니다. 이렇게 하면 XAML에서 (예를 들어)Json 기반 워크플로 정의로 마이그레이션하는 데 아주 적은 노력과 마찰이 없는 프로세스가 됩니다. 모든 현재 활동을 새 모델로 이식해야 합니다.

나는 당신에게 팀을 구성하거나 새로운 제품에 참여하라고 요구하지 않습니다. 커뮤니티는 ASP.Net 및 Entity Framework에 대해 수행하는 것처럼 이를 수행할 수 있습니다. 코어에 내장되지 않은 외부 및 보조 프레임워크로 만드십시오.

감사 해요

@jimcarley 표현식은 XAML에서 오늘날과 같은 방식으로 컴파일됩니다. 워크플로 중 하나에는 다음이 있습니다(VBValue도 될 수 있으며 샘플이 있음).
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

오늘날 XAML의 식은 대부분 부울을 반환하거나 일부 변수에 일부 값을 할당하므로 현재 XAML에 저장되는 것과 동일한 방식으로 저장되지만 Json에서는 동일한 아이디어에 따라 컴파일될 수 있습니다. 오늘.

Azure Resource Manager(ARM)를 보면 이미 하고 있습니다! 종속성과 흐름이 있는 Json 템플릿으로 리소스를 배포하고 변수를 표현식으로 호출할 수 있습니다. 이것을 보십시오:

"변수": {
"위치": "[리소스 그룹().위치]",
"usernameAndPassword": "[concat('parameters('username'), ':', parameters('password'))]",
"authorizationHeader": "[concat('기본 ', base64(variables('usernameAndPassword')))]"
}

좋아, 그들은 JavaScript 기능을 사용하고 있지만 원리는 동일합니다. 그들은 문서 구조를 안내하는 템플릿 위에 $schema 변수를 가지고 있으며, 우리가 활동으로 만들 수 있는 배포 프로세스의 단계입니다. 디자인은 WF와 매우 유사하지만 이 DSL은 리소스 그룹 배포에 중점을 둡니다. 더 일반적으로 만들고 현재 WF 구현에서와 동일한 방식으로 활동을 사용할 수 있습니다.

여러분이 시도해 볼 가치가 있다고 결정하면 "새로운 WF"의 아키텍처를 안내할 다른 문제에 대한 문서를 그리기 시작할 수 있습니다. 너무 이상하게 들리고 귀하의 계획에서 벗어나면 알려주십시오. 우리는 .net 코어를 지원하기 위해 계속 개발하고 나중에 사람들을 위한 덩어리로 릴리스할 것입니다. 저는 이 멋진 프레임워크를 현재(향후) 기술로 최신 상태로 만들려고 노력 중입니다. 이것은 우리에게 정말 필요한 비즈니스입니다. 우리는 WF에 많이 의존하지만 coreCLR에서 더 빨라지고 지원되지 않으면 NanoServer+coreCLR이 RTM일 때 이를 위해 이동할 수 있도록 이 새 프레임워크 준비를 시작해야 합니다.

질문이 있으면 알려주세요.

감사 해요

추신: 채팅이 필요하면 매일 gitter 채널에 있습니다.

@galvesribeiro 그래서 JSON에 저장된 워크플로 정의에서 Activity 개체를 생성한 후 TextExpressionCompiler를 사용하여 표현식을 컴파일하고 있습니다. 오른쪽?

@jimcarley 아직 표현식 컴파일러가 작동하지 않습니다. 우리는 여전히 TextExpressionCompiler의 동일한 원칙을 사용하여 설계하고 있지만 예, 꽤 동일한 개념처럼 보입니다. 현재 구현은 아직 System.XAML에 연결된 것처럼 보입니다. 열려 있지 않기 때문에 TextExpressionCompiler와 같은 방식으로(내부적으로) 작동하는지 확인할 수는 없지만 활동이 로드된 후에는 표현식을 평가/컴파일해야 합니다(아직 캐시에 없는 경우). 그리고 표현식 개체를 노출해야 합니다. 활동의 소비자가 평가할 것입니다(필요한 경우).

작년에 저는 자체 호스팅 WF 디자이너에서 C# 표현식 지원을 활성화하기 위해 표현식 측면에서 몇 가지 작업을 했습니다. nrefactory와 roslyn을 기반으로 했습니다. 관심 있는 사람이 있으면 파헤칠 수 있습니다.

@galvesribeiro 귀하의 json 접근 방식에 대해 더 많이 생각한 후 결국 새로운 개발에는 실제로 중요하지 않을 것이라고 생각합니다. MS가 xaml 지원을 열지 않으면 이것이 작동할 수 있습니다.

@zhenlan WF를 이식할 팀을 구성하기 위해 MS가 반드시 필요한 것은 아니라는 점에서 @galvesribeiro 에 동의합니다. 이것은 분명히 커뮤니티에서 팀 등의 지침을 받아 할 수 있는 일입니다.

@jakesays coreclr 용 WF를 다시 생성하는 경우 스토리지가 실제로 중요하지 않다는 데 동의합니다.

요점은 웹에서 두 가지의 (역)직렬화 성능을 비교하는 많은 테스트가 있고 json이 훨씬 빠르고 리소스를 덜 소비하기 때문에 Json 대신 XML을 계속 사용하는 이유는 무엇입니까?(예: Newtonsoft의 Json.Net을 다음과 비교 일반 XML 직렬 변환기) WF가 설치 공간이 작은 클라이언트 장치(모든 IoT)에서 실행되는 경우 각 메모리 바이트가 중요합니다.

또한 json을 사용하면 새로운 웹 기반 WF 디자이너를 즉시 확보하는 것이 훨씬 간단해집니다. 표현식 컴파일 및 실행은 구현하기 어렵지 않습니다. 표현식 개체를 빌드하는 것은 대략 문자열의 파서입니다. 어려운 부분(imho)은 WF를 설계하는 동안 사용된 유형에 대해 VS에서 인텔리센스를 얻는 것이지만 Roselyn과 언어 서비스가 이를 도와줄 수 있고 VS가 인프라를 갖추고 있다고 확신합니다.

@galvesribeiro 는 이미 JSON 기반 워크플로 정의 및 직렬화로 자체 워크플로 엔진을 구축했다고 언급했습니다. WF가 Core로 이식된다면 실제로 사용하시겠습니까?

@dmetzgar 우리는 프레임워크에 대한 종속성이 거의 없는 깨끗한 WF에서 더 나은 결과를 얻을 수 있다는 개념 증명으로 이를 개발 및 테스트하기 시작했습니다. 이는 coreclr에서 작동하는 데 좋습니다. 준비가 되지 않았습니다.

XAML을 기반으로 하지만 coreclr로 포팅되고 EntityFramework 및 ASP.Net의 coreclr 버전과 동일한 개념을 따르는 경우에도 자체 엔진을 빌드하고 WF를 계속 사용하지 않아도 되었으면 합니다. 서버 라이브러리 및 모든 곳에서 실행됨).

요점은 여전히 ​​XAML 및 서버 프로필에 의존하는 경우 계속 느려지고(너무 많은 리소스가 필요함) 디자이너 선택에 따라 제한된다는 것입니다.

내 제안은 Json을 사용하여 coreclr로 이식하고 오늘날 많은 종속성을 제거하여 사용자가 원하는 곳 어디에서나 실행할 수 있도록 하는 것입니다. 완료되었습니다!) 종속성과 높은 리소스 소비에 대해 걱정하지 마십시오.

오늘날 우리의 모든 워크플로는 현재 버전으로 생성되며 일부는 순수 코드로 작성되고 일부는 XAML로 작성되지만 두 경우 모두 여전히 종속성이 있습니다.

IMHO, 있는 그대로 coreclr로 이식하면 런타임 및 디자인 시간 모두에 대해 XAML/XML 구문 분석/렌더링을 위한 새로운 경량 엔진이 제공되지 않는 한 많은 이점이 없습니다. 하지만 그대로 이식하기로 결정했다면 실제적인 이점을 가져오지 않는다는 것을 알고 있더라도 0일부터 내 XAML 워크플로가 작동하도록 하기 때문에(희망) 계속 사용할 것입니다...

다시 말하지만, 나는(아마도 @jakesays 및 기타 WF 사용자) 이 포트에서 여러분이 결정하는 것과 상관없이 두 가지 방식(XAML 또는 JSON)으로 이 포트에서 도움을 줄 수 있습니다. 이 포트가 작동하도록 하는 복사 및 붙여넣기 및 수정이 아니라 coreclr의 동일한 아이디어를 따라 사용하는 사람들에게 실제로 이점을 제공하고 문제 없이 모든 곳에서 실행할 수 있는지 확인하고 싶습니다.

감사 해요

@galvesribeiro XAML이 WF에 너무 밀접하게 통합되어 있다는 데 동의합니다. 워크플로에 대한 Dharma의 원래 책 으로 돌아가서 그는 Visio에서 워크플로를 구축한 샘플을 가지고 있었습니다. 최소한 코어로 이식하면 런타임이 XAML과 분리되도록 조각할 수 있습니다. 이를 통해 XAML 팀을 코어로 이식하거나 이식하지 않고 진행할 수 있으며 나중에 언제든지 별도의 GitHub 프로젝트/NuGet 패키지로 XAML 워크플로 지원을 추가할 수 있습니다. 어떤 형식으로든 워크플로를 정의하고 지속할 수 있도록 하는 데 전적으로 동의합니다. 감사합니다. 이 피드백이 도움이 됩니다.

@dmetzgar 저는 언젠가 XAML이 코어로 이식될 것이라는 데 의심의 여지가 없습니다... .net 코어가 Windows Phone 또는 Windows 10 모바일 장치에서 실행된다면 언젠가는 일어날 것이며 우리가 구축할 수 있다는 것에 전적으로 동의합니다 새 코어를 만들고 나중에 워크플로의 정의와 상태에 대한 지속성을 추가합니다.

그렇다면 포팅을 시작하려면 어떻게 해야 할까요? (저희는 이미 기여자 계약을 체결했으며 MS 등과 회사로 다른 NDA를 보유하고 있습니다.)

감사 해요

@galvesribiro 열정에 감사드립니다! GitHub 리포지토리를 열고 해킹을 시작하고 싶은 만큼 몇 가지 단계가 필요합니다. 또한 조각해야 하는 것은 System.Xaml 뿐만이 아닙니다. System.Transactions 및 WCF와의 일부 공유 구성 요소와 같이 WF에 깊이 뿌리내린 다른 종속성이 있습니다. 우리는 이들 각각을 조사하고 있습니다.

이해 했어요. 글쎄요, 저는 여러분을 밀어붙이고 싶지 않습니다. 단지 시간이 걱정될 뿐입니다. 우리는 지금 자체적으로 빌드를 진행하거나 여기 커뮤니티에 가입하고 WF를 coreCLR로 이식하여 제품 일정에 맞출 수 있도록 결정해야 합니다.

@dmetzgar 지금 오픈 소스로 제공할 수 있는 부분을 https://github.com/Microsoft/referencesource에 게시하는 것을 고려해 보셨습니까? 실제로 작동하는 본격적인 오픈 소스 프로젝트를 만드는 것보다 훨씬 간단할 수 있다고 생각합니다.

그렇게 하면 적절한 버전으로 시간을 할애할 수 있고 다른 사람들은 그 동안 자신의 부분/사용자 정의 버전을 만들 수 있습니다.

전체 .NET의 @svick WF 구성 요소는 얼마 전에 이미 github referencesource에 게시되었습니다. 예를 들어 https://github.com/Microsoft/referencesource/tree/master/System.Activities 를 찾을 수 있습니다.

@zhenlan 예, 문제는 일부 종속성이 "해결 가능"하지 않다는 것입니다... 공개되지 않은 System.Xaml에 대한 종속성으로 인해 일부 클래스의 동작이 올바르게 무엇인지 알 수 없습니다...

우리는 항상 끝까지 알아낼 수 있지만, 그것은 우리가 같은 방식을 따르고 있는지 확실히 알지 못한다는 것을 의미합니다.

@dmetzgar System.Transaction은 아직 공개되지 않은 항목이지만(현재로서는) 처리할 수 있다고 생각합니다. WCF와 관련하여 종속성 트리에는 활동과 워크플로 서비스 호스트만 표시됩니다. 코어(IIRC)의 아무 것도 WCF에 종속되지 않습니다.

@galvesribeiro System.Transactions의 상황은 그보다 더 복잡합니다. WF 런타임 전체에 걸쳐 있으며 기본 클래스가 지속성을 위한 위치인 내구성 인스턴스에 크게 의존합니다. WCF와 WF는 .Net 4.0 시간대에 동일한 팀으로 병합되었으므로 WCF와 WF 모두에서 사용하는 System.ServiceModel.Internals와 같은 항목이 있습니다. .Net 코어에는 많은 중요한 사항이 이식되어 있지만 누락된 부분이 많습니다. 누락된 부분을 해결하려면 설계를 변경하거나 기능을 다시 작성해야 할 수 있습니다.

이 문제들 중 어느 것도 극복할 수 없는 것이 아닙니다. 저는 단지 노력을 하찮게 여기고 싶지 않습니다. 이는 코드 및 법적 승인 얻기, 환경 구축, 인프라 테스트 등과 같은 코드와 관련된 모든 것에 적용됩니다. 우리는 커뮤니티가 확실히 도움이 되기를 원하며 이를 위해 노력하고 있습니다. 자신의 포트를 작성해야 하는지 아니면 "공식" 포트를 기다려야 하는지 여부는 시간대에 따라 다릅니다. Nano 서버에서 워크플로를 실행하는 것은 가장 큰 시나리오 중 하나이며 이에 대한 도움을 받고 싶습니다.

@dmetzgar 이해했습니다. 질문이 있을 때 PR이나 법무팀에 전달해야 할 때 항상 약간의 지연이 있었습니다. :)

글쎄요, 적어도 일정 기간에 대한 개념이 있다면 스스로 준비하고 기다릴 수 있습니다. 나는 "잘못된 곳"에서 무언가를 구현하거나 더 나은 일을 하기 위해 힘을 합칠 수 있는 어딘가에서 이미 노력을 기울이고 있는 것을 싫어합니다.

우리가 할 수 있는 일이 있거나 소식이 있으면 알려주거나 디자인/포트에 대한 제안이 필요하면 저에게 핑을 보내주십시오.

감사 해요

기간이 명확해지면 이 스레드를 업데이트하겠습니다. 사람들이 관심을 갖고 있는 다른 시나리오에 대해 듣고 싶습니다. 현재로서는 Nano on WF가 주요 시나리오이지만 다른 사람들이 무엇을 하고 있는지 아는 것이 좋을 것입니다.

안녕하세요 여러분, XAML과 JSON 외에도 활동을 구성하는 멋진 방법인 메타프로그래밍이 있습니다. 제 실험 프로젝트인 Metah.W: A Workflow Metaprogramming Language(https://github.com/knat/Metah)를 살펴보세요.

@jakesays 자체 호스팅 WF에서 C# 식 지원을 활성화하는 방법에 대한 지침을 제공할 수 있습니까?

Xaml을 유지하십시오. :) JSON 직렬화된 객체도 흥미로울 것입니다. 그러나 선호하는 형식을 선택하기 위해 프레임워크에서 어떻게든 구성된 공급자를 보고 싶습니다.

@dmetzgar (및 다른 MSFT 사람들) 이 주제에 관한 소식이 있습니까?
감사 해요

우리는 이 문제를 해결하기 위해 노력해 왔으며 많은 진전을 이루었습니다. XAML은 현재 Core에서 사용할 수 없으므로 런타임에 중점을 둡니다. 우리는 다른 직렬 변환기를 개방하는 방법을 찾고 있습니다. 따라서 JSON 또는 XAML 중 하나를 선택하는 대신 자체 직렬 변환기를 사용할 수 있도록 하는 것이 좋습니다. 아직 더 많은 규정 준수 및 승인을 받아야 하는 법적 사항이 있습니다. 많은 고객이 이 포트를 추진하지 않기 때문에 우선 순위가 낮습니다.

@dmetzgar 달콤한! 나는 그것에 기여하게 되어 기쁩니다. 그러나 이것이 핵심 프로젝트가 된다면 할 수 있습니다... 그것이 웹 워크플로 디자이너든 등등. xaml은 정의 형식을 위해 거기에 거의 필요하지 않은 것 같습니다... 듣게 되어 기쁩니다. 이 작품에 대해!

안녕하세요 여러분, 메리 크리스마스와 새해 복 많이 받으세요!

따라서 해당 포트에 대한 업데이트나 현재 작업의 최소한 OSS 릴리스가 있어서 도움을 드릴 수 있습니까?

감사 해요

@galvesribeiro 최대한 상황을 설명하도록 노력하겠습니다. WF를 .NET Core로 이식하려는 열의에서 나는 이 모든 것의 비즈니스 측면을 고려하지 못했습니다. WPF/XAML은 .NET Core로 이식되지 않으며 이는 WF의 상당 부분을 나타냅니다. XAML은 런타임에 필수적인 것은 아니지만 대부분의 고객이 워크플로를 빌드하는 방법입니다. 이것은 Core의 WF가 유용하다고 생각하는 청중을 제한합니다. 두려움 중 하나는 Core에서 WF를 출시하고 커뮤니티 참여가 많지 않다는 것입니다. 이는 지원 비용을 추가하고 대부분의 WF 고객의 상황을 개선하지 않습니다. WF가 Linux 시스템에서 실행되는 것을 보는 것은 멋진 일이지만 누군가가 실제로 그것을 사용할 것이라는 것을 증명하기는 어렵습니다.

저는 OmniXAML을 알고 있으며 저자에게 MIT 라이선스로 변경하도록 설득했습니다. 따라서 약간의 투자를 통해 잠재적으로 XAML이 작동하도록 할 수 있습니다. 그러나 이것이 기존 WF 고객에게 어떤 이점이 있는지에 대해서는 여전히 의문이 있습니다. 어느 날 SharePoint 또는 Dynamics와 같은 대규모 고객이 와서 Nano로 전환한다고 말하면 설득력 있는 사례가 될 것입니다. .NET Framework 팀이 Nano에서 전체 프레임워크를 실행할 수 있는 패키지를 만들기로 결정했다면 그것은 모두 무의미합니다.

커뮤니티의 관심이 충분하고 프로젝트를 옹호하려는 누군가가 있다면 그렇게 할 수 있습니다. Open Live Writer와 비슷합니다. 까다로운 부분은 우리 팀이 가능한 한 이 일에 기여하지만 그런 종류의 프로젝트에는 Microsoft 지원이 제공되지 않는다는 것입니다. 대부분의 WF 고객은 주로 Microsoft가 WF를 지원하기 때문에 WF를 사용하는 것 같습니다.

.NET Core와 전체 .NET Framework가 서로 다른 두 제품이라는 점을 강조하는 것이 중요하다고 생각합니다. .NET Framework는 죽지 않습니다. 계속해서 지원하고 기능을 추가할 것입니다. 따라서 WF를 계속 유지하기 위해 .NET Core로 WF를 이식해야 하는 것은 아닙니다. Core의 WF는 기본적으로 새 제품입니다. 확실한 비즈니스 정당성을 제시하는 것은 어렵습니다. 타이밍의 문제일 수도 있습니다. 더 많은 회사가 Nano 서버를 채택함에 따라 더 강력한 사례가 있을 수 있습니다.

@dmetzgar Portable.Xaml은 어떻습니까? 대안이 될 수 있습니까? https://github.com/cwensley/Portable.Xaml Eto를 위한 환상적인 Eto.Forms 프로젝트 작성자가 사용하기 위해 추출했습니다. MIT 라이센스가 있으며 모노 프로젝트에서 파생된 클래스 라이브러리도 마찬가지입니다.

@dmetzgar ,

최대한 상황을 설명하려고 노력하겠습니다. WF를 .NET Core로 이식하려는 열의에서 나는 이 모든 것의 비즈니스 측면을 고려하지 못했습니다. WPF/XAML은 .NET Core로 이식되지 않으며 이는 WF의 상당 부분을 나타냅니다. XAML은 런타임에 필수적인 것은 아니지만 대부분의 고객이 워크플로를 빌드하는 방법입니다. 이것은 Core의 WF가 유용하다고 생각하는 청중을 제한합니다. 두려움 중 하나는 Core에서 WF를 출시하고 커뮤니티 참여가 많지 않다는 것입니다. 이는 지원 비용을 추가하고 대부분의 WF 고객의 상황을 개선하지 않습니다. WF가 Linux 시스템에서 실행되는 것을 보는 것은 멋진 일이지만 누군가가 실제로 그것을 사용할 것이라는 것을 증명하기는 어렵습니다.

WF 현 사용자들에게 가장 큰 동기는 리눅스가 아닌 나노 서버와 마이크로 서비스라고 생각합니다. Linux는 더 많은 사용자를 추가하지만 실제 동기는 아닙니다.

그러나 이것이 기존 WF 고객에게 어떤 이점이 있는지에 대해서는 여전히 의문이 있습니다.

우리는 구름이 많은 시대에 살고 있습니다. "클라우드 우선, 모바일 우선..." 및 성장하고 있는 빅 기술 중 하나는 컨테이너, 마이크로 서비스 및 MS의 큰 제안인 나노 서버라는 것을 기억하십시오.

어느 날 SharePoint 또는 Dynamics와 같은 대규모 고객이 와서 Nano로 전환한다고 말하면 설득력 있는 사례가 될 것입니다.

지구상에서 가장 큰 Sharepoint 또는 Dynamics를 배포하더라도 동일한 수의 사용자에 도달하지 못할 것이며 심지어 클라우드 기술로 창출되는 것과 동일한 수준의 수익이라고 말할 수 있습니다.

.NET Framework 팀이 Nano에서 전체 프레임워크를 실행할 수 있는 패키지를 만들기로 결정했다면 그것은 모두 무의미합니다.

오늘날 DNX(RC1까지)는 coreCLR만이 아닙니다. 여기에는 전체 프레임워크(dnx451)도 있으므로 현재 DNX에서 WF를 사용할 수 있으며 여기서 문제가 되는 것은 아닙니다. coreCLR(dnxcore50)에 대해 이야기하고 있습니다.

커뮤니티의 관심이 충분하고 프로젝트를 옹호하려는 누군가가 있다면 그렇게 할 수 있습니다. Open Live Writer와 비슷합니다.

Open Live Writer로 만든 것과는 비교하지 않겠습니다... 이 정도면 ASP.Net, MVC, Entity Framework로 만든 것 같습니다. .Net 제품군의 핵심 "제품"은 오늘날 오픈 소스입니다.

까다로운 부분은 우리 팀이 가능한 한 이 일에 기여하지만 그런 종류의 프로젝트에는 Microsoft 지원이 제공되지 않는다는 것입니다. 대부분의 WF 고객은 주로 Microsoft가 WF를 지원하기 때문에 WF를 사용하는 것 같습니다.

실제로 WF 고객은 MS 지원 계약을 사용합니다... 특히 Dynamics 및 Sharepoint 고객은 이를 사용합니다. 그러나 이 세상에는 여전히 지원이 필요한 응용 프로그램이 많이 있습니다. OSS가 지원되지 않아서 사람들이 그것을 사용한다는 것은 CoreCLR, EF, ASP.Net이 MS에서 지원하지 않을 것이라고 말하는 것과 거의 같습니다. 이러한 프로젝트는 현재 OSS이지만 MS 팀에서 철저하게 모니터링하고 조정합니다.

예를 들어, 저는 MS Orleans 프로젝트의 사용자로 시작했습니다. 거의 7년 동안 모든 Halo 클라우드 서비스를 지원합니다. Skype, Outlook 및 기타 많은 MS 공용/클라우드 서비스에서 이를 어떻게든 활용합니다. 몇 년 전에 MS Research에서 OSS를 받았고 현재는 343 Studios, MSR의 일부 및 MS 내부의 다른 그룹의 일부에서 유지 관리하지만 대부분 커뮤니티에서 유지 관리합니다. 오늘날 나는 나 자신을 그 프로젝트에 적극적으로 기여하고 있다고 생각하며 다른 MS 및 MS가 아닌 사람들과 함께 새로운 사용자를 지원합니다. Orleans의 GH 팀 내부에는 전(나처럼) MS 직원이 아닌 사람들도 있습니다. 이것은 우리가 지원하지 않는다는 것을 의미합니까? 글쎄, 나는 Orleans를 구입하지 않았으므로 구체적으로 Orleans에 대한 MS와의 계약 내에서 법적으로 지원을 요청합니다. 그러나 .Net 프레임워크 또는 기타 관련 제품을 대상으로 하여 그렇게 할 수 있으므로 귀하의 진술에 정말 동의하지 않습니다.

확실한 비즈니스 정당성을 제시하는 것은 어렵습니다.
Sharepoint와 Dynamics 고객만 찾는다면 동의합니다.

음, 우리는 전 세계의 다른 많은 회사와 마찬가지로 이러한 계약에서 가장 가변적인 제품을 사용하여 Microsoft와 대규모 EA(기업 계약)를 유지합니다. 우리의 경우 하루에 수백만 건의 금융(신용/직불 카드) 거래를 처리하고 각 거래는 Orleans와 Microsoft Azure 내부에서 실행되는 WF의 인스턴스 하나를 나타냅니다. 나는 당신이 비즈니스 정당화로 행동하기 위해 무엇이 큰지 모르겠습니다.

XAML이 없는 핵심(System.Activities)은 coreCLR로 이식될 수 있고 디자이너는 XAML, Json, HTML, XML 등에 대한 수요에 따라 생성될 수 있다고 생각합니다. 이 종속성을 분리함으로써 다른 가능성이 열립니다.

이 스레드의 시작 부분에서 말했듯이 지금 우리가 원하는 가장 무거운 작업은 OSS를 받고 MSFT의 누군가(최소한 초기에는) PR을 검토할 수 있게 하는 것입니다. 여기서 상식은 WF를 다시 작성하는 것이며 coreCLR에 대해 복사 및 붙여넣기만 하는 것이 아니라 이에 대한 큰 기여를 기대할 수 있습니다.

그것이 일어나지 않을 것이라면 우리는 이 문제를 종결할 수 있고 최소한 사람들은 다른 OSS 또는 결국 CoreCLR 지원을 받게 될 유료 워크플로 엔진을 찾기 시작할 것이라고 생각합니다. CoreCLR 내부에 없으면 큰 손실이라고 생각합니다 ...

WF가 .Net Core로 이식되어야 하는 매우 강력한 이유를 제시할 수 있습니다.

Microsoft는 개발자를 UWP 플랫폼으로 안내합니다. UWP는 미래의 Windows 플랫폼이 될 것입니다. Linux 등으로 앱을 이식하는 멋진 아이디어와는 아무 관련이 없습니다. Windows 10 시스템에서 WF를 실행해야 하는 어려운 상황이 발생하며 UWP는 Windows 10 플랫폼의 미래입니다.

우리는 가끔 연결되는 앱을 만듭니다. .Net 백 엔드와 UWP 프런트 엔드가 있습니다. 현재 모든 비즈니스 논리는 .Net 및 UWP에서 공유됩니다. 그러나 우리는 WF에서 비즈니스 로직을 소프트 코딩하고 싶습니다. 이것은 .Net에서 제대로 작동하지만 WF는 현재 UWP에서 지원되지 않으므로 사용자가 인터넷에 연결되어 있지 않으면 WF 논리에 의해 검증된 호출을 할 수 없기 때문에 WF는 쓸모 없게 렌더링됩니다.

UPW에는 XamlReader가 있으므로 XAML 구문 분석은 실제로 큰 문제가 아닙니다...

@MelbourneDeveloper 는 모든 이유에 동의하지만 UWP와 .Net Core(최소한 현재)는 동일한 이름 아래에 있지 않습니다. 즉, 동일한 하위 수준 API를 공유하고 동일한 API 표면(및 . Net Core는 OSS이고 UWP는 그렇지 않음), 동일한 것이 아니며 호환되지 않습니다. 즉, .Net Core 어셈블리를 UWP 어셈블리에 추가할 수 없습니다. 이러한 차이점(IMHO)은 결국 제거되지만 현재로서는 여전히 존재합니다...

예. 이해했다. 이 두 가지가 미래에 하나로 합쳐질 것이라는 작업 가정 하에였습니다. 그렇지 않다면 하나님께서 우리를 도우소서!

또한 @MelbourneDeveloper UWP의 Xaml은 완전히 다른 .NET의 Xaml 버전입니다. WindowsDev의 UserVoice는 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

바라건대 그들이 옳은 일을 하고 @cwensley 의 Mono Xaml 포트 및/또는 제안된 대로 OmniXaml 뒤에 집결하기를 바랍니다. UWP의 Xaml 시스템은 그 자체로 농담이며 채택률이 매우 낮은 이유 중 하나입니다.

이러한 메모와 함께 MSFTies가 NodeJS를 고려해야 하는 비즈니스 사용 사례가 있습니다. 우리 모두가 이 문제에 대해 총체적으로 긁어모으는 시간이 길수록 NodeJS는 시장에서 더 많은 가치를 창출합니다. NodeJS는 진정한 크로스 플랫폼이며 진정으로 유비쿼터스이며 MSFT 기술이 현재(또는 가까운 미래에) 단순히 주장할 수 없는 것입니다. NodeJS는 서버와 클라이언트(모두)에서 작동하며 둘 사이에서 코드 재사용을 가능하게 합니다. 하나의 코드베이스는 네이티브(Cordova를 통해) 및 웹(표준 HTML5 브라우저를 통해) 시나리오에서 작동하며, 이는 MSFT 기반 솔루션으로 수행해야 하는 것보다 훨씬 저렴합니다.

머지 않아 NodeJS에서 시스템을 다시 실행하고 MSFT를 완전히 버리는 것이 역기능 팀이 시장의 경제적 현실을 따라잡을 때까지 기다리는 것보다 더 맛있고(분명히 덜 비싸게) 될 것이라는 점에 도달할 것입니다.

또한 MSFT가 클라이언트 플랫폼에 대해 UWP를 기대하고 있는 것처럼 보이지만 NodeJS가 수행하는 시장의 일부에 도달한다고 언급했기 때문에 이에 대해서도 언급했습니다. 분수라고 하면 과장된 것일 수도 있습니다. 우리는 nodejs 기반 애플리케이션이 도달할 수 있는 2억(Windows 10의 마지막으로 알려진 설치 수) 대 ~3B(BILLION) 장치에 대해 이야기하고 있습니다.

오해하지 마세요. 저는 MSFT를 좋아합니다. 저는 15년 이상을 기술에 투자했으며 개인적으로 여기에 완전히 투자했습니다. 그러나 그 투자와 함께 모든 사람이 올바른 결정을 내리는 것을 보고, 오픈 소스, 크로스 플랫폼의 놀라운 새 시대와 함께 이곳에서 내린 결정과 노력을 자랑스럽게 생각하는 열정이 따릅니다. 나는 또한 모든 사람들이 다가오는 시장 위협에 대해 알고 있기를 바랍니다(또한 내 두려움을 확인/확인하기 위해).

마지막으로, 모든 것이 순조롭게 진행된다면, Portable.Xaml은 OmniXaml과 다르기 때문에 현재 크로스 플랫폼 Xaml 상태에 또 다른 큰 문제가 있습니다. 코드 베이스... 이상적으로는. :)

@Michael-DST는 모든 점에서 귀하와 동의합니다. WF가 실행되기를 원하는 대상 중 하나는 클라이언트(특히 모바일 및 임베디드)입니다. WF를 추가하여 로컬 비즈니스 규칙에 대한 클라이언트 코드를 줄이고 싶습니다. 클라이언트에 의해 Windows 장치(전화, 태블릿 및 IoT)와 같은 UWP에 대해 엄격하게 말하는 것이 아닙니다.

BizTalk 및 Sharepoint와 같이 WF에 의존하는 주요 제품이 있지만 여전히 .Net 정식 버전에 의존할 수 있는 반면 .Net Core(및 이후 UWP) 사용자는 새로운 WF/XAML API에 의존할 수 있다고 믿습니다. 나는 그것이 코드베이스 주위에 많은 #ifs를 암시할 것이라는 것을 알고 있지만 그것이 갈 길일 것입니다...

@galvesribeiro 확인/지원에 감사드립니다. 아무도 .NET이 직면한 이 매우 실제적인(실존적인?) 문제를 인식하지 못하는 것 같아서 때때로 오르막길을 걷는 것처럼 느껴집니다. 사실, .NET 리더십은 기본적으로 과감한 조직이 NodeJS로 완전히 전환하도록 하는 웹 애플리케이션용 AngularJS와 .NET을 결합하도록 권장함으로써 이 문제를 악화시키는 데 도움을 주고 있습니다! (전체 공개, 나는 그것을 썼다. :P ).

WF는 서버 측 기술에 가깝기 때문에 여기에 NodeJS에 관해 너무 많이 게시하는 것을 주저하지만 저와 다른 조직이 보기 시작하는 방식은 모든 영역에 영향을 미치고 전반적으로 .NET을 위협합니다. 현재로서는 NodeJS를 솔루션 스택으로 사용하는 것이 더 비용 효율적이고(시장 도달 범위도 효율적이며) 우리는 이것이 조직이 선택한 기술에 대해 반영하는 것을 보고 있습니다(다시 말하지만 실제로는 그렇지 않음).

결론: 내 불안을 _어딘가_ 두어야 하며 이 스레드가 희생자입니다. :P #죄송합니다죄송합니다

#if defs... yuck, 여기에서 MvvMCross Manifesto 를 인용하겠습니다. "# is for twitter, not code." :피

마지막으로 (OmniXaml의 저자로서) 이 스레드/토론을 알고 있어야 하므로 @SuperJMN 에 태그를 지정하는 것을 잊었습니다. 다음 주 정도에 OmniXaml 대 Portable.Xaml 문제를 개인적으로 다룰 것입니다.

@Michael-DST 예... 실제로 #if는 단방향입니다... .Net Core 팀은 실제(OS별) 구현이 네이티브 코드의 얇은 하위 계층에서 추상화되는 "네이티브 심"의 접근 방식을 취했습니다. WF의 경우 예를 들어 .Net Full용 shim과 .Net Core용 shim이 될 수 있습니다.

나는 Node.js의 팬이 아니며 JavaScript도 아닙니다(저는 여전히 스크립팅 언어라고 생각하는 경향이 있습니다. 프로그래밍 언어는 아니지만 그것이 제 개인적인 의견입니다). 하지만 요즘에는 그 어떤 것과도 비교할 수 없다는 데 동의해야 합니다. xplat 측면에서. Microsoft 자체는 예를 들어 모든 플랫폼에서 실행되기 때문에 VSTS의 빌드 에이전트에 사용합니다.

나는 WF가 현재 버전이 .Net Core를 사용하여 서버 측의 사용자가 되도록 의도되었으며 클라이언트에서도 완벽하게 수행할 수 있는 멋진 기술이라고 생각합니다.

@galvesribeiro ... 100%

또한 shims에 대해 듣는 것이 좋습니다. 많은 승인. :)

마지막으로 여기에서 스레드를 탈선/하이재킹하고 싶지는 않지만 다음을 확인합니다. JavaScript: 저는 스크립팅 언어에 동의합니다. 그러나 다른 형식, 특히 바이트 코드(ish)로 활용할 수 있는 매우 유연한 "언어"이기도 합니다. 이미 보셨겠지만 C++용 .NET 개발자 커뮤니티에서 증가하는/인기 있는 요청은 .NET에 대해서도 동일한 작업을 수행하는 것입니다 (공식 용량에서 .NET을 JS로 변환). 이것은 현재 MSFT 개발자 환경에서 모든 현재(주요) 악을 진정으로 수정할 것입니다.

어쨌든, 정규 일정 프로그래밍으로 돌아갑니다. :P 대화와 생각에 감사드립니다!

너희들은 내가 9년 동안 다루어온 몇 가지 일을 만지고 있다. Microsoft 기술을 사용하는 많은 사람들이 이해하지 못하는 것이 있습니다. 즉, 분산 컴퓨팅의 개념입니다. 처음부터 우리 소프트웨어의 기본 요구 사항은 때때로 연결 모드에서 작동한다는 것입니다. 시간이 지남에 따라 Microsoft는 이를 위한 도구를 제공하기 위해 다양한 시도를 했지만 포괄적인 프레임워크는 개발된 적이 없습니다. 여기에 약간의 동기화 프레임워크가 있고 약간의 LINQ 데이터베이스가 있지만 모든 것이 함께 작동하도록 하는 포괄적인 도구 집합은 없습니다.

지난 9년 동안 우리는 때때로 연결되는 자체 프레임워크를 개발했습니다. 이제 .Net, Silverlight 및 UWP에서 실행됩니다. EF 및 WF와 같은 Microsoft 프레임워크를 활용하기 위해 매우 열심히 노력했지만 Silverlight와 같은 클라이언트 기술 플랫폼에서는 이러한 기술에 대한 지원이 제공되지 않았습니다. 우리는 말 그대로 이제 UWP와 호환되는 Silverlight용 자체 ORM 및 동기화 프레임워크를 구축했습니다.

처음에 WF에 대해 많은 소문이 났을 때 코드 없이 비즈니스 로직을 소프트 코딩하는 방법을 제공했기 때문에 상당히 흥미로웠습니다. 그러나 시간이 지남에 따라 Silverlight와 같은 클라이언트 측 기술에 대한 포트가 있을 것이라고 생각하는 경향이 점점 줄어들었습니다. 이에 대해 포럼에 수많은 질문을 게시했지만 응답은 항상 같았습니다. WF는 서버 측 기술입니다. 왜 Silverlight에서 이를 사용하고 싶습니까?

갈베스리베이로가 말했듯이

"저는 WF가 현재 버전이 .Net Core를 사용하는 서버 측 사용자용으로 의도된 멋진 기술이라고 생각합니다. 클라이언트에서도 완벽하게 할 수 있습니다..."

그리고

"WF가 실행되기를 원하는 대상 중 하나는 클라이언트(특히 모바일 및 임베디드)입니다. WF를 추가하여 로컬 비즈니스 규칙에 대한 클라이언트 코드를 줄이고 싶습니다. 클라이언트에 의해 Windows 장치와 같은 UWP에 대해 엄격하게 말하는 것이 아닙니다. (전화, 태블릿 및 IoT)"

사람들이 이해해야 하는 것은 분산 컴퓨팅의 경우 클라이언트와 서버 기술 사이에 차이가 없다는 것입니다. Git이 작동하는 방식에 대해 생각해 보십시오. Git의 코드는 중앙 저장소를 보고 있는지 아니면 네트워크 어딘가에 있는 노드를 보고 있는지에 관계없이 동일합니다. 코드는 도처에 복제됩니다. 우리의 프레임워크도 마찬가지입니다. 비즈니스 로직은 모든 ​​노드에 복제됩니다. 사용자가 네트워크에 연결되어 있지 않더라도 여전히 동일한 비즈니스 로직을 따라야 하기 때문입니다. 분산 컴퓨팅에서 각 컴퓨터는 말 그대로 서버입니다. 말 그대로 서버와 동일한 코드를 실행합니다.

Silverlight에서 WF 코드를 실행할 수 없고 이제 UWP에서 실행할 수 없기 때문에 WF를 활용할 수 없었습니다. EF가 UWP로 이식되는 것을 보는 것은 고무적입니다. 아마도 이것이 Microsoft가 분산 컴퓨팅이 필요하다는 것을 이해하게 된 시작일 것입니다. 그러나 Microsoft는 분산 컴퓨팅에 참여하고 WF를 전체 분산 컴퓨팅 프레임워크의 일부로 포함해야 합니다. 그러면 분산 컴퓨팅 프레임워크를 삭제할 수 있게 되며 더 이상 해당 코드를 유지 관리할 필요가 없습니다.

정말 훌륭한 관점과 생각 @MelbourneDeveloper. 공유해 주셔서 감사합니다. 나는 또한 Silverlight의 열렬한 팬이었고 그 이후로 그것에 발을 들이고 있었습니다 (따라서 결과 투표와 -- 실제로 -- 위의 사이트). 또한 Azure Mobile Services 에 대해 어떻게 생각하고 오프라인 스토리에서 이를 사용하는 것을 고려했는지 궁금합니다. 저는 분산 컴퓨팅을 사용하는 뉴비이지만(하지만 무슨 말을 해야 하는지 알아내십시오), 내년에 실제로 이 분야에 뛰어들려고 합니다. .

사람들이 이해해야 하는 것은 분산 컴퓨팅의 경우 클라이언트와 서버 기술 사이에 차이가 없다는 것입니다.

정말 좋은 점. 이 시점에서 기술이 호스팅되는 위치에 관한 모든 것입니다. 즉, 내가 말하고자 하는 "배포"하려는 기술의 호스트에 의해 실제로 제한을 받습니다(다시 말하지만 저는 이에 대한 전문가가 아닙니다). 가장 유비쿼터스한(또는 쉽게 사용할 수 있는) 호스트는 애플리케이션이 더 잘 분산/액세스 가능합니다. Annnnnd.... 당신은 내가 어디로 가고 있는지 알 것 같아요. :피

어쨌든, 실제로 우리 모두가 이 토론에 대해 _무언가_에 대해 동의하는 것처럼 느껴지며 이는 저에게 환영받는 변화/성취입니다. ;)

@galvesribeiro

UWP와 .Net Core(적어도 지금은)는 동일한 이름 아래에 있지 않습니다. 즉, 동일한 하위 수준 API를 공유하고 동일한 API 표면(및 .Net Core는 OSS인 반면 UWP는 아님)을 공유한다는 것을 의미합니다. , 그들은 같은 것이 아니며 호환되지 않습니다. 즉, .Net Core 어셈블리를 UWP 어셈블리에 추가할 수 없습니다. 이러한 차이점(IMHO)은 결국 제거되지만 현재로서는 여전히 존재합니다...

이 PR dotnet/corefx#5760을 살펴보고 몇 가지 사항이 명확해지기를 바랍니다.

UWP _is_ .NET Core의 .NET 측. 그러나 .NET Core는 여러 런타임을 제공합니다. UWP는 AOT 기반 런타임을 사용하므로 JIT가 필요한 특정 기능(예: LCG 또는 RefEmit)은 지원되지 않습니다. 그러나 동일한 어셈블리와 (앞으로) 동일한 NuGet 패키지를 공유합니다. 특히 UWP 및 ASP.NET Core에서 어셈블리(및 패키지)를 상호 참조할 수 있도록 스택을 설계했습니다.

물론, 플랫폼 집합에서 작동할 라이브러리를 구축하는 데 도움을 주는 PCL(Portable Class Library)이라고 하는 이 위에 VS 도구가 있습니다. 바이너리가 .NET Core와 호환되도록 하는 PCL 대상 지정 대화 상자에서 선택할 수 있는 여러 가지가 있습니다. 그러나 VS의 이식성은 플랫폼을 확인하여 결정되므로 해당 PCL에서 UWP를 대상으로 할 수 있다고 명시하지 않는 한 UWP 앱에서 PCL을 참조할 수 없습니다. PCL 도구는 실행해야 하는 모든 곳에서 지원되지 않는 기능을 실수로 사용하지 않도록 도와주기 때문에 이 동작은 의도적으로 설계된 것입니다. 반대로 목표로 하는 플랫폼에서만 PCL을 참조할 수 있습니다.

당신이 명시적으로 모니커를 언급했으므로 이것에 대해서도 잠시 이야기합시다. 모니커(TFM)의 디자인은 전체 표면적을 나타내는 것입니다. 우리 도구에는 두 가지 이름이 있습니다.

• TargetPlatformMonikers(TPM)
• TargetFrameworkMoniker(TFM)

TFM은 관리되는 인박스 노출 영역의 전체를 식별하는 것으로 생각하고 TPM은 기본 OS, 즉 OS에서 제공하는 API 세트를 나타냅니다.

여러 플랫폼에 이식할 수 있도록 .NET Core를 설계했기 때문에 기존 TFM은 그다지 의미가 없습니다. 이것이 바로 이전에 세대라고 하는 Standard Platform 이라는 새로운 개념이 있는 이유입니다.

도움이 되나요?

그러나 동일한 어셈블리와 (앞으로) 동일한 NuGet 패키지를 공유합니다.

대부분의 어셈블리에는 'netcore50' NuGet 대상(WINdows UWP Store App) 및 'dnxcore50' NuGet 대상(ASP.NET v5/ASP.NET Core 1.0) 애플리케이션 모두에 대해 동일한 BINARY 구현 DLL이 있습니다.

그러나 많은 System.Net.* 라이브러리 패키지와 같은 일부 NuGet 패키지는 'netcore50' 대상과 'dnxcore50' 대상에 대해 구현이 다릅니다. 예를 들어 'netcore50'이 있는 System.Net.Http 라이브러리는 아래에 WinRT Windows.Web.Http 구현을 사용합니다. 'dnxcore50' 구현은 다른 것을 사용합니다(네이티브 WinHTTP).

그러나 많은 System.Net.* 라이브러리 패키지와 같은 일부 NuGet 패키지에는 'netcore50' 대상과 'dnxcore50' 대상에 대한 구현이 다릅니다.

그래, 나는 그것을 언급했어야 했다. 내가 보기에 NuGet 패키지는 생산자가 다양한 실행 환경에 대해 서로 다른 구현을 제공할 수 있는 컨테이너를 제공하지만 소비자는 이를 알 필요가 없습니다. 그런 의미에서 NuGet 패키지는 새 어셈블리입니다.

이 더 깊은 설명과 참조 문제를 공유해 주신 @terrajobst 와 @davidsh 에게 감사드립니다. 하지만 "한 플랫폼의 1개의 어셈블리는 다른 플랫폼에서 참조할 수 없습니다"라고 말한 것이 잘못된 점은 무엇입니까?

내가 보기에 NuGet 패키지는 생산자가 다양한 실행 환경에 대해 서로 다른 구현을 제공할 수 있는 컨테이너를 제공하지만 소비자는 이를 알 필요가 없습니다. 그런 의미에서 NuGet 패키지는 새 어셈블리입니다.

이 개념은 실제로 새로운 것이 아닙니다... 사람들은 이미 "메타 패키지"라고 하는 다른 패키지에 대한 참조에 불과한 하나의 Nuget 패키지를 만듭니다. 여러 플랫폼에서 PCL이 작동하도록 하는 방법에는 여러 가지가 있습니다. 많은 인기 있는 라이브러리(예: Newtonsoft의 Json.Net)에서 가장 유명한 것은 공개 인터페이스(API 표면)와 각 특정 플랫폼(API 표면의 실제 구현)에 대한 하나의 어셈블리가 있는 너겟이 있는 Bait 및 Switch 입니다. 서로 diff 종속성을 가질 수 있으며 런타임에 해당 플랫폼에 대한 올바른 어셈블리가 선택됩니다. 이제 차이점은 단일 컨테이너 너겟 "내부"에 여러 개의 너겟이 있는 대신 모두가 동일한 플랫폼에 있어야 하거나 개발에서 방금 사용하고 런타임에 특정 것으로 전환하는 1개의 인터페이스 어셈블리에 있어야 한다는 것입니다. 그것의! 컨테이너인 1개의 너겟과 동시에 연결된 모든 플랫폼별 너겟에 대한 공개 인터페이스입니다.

같은 말을 하고 있는 것 같은데, 처음에는 내 자신을 나쁘게 표현했을 뿐이야 :스마일:

어쨌든, WF로 돌아가서... 사람들이 WF로 이식되기를 원한다는 것은 악명이 높다고 생각합니다. Linux나 Nano 서버에서 실행하는 "멋진" 이유가 아닙니다. 사람들은 클라이언트에서도 가볍게 사용하기를 원합니다.

다시 말하지만, 이 포트를 만들기 위해 커뮤니티에서 충분한 사람들이 있다고 생각합니다...

추신: 분산 컴퓨팅(오프라인 클라이언트 이야기가 아닌 실제 프로젝트)에 관심이 있는 사람들은 실제로 .Net Core의 WF에 대한 좋은 사용 사례이며 오늘날 대규모 Microsoft 서비스를 지원하는 다른 프로젝트 Orleans 를 살펴보십시오. Skype, Halo5와 같이 분산 방식으로 수십억 건의 거래를 처리하는 금융 거래 처리 플랫폼의 핵심 기술로 개인적으로 사용하고 있습니다.

@galvesribeiro

"한 플랫폼의 1개 어셈블리는 다른 플랫폼에서 참조할 수 없습니다"라고 말한 내용이 잘못된 것은 무엇입니까?

당신의 말이 틀렸다는 것이 아닙니다. 그냥 옳지 않다는 것뿐입니다 :smile: 평소에는 똑딱이를 좋아하는 스타일은 아니지만, 저를 실망시킨 것은 이 부분이었습니다.

즉, .Net Core 어셈블리를 UWP 어셈블리에 추가할 수 없습니다.

UWP와 .NET Core가 .NET Framework 및 Silverlight와 같은 다른 .NET 플랫폼이라는 인상을 주고 싶지 않습니다. 모든 플랫폼에서 작동하는 어셈블리를 작성할 수 있는 .NET Core를 특별히 설계했습니다. 예를 들어 System.Collections.Immutable 및 거의 모든 Roslyn은 .NET Core 어셈블리이며 UWP에서도 잘 작동합니다.

다시 말해서: 우리의 목표는 단순한 MSIL 기반 구성 요소가 말 그대로 모든 .NET Core 기반 플랫폼에서 동일한 바이너리를 사용할 수 있는 플랫폼을 구축하는 것입니다. 예를 들어 기본 종속성 또는 다른 구현으로 인해 이것이 불가능한 경우 Paul Betts가 Bait 및 Switch PCL 로 유창하게 설명한 대로 수행하고 있습니다. 선택자.

.NET Core 세계에서 System 라이브러리는 그다지 특별하지 않습니다. 누구나 동일한 기술을 사용하여 대부분의 소비자가 #if 지시문으로 코드 기반을 어지럽힐 필요가 없도록 할 수 있습니다.

같은 말을 하고 있는 것 같은데, 처음에는 내 자신을 나쁘게 표현했을 뿐이야 :스마일:

우리가 사람들을 혼동시키기에는 너무 쉬운 세상을 만들었다고 생각합니다. 여기에는 분명히 우리도 포함됩니다. 미소: 그렇기 때문에 .NET Core가 어떻게 구축되었고 어떤 문제를 해결하려고 노력했는지 정확히 밝히기 위해 열심히 노력하고 있습니다.

그래 네가 맞아. 인상이 중요합니다.

언젠가 UWP에서도 .Net Core를 호출하여 이 작업이 끝나기를 바랍니다... 그래서 여전히 system.xaml이 필요합니다.

관련이 있지만 System.Xaml 자체적으로 가치를 추가하는 별도의 구성 요소라고 생각합니다. 이를 별도로 추적하기 위해 dotnet/corefx#5766을 제출했습니다.

Michael-DST님, 감사합니다.

또한 Azure Mobile Services(https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/)에 대해 어떻게 생각하는지 궁금합니다. 오프라인 스토리에서 그것을 사용하는 것을 고려했다면?

훌륭한 질문입니다. 이것은 때때로 연결된 앱이라고도 하는 분산 컴퓨팅에 대한 우리 회사의 경험과 그것이 Azure Mobile Services 및 Microsoft 기술을 사용한 분산 컴퓨팅과 어떻게 연결되는지에 대한 약간의 역사 수업을 촉발합니다.

사람들이 위에 언급된 웹사이트를 보지 않았다면, 나는 그것을 보는 것을 강력히 추천합니다. Azure Mobile Services에 대한 좋은 비디오가 있습니다.

약 8년 전에 우리는 원래 Windows Phone 플랫폼용 앱을 만들었습니다. .Net Compact Framework가 포함된 구식 버전입니다. 사람들은 비웃을지 모르지만 이 플랫폼은 때때로 연결되는 기술과 관련하여 현재 UWP 플랫폼보다 더 발전된 몇 가지 핵심 사항입니다. 그러나 UWP가 따라잡고 있는 것으로 보입니다. 해당 플랫폼에서 간헐적으로 연결된 앱의 성공 비결은 다음과 같습니다.

1) 전체 SQL 데이터베이스 구현(SQL Server CE)
2) SQL Server(백엔드)와 SQL Server CE(모바일 장치) 간의 Sync Framework 구현. 이것은 Sync Framework 버전 1이었습니다.

이 앱은 성공했습니다. 우리는 최상위 SQL CE 위에 있는 데이터 계층과 서버에 배포되고 장치에 배포되는 SQL Server를 작성했습니다. 거의 최대 메모리이지만 작동했습니다. 현장 작업자는 현장에서 데이터 캡처를 수행할 수 있었고 데이터는 중앙 데이터베이스로 다시 동기화되었습니다.

Windows Phone 7이 출시되었을 때 시장에 나와 있는 모든 데이터베이스가 SQL이 아닌 데이터베이스라는 결정적인 문제가 있었기 때문에 우리는 경악했습니다. 대부분 LINQ로 구현되었습니다. 이것은 우리의 데이터 계층과 호환되지 않았고 EF는 Windows Phone 7용으로 존재하지 않았습니다. 따라서 원래의 전체 솔루션을 구축할 수 있었음에도 불구하고 Windows Phone 7용 가끔 오프라인 프레임워크를 구축할 수 없었습니다. 윈도우 폰 플랫폼.

Silverlight는 게임 체인저였습니다. 다시, 우리는 완전한 SQL 데이터베이스를 발견했습니다. 그러나 Microsoft는 Silverlight 또는 해당 인라인 데이터베이스에 대한 동기화 프레임워크를 구현하지 않았습니다. 그래서 우리는 Microsoft의 동기화 프레임워크를 모델로 한 자체 동기화 프레임워크를 작성하기 시작했습니다. Microsoft 동기화 프레임워크는 타임스탬프를 기반으로 합니다. 이것이 우리가 동기화 프레임워크에서 구현한 것입니다. 이번에도 Silverlight로 완전한 성공을 거두었습니다. 현장 작업자는 Windows 태블릿을 현장으로 가져와 데이터를 캡처한 다음 중앙 데이터베이스에 다시 동기화할 수 있었습니다. 문제는 이것이 전화에서 사용할 수 없다는 것입니다. Windows Phone 7용 데이터베이스 플랫폼이 존재하지 않았습니다.

앞서 언급했듯이 우리는 WF로 비즈니스 로직을 구현하고 싶었지만 Silverlight는 포기되었고 아무도 WF를 Silverlight로 이식할 가능성에 대해 이야기하지 않았습니다.

드디어 UWP에 도착했습니다. SQLite용 래퍼는 UWP용으로 작성되었으며 래퍼에 대한 몇 가지 해킹으로 SQLite와의 인터페이스를 확장하여 전체 SQL 데이터베이스로 다시 작업할 수 있습니다. 즉, 데이터 계층이 해당 계층과 호환됩니다. 데이터 계층 및 동기화 계층은 이제 SQL Server, SQLite 및 다른 이름 없는 데이터베이스 플랫폼과 함께 .Net, Silverlight 및 UWP에서 작동합니다.

오늘은 Michael-DST 덕분에 순수한 Microsoft 기술로 동기화되는 것을 처음 보았습니다. 기본적으로 Azure Mobile Services 동기화는 Microsoft Sync Framework의 브랜드가 변경되었다고 말할 수 있습니다. API 인터페이스가 약간 다르지만 기본 사항은 약 8년 전에 동기화 작업을 수행하는 데 사용했던 원래 Windows Phone 동기화 프레임워크와 동일합니다. 동일한 두 개의 타임스탬프 필드를 사용하여 데이터 변경 사항을 추적하는 것을 볼 수 있습니다. 이들은 SQL Server 2008의 핵심 기능으로 SQL Server에 도입되었습니다. 우리의 동기화 프레임워크는 Microsoft 동기화 프레임워크와 거의 같은 방식으로 작동합니다.

따라서 Michael의 질문에 답하기 위해 이 기술을 조사하겠습니다. 동기화 프레임워크를 대체할 수 있는지 확인하겠습니다. 버리고 다른 사람이 관리하게 하고 싶습니다. 그들이 SQLite를 지원할 것이라고 언급한 것을 보면 전체 SQL 데이터베이스를 계속 사용하기 위해 SQLite 래퍼를 해킹할 수 있고 따라서 데이터 계층을 계속 사용할 수 있기 때문에 유망하게 들립니다. 이 경우 5년 이상의 동기화 프레임워크 코드가 곧바로 휴지통에 들어갈 것입니다.

어쨌든 요점은 마이크로소프트가 분산 컴퓨팅이 중요하다는 것을 다시 한 번 인정하는 것처럼 보인다는 것입니다. 중요한 경우 WF를 UWP로 이식해야 합니다. UWP는 미래이며 따라서 Microsoft 기술을 사용한 분산 컴퓨팅의 미래이기도 합니다. 분산 기술의 미래에는 WF가 필요합니다.

관련이 있지만 System.Xaml은 자체적으로 가치를 추가하는 별도의 구성 요소라고 생각합니다. 이를 별도로 추적하기 위해 dotnet/corefx#5766을 제출했습니다.

@terrajobst 정말 감사합니다! 나는 당신이 온라인/트위터에 게시하는 모든 것에 동의하지 않지만 개발자/커뮤니티 간의 대화와 의사소통을 촉진하는 방법에 대해 열렬한 팬이며 나는 항상 그것에 동의할 것입니다. :) 이것은 MSFT에서 무엇이든 얻기 위해 오르막 스케이팅을 1년 넘게 하는 것처럼 보이기 때문에 개인적으로 정말 큰 의미가 있습니다.

따라서 Michael의 질문에 답하기 위해 이 기술을 조사하겠습니다.

멋진 @MelbourneDeveloper , 기꺼이 도와드리겠습니다! 나는 Azure가 그들의 그룹에 대해 확고한 역할을 하고 있다고 생각합니다. VSO/VSTS와 함께 그들은 개발자의 말을 정말로 듣고 *_lot *_done을 얻습니다. 사실 이것은 UWP 그룹을 제외하고 MSFT의 모든 그룹에 해당하는 것 같습니다. UWP 그룹은 실제로 많은 일을 하지 않고 자체 기술을 이해하지도 못하는 것 같습니다. "Xaml").

현재 우리는 몇 가지 핵심 서비스에 WF를 사용하고 있으며 Workflow에 대한 훌륭한 경험과 시각적이고 이해하기 쉬운 형식의 비즈니스 논리를 가지고 있기 때문에 사용을 더욱 확장하고 있습니다.

@MelbourneDeveloper 가 말했듯이

어쨌든 요점은 마이크로소프트가 분산 컴퓨팅이 중요하다는 것을 다시 한 번 인정하는 것처럼 보인다는 것입니다. 중요한 경우 WF를 UWP로 이식해야 합니다. UWP는 미래이며 따라서 Microsoft 기술을 사용한 분산 컴퓨팅의 미래이기도 합니다. 분산 기술의 미래에는 WF가 필요합니다.

많은 .NET 개발자들은 WF의 가치를 그 당시에는 보지 못했을 수 있기 때문에 WF를 과소 평가했습니다(과거에는 몰랐지만 지금은 WF가 얼마나 강력한지 이해하기 때문에 WF의 열렬한 팬입니다. be!) 하지만 분산 컴퓨팅 시대에 그 어느 때보다도 WF가 정말 빛날 수 있고 궁극적으로 포팅되기를 바랍니다.

나는 이 주제에 대해 이견이 있을 여지가 거의 없다고 생각한다.

WF와 같은 선언적 시각적 프로그래밍은 코드를 작성하는 것만큼 효율적이지 않다는 주장이 있습니다. 나는 심지어 동의하는 경향이 있습니다. 그러나 구성 가능한 플랫폼을 완성하기 위해 툴킷의 도구로 WF를 사용하는 것은 확실히 좋은 일입니다. 고객 *_DO *_는 시각적 워크플로를 보고 싶어하며 고객이 자신의 워크플로를 수정할 수 있도록 권한을 부여하는 것은 확실히 좋은 일입니다.

이 작업을 완료할 시간입니다!

나는 이 주제에 대해 이견이 있을 여지가 거의 없다고 생각한다.

ㅎㅎ @MelbourneDeveloper 소프트웨어 개발자를 만나본 적 있나요? 아니면 정말, 인류? ;피

저는 개인적으로 MSBuild 워크플로에 대해 생성된 지나치게 장황한 파일로 인해 Xaml에 이와 관련하여 잘못된 이름이 부여되었기 때문에 WF 비주얼 디자이너와 기존 도구가 XAML에 해를 끼쳤다고 생각합니다. 이것이 바로 개발자가 Xaml("비대해진 파일")과 연관시키는 것이며 "간단한" JSON 파일 및 "스크립트된" 빌드 파일로의 비행을 생성하는 데 도움이 되었습니다. 말할 것도 없이, 처음에 Xaml 파일을 보기 위해 프로젝트를 만드는 것까지 전체 신비하고 어렵고 성가신 프로세스(나는 여전히 내 프로젝트에서 완전히 작동하도록 할 수조차 없음)입니다.

사실 WF가 작동하는 방식은 항상 "올바른 방법"이었습니다. 그것의 진짜 병은 도구에 있었다.

따라서 디자이너 도구가 조금 더 친숙하다면(그리고 아마도 더 조직화되고 구분된 방식으로 파일을 직렬화하는 데 더 나은 작업을 수행했을 수 있음) 이것은 문제가 되지 않을 것입니다(또는 덜 문제가 됨).

저는 WF가 목표로 하는 경로의 열렬한 팬이지만 조금 더 조여지고 도구가 해결되고 개선되어야 합니다. 실제로, 결국 기술은 지원 도구, 즉 디자이너와 그 모든 것만큼이나 훌륭합니다. 도구/디자이너가 더 좋을수록 더 접근 가능하고 더 이해하기 쉬우며 더 나은 기술일수록 더 잘 채택됩니다.

나는 확실히 WF가 EF와 비슷해지고 모든 .NET 시나리오에서 액세스할 수 있고 도구가 이를 용이하게 하기 위해 개선되는 것을 보고 싶습니다.

내 이해에 따르면 WF의 원래 비전 중 하나는 XAML뿐만 아니라 워크플로에 대해 여러 파일 형식을 지원하는 것이었습니다. 여기 저기에 있는 몇 가지 단점 외에는 전반적으로 XAML에 문제가 없었습니다. 내 머리를 감싸고 필요할 때 수동으로 편안하게 편집하는 데 시간이 걸렸습니다. 많은 사람들에게 진입 장벽이 될 것입니다. 따라서 XAML은 이전 버전과의 호환성을 위해 유지되어야 한다고 생각하지만(최소한 단기적으로는) JSON과 같은 다른 워크플로 파일 형식이 개발되기 시작하는 것을 보고 싶습니다. 전면에서 멋진 커뮤니티 기여를 볼 수 있었습니다! ( 공백 으로 작성된 워크플로는 누구인가요? :smile: )

@Michael-DST 전적으로 동의합니다. 최근에 저희 팀과 저는 Workflow에 대한 좋아요/싫어요/희망을 검토하고 있었고 개선되기를 바라는 거의 모든 것이 디자이너 주변에 있었으며 반드시 핵심 WF 자체는 아닙니다. 저는 Microsoft가 WF에서 구축한 기능으로 환상적인 일을 해냈다고 생각하며 몇 가지 개선 사항과 새 생명을 불어넣은 전도를 볼 수 있다고 생각합니다. 나는 그것이 존재해야 하는 도구라고 생각하고 WF에서 많은 가치를 얻었고 그것이 오랫동안 지속되는 것을 보고 싶습니다.

우리 기업은 WF에 상당한 투자를 했으며 이제 우리 비즈니스의 중추적인 기술이 되었습니다. 오픈 소스 및 .NET Core에 대한 MIcrosoft의 최근 약속을 감안할 때 WF 포팅은 이 기술을 위한 최선의 다음 단계로 보입니다. 우리는 이것이 필요합니다!

워크플로는 조직 내 개발자인 우리에게 많은 이점을 제공하는 도구였습니다. Microsoft가 프레임워크를 통합한다면 핵심 프레임워크에 WF를 포함하는 것이 우리의 삶을 더 쉽게 만들 것입니다.

ㅎㅎ @MelbourneDeveloper 소프트웨어 개발자를 만나본 적 있나요? 아니면 정말, 인류? ;피

하하 저는 소프트웨어 개발자입니다. 인류는 나에게 하찮은 존재다.

마이클 DST

저는 개인적으로 MSBuild 워크플로에 대해 생성된 지나치게 장황한 파일로 인해 Xaml에 이와 관련하여 잘못된 이름이 부여되었기 때문에 WF 비주얼 디자이너와 기존 도구가 XAML에 해를 끼쳤다고 생각합니다. 이것이 바로 개발자가 Xaml("비대해진 파일")과 연관시키는 것이며 "간단한" JSON 파일 및 "스크립팅된" 빌드 파일로의 비행을 생성하는 데 도움이 되었습니다.

당신이 아마 옳을 것입니다. 하지만 저는 개인적으로 여기에서 Xaml을 너무 강조하고 있다고 생각합니다. WF를 시도했을 때(Silverlight에 존재하지 않기 때문에 사용할 수 없다는 것을 깨닫기 전에) 저는 WPF 앱을 만들었습니다. 해당 앱은 WCF 서비스에 연결하고 WF용 Xaml을 데이터베이스의 테이블에 저장했습니다. 이것이 WF의 소프트 코딩을 달성한 방법입니다.

그러나 Xaml은 WPF WF 디자이너 도구를 사용하여 완전히 조작되었습니다. 사용자는 Xaml을 본 적이 없습니다. xaml은 사용자와 관련이 없습니다. 웹 페이지 뒤에 있는 HTML 마크업과 같다고 생각하십시오. 매우 복잡할 수 있지만 최종 사용자가 웹 페이지를 좋아하는 한 실제로는 중요하지 않습니다. Xaml을 텍스트로 직접 조작하는 경우 어쨌든 의도한 방식으로 WF를 사용하고 있지 않다고 생각합니다...

인류는 나에게 하찮은 존재다.

멋진. 비)

그러나 Xaml은 WPF WF 디자이너 도구를 사용하여 완전히 조작되었습니다. 사용자는 Xaml을 본 적이 없습니다.

옳은. 이것이 바로 MSBuild가 작동하는 방식이며 최종 사용자는 생성하는 파일의 크기 때문에 이를 싫어합니다(특히 매우 기본적이고 선형적인 간단한 "스크립트" 파일과 비교할 때). 나는 이것이 툴링/디자이너의 문제라는 데 동의하며 WF로 툴링/디자이너를 크게 개선할 수 있다고 말하고 싶습니다.

요점: 블로그 게시물 및 코드 복사/붙여넣기(또는 실제로는 _workflow_:smile: 복사/붙여넣기). 온라인에서 WF를 검색한 적이 여러 번 있었고 워크플로 구성 요소(대부분 MSBuild의 경우)를 추가하기 위해 수행해야 할 몇 가지 단계를 보여주는 멋진 블로그 게시물을 발견했습니다. 글쎄, 이것을 하기 위해서는 기본적으로 많은 단계를 복제해야 했습니다. 일반적으로 코딩 블로그 게시물에서 코드는 간단한 복사/붙여넣기에 사용할 수 있습니다. WF에서는 그렇지 않습니다. 블로그 게시물에서 보이는 것과 정확히 같은 방식으로 컴퓨터에서 보일 때까지 단계별로 수행해야 합니다. 이것은 분명히 매우 지루하고 오류가 발생하기 쉽습니다.

MSBuild에서 만난 또 다른 문제는 바이트 단위뿐 아니라 디자이너 자체의 파일 크기입니다. 복잡한 워크플로를 탐색하는 것은 정말 어려웠습니다. 이것은 매우 포괄적이고 직관적인 방식으로 설명되어야 하는 것처럼 보입니다.

마지막으로 파일 크기 문제를 마무리하고 싶습니다. 예전에 WordML 및/또는 MSFT Frontpage에 대해 알고 있는지 잘 모르겠습니다. 그러나 그것은 세계에서 가장 부풀려진 HTML을 만들 것입니다. 사용자는 일반적으로 결과 마크업에 손을 넣지 않지만 얼마나 "깨끗한"지 느끼기 위해 코를 넣고 싶어합니다. 그들이 보는 첫 번째 것은 디스크의 크기이고 두 번째로 파일을 열어 형식 등을 확인하는 것입니다.

다시 말하지만, 나는 이 파일이 어떻게 만들어지는가가 전적으로 도구/설계자의 문제라는 데 동의하지만, 개발자들은 호기심을 갖게 되며 이 또한 고려되어야 합니다. :)

예. 모든 좋은 점. 그런 장황한 Xaml을 생성하지 않도록 디자이너가 정리해야 한다고 생각합니다.

WF가 .Net Core 또는 UWP로 이식되는지 여부를 결정할 권한이 실제로 누구에게 있습니까? 어딘가에 코드를 작성한 다음 해당 패치를 .Net Core 코드베이스 리포지토리의 관리자에게 제출하는 개발자의 경우입니까? 이를 둘러싼 정치는 무엇인가? 마이크로소프트의 영향을 받는 핵심 개발자 팀이 있지 않습니까? 마이크로소프트 직원입니까? 나는 아직도 전체 설정을 이해하지 못한다. 우리는 누구를 설득해야 합니까?

실제로 @MelbourneDeveloper 는 이 스레드에 참여하는 것만으로도 주장을 하는 데 도움이 됩니다. 현재 내 소유인 WF를 소유한 MS 팀이 있지만 Core에서 WF를 출시하기로 결정하지는 않았습니다. 우리는 비즈니스 사례를 만들어야 합니다. 여기에 있는 토론이 그렇게 하는 데 도움이 됩니다.

사람들이 이 스레드를 지원하는 2016년을 시작한 방법은 실제로 인상적입니다. :)

또한 @terrajobst 의 https://github.com/dotnet/corefx/issues/5766은 요즘 더 바빠졌습니다 :)

@dmetzgar 나는 당신이 OSS를 위해 충분한 경우를 가질 수 있도록 당신이 그 토론에서 할 수 있는/필요한 만큼 많은 피드백을 얻기를 바랍니다.

dotnet/WF repo가 ​​corefx에 추가되면 열리면 사람들이 확실히 빠르게 성장할 것이라고 확신합니다.

실제로 @MelbourneDeveloper 는 이 스레드에 참여하는 것만으로도 논쟁을 만드는 데 도움이 됩니다.

그래서 그런지 따뜻하고 포근한 느낌이 듭니다.

참고로 dmetzgar - 저는 우리의 경험을 문서화하고 항구 비즈니스 사례에 대한 증거를 구축하는 데 도움이 되는 설득력 있는 사례를 제출하게 되어 기쁩니다.

저는 2000년부터 Microsoft 기술에 대해 무지했습니다. 이 스레드와 관련된 모든 주요 기술이 발전하고 사라지는 것을 지켜봤습니다. 저는 Microsoft 기술에 몰두하고 있지만 여전히 객관적인 관점에서 기술을 보고 있으며 WF가 .Net Core 및 Windows UWP 플랫폼에 대한 비즈니스/정부의 구매를 개발하는 데 도움이 될 핵심 기술 중 하나라고 생각합니다.

순서도보다 고객을 더 흥분시키는 것은 없습니다! 아무것도!

나는 또한 마이크로소프트 기술이 거대한 것의 정점에 있다고 말해야 한다.

수년 동안 나는 좋은 기술이 오르고 내리는 것을 지켜왔습니다. 기술이 곁길로 빠진 주된 이유는 변화하는 장치 환경 때문입니다. 과거에는 각 장치 제품군에 대한 플랫폼을 구축하는 것이 전략이었습니다. 이 접근 방식에는 본질적으로 잘못된 것이 없었습니다. 하지만 이는 플랫폼 간의 기술 이식을 의미합니다. 이는 번거로운 일이며 플랫폼이 갑자기 입맛에 맞지 않게 되기 때문에 기술이 중단되는 것은 드문 일이 아닙니다(기침 - Silverlight).

Microsoft는 이제 .Net Core와 UWP를 지원하고 있습니다. 이 두 플랫폼은 하나이고 동일해야 한다고 생각하지만 주어진 기술이 만들어지거나 유지 관리되면 여러 플랫폼에서 작동할 것이라고 여전히 낙관합니다. Xamarin은 내 낙관주의를 더욱 강화합니다.

역사상 처음으로 우리는 매우 광범위한 CPU와 운영 환경에서 작동하는 기술 모음을 멍하니 바라보고 있는 것 같습니다. Microsoft가 이를 강력하게 추진한다면 WF가 그 일부가 될 것입니다.

그래서 그런지 따뜻하고 포근한 느낌이 듭니다.

:+1: @MelbourneDeveloper 와 @dmetzgar에서. 이것은 내가 개인적으로 MSFT에서 보기를 좋아하는 일종의 참여와 대화입니다. 열정적인 기반( 즉, 비열한 사람 )의 무시된 탄원 과 응답되지 않은 전화 가 아닙니다.

여기에서 무작위로 제쳐두고: NodeJS가 당신이 필요로 하는 유일한 비즈니스 사례/위협이라는 점에서 최근에 우연히 보게 된 기사 입니다.

마지막으로, ".NET Core가 EF에 충분하다면 WF에도 충분해야 합니다."라는 내 관점에서 ... WF가 .NET Core로 이동했다면 EF가 서비스를 제공할 수 있도록 EF와 통합하는 방법이 있습니까? 어떻게 든 백엔드로? 그렇다면 그것은 바로 거기에 설득력있는 경우입니다. 그렇지 않은 경우에도 생각해 볼 가치가 있습니다(토론/대화/브레인스토밍/기타 참조). :)

마지막으로, ".NET Core가 EF에 충분하다면 WF에도 충분해야 합니다."라는 내 관점에서 ... WF가 .NET Core로 이동했다면 EF가 서비스를 제공할 수 있도록 EF와 통합하는 방법이 있습니까? 어떻게 든 백엔드로? 그렇다면 그것은 바로 거기에 설득력있는 경우입니다. 그렇지 않은 경우에도 생각해 볼 가치가 있습니다(토론/대화/브레인스토밍/기타 참조). :)

흥미로운 생각입니다. EF와 WF를 통합하는 사용 사례는 무엇입니까? 예를 들어주실 수 있습니까? 이것은 지속성을 위한 것인가?

예를 들어주실 수 있습니까? 이것은 지속성을 위한 것인가?

최소한 애플리케이션 도메인에서 워크플로가 작동하는 지원 모델로 사용할 수 있다는 것입니다. 기껏해야 실제로 워크플로 자체의 저장 메커니즘 역할을 할 수 있습니다(하지만 권장하지 않습니다. Xaml이 훨씬 더 적합합니다).

여기에서 Xaml에서 워크플로를 정의한 다음 EF에서 정의, 수정 및 저장된 모델 엔터티의 데이터를 사용하여 워크플로 요소의 속성에 바인딩할 수 있는 WPF-esque 패러다임을 볼 수 있습니다.

물론, WF에 대한 내 경험은 여기에서 제한됩니다(폭넓은 경험이 있는 사람들은 여기에서 차임할 수 있음). 그러나 WPF에서 작동했다면 WF에서도 작동할 수 있습니다. 사실, 나는 현재 프로젝트에 사용하는 콘솔 응용 프로그램 에 대해 이와 동일한 패러다임(즉, WPF-esque Xaml 기반 개발)을 사용합니다. 물론 (아직) 내가 제안한 대로 데이터 바인딩을 사용하지 않지만 OmniXaml/Perspex에서 보여주듯이 데이터 바인딩은 쉽게 생성됩니다. :색안경:

@Michael-DST 너무 많은 통합을 피하고 싶습니다. WF는 독립 실행형 NuGet 패키지여야 합니다. WF와 EF를 함께 통합하는 것은 별도의 프로젝트여야 합니다. 너무 많은 것들을 결합하기 시작하면 결국 오슬로 가 될 수 있습니다.

나는 @dmetzgar 에 동의합니다 :+1:

EF는 스토리지/지속성 제공자입니다. diff NuGet 패키지여야 하며 런타임에 주입되어야 합니다. WF는 인터페이스 집합만 제공해야 하며 그게 전부입니다.

우리는 Microsoft Orleans의 Storage Providers와 함께 아주 잘 해냈습니다.

@dmetzgar (및 @galvesribeiro)가 동의했습니다. 나는 필수 통합을 제안하는 것이 아니라 가능한 사용 사례/가치 제안을 제안합니다. (참조: 브레인스토밍. :스마일:)

EF와 WF를 통합하는 사용 사례는 무엇입니까? 예를 들어주실 수 있습니까? 이것은 지속성을 위한 것인가?

나는 이것에 차임하고 싶다! 다시 말하지만, 이것은 우리 회사의 경험과 관련이 있습니다. 궁극적으로 우리는 가끔 연결되는 앱에 대해 SQLite와 같은 인라인 데이터베이스의 데이터 지속성을 위해 EF를 사용하고 싶습니다. 궁극적으로 UWP/.Net Core에는 EF, SQLite, Azure Mobile Services 및 WF가 모두 조화롭게 작동합니다. 왜 이런 일이 일어나길 원하는지 설명한다면 스스로 반복하겠지만, EF와 WF가 함께 잘 작동하는 이유는 설명할 수 있습니다. 하지만 EF에서 과거에 우리를 멈춘 한 가지 제한 사항을 발견했습니다. 이것이 바로 우리가 자체 ORM을 만들어야 하는 또 다른 이유입니다.

데이터 액세스가 "BeforeLoad", "BeforeSave" 등과 같은 이벤트를 트리거하는 시스템이 있습니다. 이러한 이벤트에 후크를 남겨두어 주어진 레코드 유형이 저장될 때 거기에 사용자 정의 비즈니스 로직을 넣을 수 있습니다. 현재 우리는 사용자 정의 비즈니스 로직 DLL에 연결하여 이를 수행했습니다. 각 고객에게는 고유한 사용자 정의 이벤트 세트가 있습니다. 또한 WF에 대한 호출을 구현했습니다. 따라서 예를 들어 BeforeSave 이벤트에서 필수 필드의 유효성을 검사하는 WF를 호출하여 일부 유효성 검사를 수행할 수 있습니다. 이러한 방식으로 유효성 검사 논리는 주어진 고객에 대해 소프트 코딩되었습니다. 장기적으로 WF는 Silverlight에서 구현되지 않았기 때문에 이 목적을 위해 WF를 포기해야 했지만 옵션으로 포함했으면 좋았을 것입니다.

어쨌든 이것은 모든 앱에 대한 상당히 보편적인 요구 사항이라고 생각합니다. 일반적으로 말해서, 데이터베이스로 들어가는 데이터의 유효성을 검사하거나 일반적인 비즈니스 로직을 수행하는 데이터 계층 바로 위에 항상 계층이 필요합니다. 예를 들어, 특정 유형의 레코드가 데이터베이스에 추가될 때 이메일을 보내는 일부 고객에 대한 비즈니스 논리가 있습니다. 이것은 WF에서 수행할 수 있습니다. EF와 WF가 조화롭게 작동하여 이와 같은 것을 구현하는 것이 좋을 것입니다.

아아, .Net에서도 EF로 이 작업을 수행하는 방법을 찾지 못했습니다. 내가 찾은 문제는 EF가 주어진 유형의 레코드가 저장되려고 할 때 알려주지 않는다는 것입니다. 예를 들어 새 "Task" 개체를 만들고 EF를 사용하여 데이터베이스에 유지하면 "RecordInserted"와 같은 이벤트가 EF에서 발생하지 않습니다.". 이렇게 하면 맞춤형 비즈니스를 삽입할 수 있도록 데이터 액세스에 대한 후크를 구축할 수 있습니다. 따라서 이것이 우리가 EF를 사용하지 않은 이유 중 하나입니다. 자체 ORM을 구축하는 데 몇 년이 걸렸기 때문에 유감입니다.

NodeJS의 "비즈니스 사례"에 대해 말하기: NodeJS가 3가지 쉬운 차트에서 .NET을 지배하는 방법

그 GitHub 저장소를 참을성 있게 기다리고 있습니다. WF가 .NET Core로 이식되지 않아 우리 제품에 대한 실행 가능성이 거의 사라졌다는 것을 방금 깨달았습니다. ASP.NET Core에 대한 변경 사항과 .NET Core의 전체 플랫폼 간, 슬림형, 모듈식 아이디어를 좋아하지만 전체 제품의 기초인 WF가 필요하기 때문에 이는 부끄러운 일입니다.

솔직히 이것이 WWF인지 또는 다른 잘 지원되는 워크플로 엔진인지는 별로 신경 쓰지 않지만 확장성을 위해 일종의 워크플로가 절대적으로 거대할 수 있다고 생각합니다.

+1

동적 생성(가져온 외부 규칙 기반)과 워크플로 로드를 WCF 서비스로 사용했습니다. .net 코어에서 그러한 모델을 사용할 수 있다면 정말 좋을 것입니다!
BTW - 전체 .Net의 어셈블리를 가져올 때의 문제는 무엇입니까? 대부분 IL 코드인 경우 .net 코어에서 실행되지 않는 이유는 무엇입니까?

+1

@dmetzgar https://github.com/dmetzgar/corewf를 보니 정말 신기합니다! readme에서 WF 팀의 포트가 그다지 주목을 받지 못했다는 사실에 놀랐습니다. 특히 전체 프레임워크로 제한되는 Powershell Workflow가 있는 최근 Powershell 포트를 고려할 때 Linux와 Mac은 분명히 주요 대상이 아니지만 Nano 서버는 Powershell에 매우 중요하다고 생각합니다. 또한 Portable.Xaml과 같은 다른 Xaml 구현을 포함하는 XAML의 대안을 탐색하고 있다고 언급되어 있습니다. 예를 들어 CoreCLR과 호환되는 Profile 259를 이미 지원합니까?

@watertree Portable.Xaml 및 내가 지금까지 본 .NET Core 지원을 포함한 기타 XAML 구현에는 모두 누락된 기능이 있습니다. x:Class="" 속성을 구현하지 않습니다. WPF에는 필요하지 않지만 WF에는 중요합니다. XAML 워크플로에는 일반적으로 다음이 있습니다.

PowerShell Workflow에는 스크립트에서 워크플로를 정의하는 정말 좋은 방법이 있습니다. XAML이나 C#으로 같은 것을 작성하는 것보다 훨씬 깔끔합니다. 그러나 PSWF는 해당 스크립트를 백그라운드에서 XAML 파일로 변환합니다. PSWF가 Nano에서 작동하려면 XAML을 사용하지 않도록 기존 파이프라인과 WF 런타임을 교체해야 합니다. 그리고 고객이 Nano에 PSWF를 설치해야 한다는 압력이 충분하지 않습니다.

XAML에 대한 대안과 관련하여 이에 대해 많은 의견이 있습니다. XAML에 대한 내 문제는 WF에 포함되어 있다는 것입니다. .NET 3.5에서 릴리스된 이전 WF에서는 원하는 형식을 워크플로로 변환하도록 WF 팀에서 더 많은 격려를 받았습니다. Visio 다이어그램을 워크플로로 변환하는 예를 사용했습니다. 그러나 새로운 WF가 4.0에 도착했을 때 모든 것이 XAML에 집중되었습니다. XAML에서 손으로 워크플로를 작성해 본 적이 있습니까? 발생하지 않습니다. 그런 다음 디버그 기호와 viewstate가 있습니다. 그리고 diffing 도구를 사용하여 한 버전의 XAML을 다른 버전과 비교해 보십시오.

XAML을 사용하여 워크플로를 정의하는 것은 NuGet 패키지를 포함하는 문제여야 한다고 생각합니다. 워크플로 정의를 저장하는 다른 방법을 만드는 것이 좋습니다. 압축이 잘 되는 무언가가 필요할 수도 있습니다. 보안이 필요하고 제한된 활동만 허용할 수 있습니다. 옵션이 있는 것을 선호합니다.

x:Class="" 속성을 구현하지 않습니다.

실제로 컴파일된 Xaml(baml?)은 내가 본 모든 Xaml 풍미에서 눈에 띄게 없었습니다. 나는 내 여가 시간에 이것에 뛰어드는 것에 대해 생각해 보았지만 아마도 내년에 곧 어느 정도 사용할 수 있을 것이라고 생각합니다. 또한 Xamarin의 Xaml 시스템은 이를 지원하지만 폐쇄적이며 확장/액세스가 전혀 불가능합니다.

XAML에서 손으로 워크플로를 작성해 본 적이 있습니까? 발생하지 않습니다.

진실. 아이러니하게도 WF는 모든 Xaml 통합의 가장 포괄적인 후원자입니다. 잘못에, 아마도. Xaml이 매우 디자이너 친화적이도록 제작되었지만 WF 주변 도구는 손으로 작성한 시나리오와 디자이너 자체에 대해 약간 금지되어 있다는 것은 유감스러운 일입니다. 그들은 그것을 시각적 프로그래밍 언어로 만드는 것을 정말로 목표로 삼았지만 상당한 양의 지원/자원 없이는 성공해야 할 것입니다.

XAML을 사용하여 워크플로를 정의하는 것은 NuGet 패키지를 포함하는 문제여야 한다고 생각합니다.

나는 당신이 어떻게 생각하는지 좋아! 👍

BTW, 아직 하지 않았다면 System.Xaml 포트 요청/문제로 이동하고 가능한 경우 문제에 찬성 투표를 하십시오. 저는 알려진 모든 시스템을 최대한 활용하고 하나의 공식적이고 권위 있는 풍미를 제공하는 새로운 오픈 소스, 크로스 플랫폼 Xaml 시스템을 보고 싶습니다. 좋지 않겠습니까? 😛

어쨌든 지금은 최대 74표입니다. GitHub 반응을 사용할 수 있기 전에 투표가 시작되었다는 점을 고려하면 꽤 굉장합니다.
https://github.com/dotnet/corefx/issues/5766

17하트도 이쁘네요. :)

지원(및 지속적인 피드백)에 감사드립니다!

@dmetzgar 수고해주셔서 감사합니다! XAML에 대해 언급하십시오. 저는 XAML에 대해 매우 부정적인 견해를 가지고 있었습니다. 왜냐하면 제가 처리한 대부분의 파일은 XAML의 시각적 디자이너 우선 방언으로 생성되었기 때문입니다.

XAML 외에도 매우 멋진 선언적 C# API가 있는 Xamarin.Forms로 프로그래밍을 시작했을 때 모든 것이 바뀌었습니다. 비주얼 디자이너는 없습니다(XF 릴리스보다 훨씬 늦게 나온 프리뷰어만 있음). 놀랍게도 저는 C# 코드보다 XAML의 방언으로 작업하는 것을 훨씬 선호합니다! 그들은 그것을 아주 훌륭하게 해냈고 마크업의 의미를 오염시키는 디자이너 메타데이터가 많이 없습니다. Prism.Forms와 같은 프레임워크를 지원하면 코드 숨김 없이 코드를 작성하는 것이 매우 쉽기 때문에 XAML로 확장하는 데 도움이 됩니다.

따라서 XAML 자체가 문제라고 생각하지 않지만 먼저 디자이너를 지원하도록 설계된 방언이 있습니다. XF는 저에게 꽤 설득력 있는 증거입니다.

해당 주제에 대한 업데이트가 있습니까?

CoreWF는 살아 있고 https://github.com/dmetzgar/corewf 에 존재합니다.

이제 DynamicActivity가 core 및 .net 표준 2.0에 추가된 새 구성 API로 이식될 수 있는지 확인해야 합니다.

우리가 WF 팀으로부터 듣게 된다면 좋을 것입니다.

이 주제에 대해 흥미롭고 유용한 의견이 많이 있습니다. 제 생각에는 WF 런타임과 이벤트 추적(즉, XAML, 트랜잭션 또는 WCF 비트 없이)이 .NET Core로 이식되는 것만으로도 가치가 있다고 믿으며 이것이 (일종의) 완료되어 기쁩니다.

WF.Core가 공식적으로 존재해야 한다는 데 동의합니다. 개발자에게 적합한 워크플로를 보다 유연하게 정의할 수 있는 기능이 있다면 그것이 최선의 접근 방식일 것이라고 생각합니다. MS가 System.XAML을 이식하지 않을 것이라고 말하면 XAML이 크랙하기 어렵다는 데 동의하지만 .NET Core Web API 프로젝트에서 WF.Core를 보고 싶습니다.

여기 있는 거대한 코끼리는 MS와 다른 사람들이 WF에 대한 정보에 대해 입을 다물고 있기 때문에 이 프로젝트를 시작하기에 충분한 견인력이 없다는 것입니다. 물론 MSDN에 몇 가지 샘플이 있지만 책이나 기타 견고한(검토된) 자료 형태의 정보는 거의 없습니다.

나는 이것을 실현하는 데 시간을 할애할 용의가 있습니다.

따라서 아직 개발 중인 OmniXAMLv2(github repo의 분기에 있음)는 x:Class 속성(https://github.com/SuperJMN/OmniXAML/issues/12)을 지원해야 합니다. (Core)WF에 사용할 수 있습니까?

@ewinton 지적해주셔서 감사합니다!
그것은 확실히 큰 덩어리입니다. 또한 .NET Standard 2.0에는 WF에서 사용하는 System.ComponentModel 유형이 많이 있습니다. System.Transactions는 이미 corefx에 있습니다. 누락된 것은 WCF ServiceHost뿐입니다.

WCF ServiceHost는 IMHO를 기다릴 수 있습니다. 호스팅 모델은 .Net Core/Asp.Net 세계의 다른 것과 마찬가지로 불가지론적이어야 합니다.

@galvesribeiro 나는 Web API를 포함하여 WF가 .NET Core 세계에서 작동할 수 있는 다른 많은 방법이 있다는 사실을 감안할 때 이에 동의합니다.

예. 그러나 오늘날 WCF를 사용하는 많은 고객이 있으므로 지원하는 것이 필수이지만 다시 지연될 수 있다는 @dmetzgar 의 의견에 동의합니다.

사실 호스팅과 "디자인 언어"는 핵심 런타임에서 추상화되어야 합니다...

우리는 WF와 함께 WCF를 사용하지만 WF가 Core에 있다면 WebAPI와 같은 것으로 기꺼이 전환할 것입니다. 사실 우리는 WCF에서 RESTful 대안으로 계속 나아가고 있습니다. 우리는 Workflow에서 많은 가치를 얻었고 이는 제가 가장 좋아하는 .NET 기술을 기반으로 합니다!

나는 또한 코어의 WF가 xaml이나 wcf에 의존할 필요가 없어야 한다고 생각합니다. wf 엔진과 개체 모델만 있으면 매우 가치가 있을 것입니다. 그런 다음 특히 kestrel에 제공되는 새로운 파이프라인/비 http 작업과 함께 asp.net 코어에서 미들웨어로 실행합니다.

Core에서 WF 엔진 및 개체 모델을 보유하고 지원하는 데 +1입니다. XAML 및 WCF도 해결할 수 있습니다.

XAML은 훌륭합니다. 동적 구성을 만들 수 있습니다. 한 프로젝트에서 파일에서 xaml 워크플로를 로드하고 WCF 끝점으로 표시됩니다. 그리고 이러한 XAML 파일은 사용 가능한 서비스의 레지스트리에서 자동 생성됩니다. 따라서 wcf-services는 끝점을 얻습니다.
https://[base]/wcf/[service_id1]
https://[base]/wcf/[service_id2] ...
.Net 코어에 이러한 기능이 있으면 좋을 것입니다. :)
아..전에도 여기다 쓴적이 있는데... :)))

예, 여기에서 더 익숙해지면서 WF의 Xaml 지원은 그 자체로 중요하지 않지만 오히려 System.Xaml을 이식하는 것이 중요한 부분입니다. 그것이 다른 기사에 명확하게 포착 되었기 때문에 -- 그리고 나는 꽤 인기가 있다고 말하게 되어 매우 기쁩니다 (그러나 그것이 당신이 찬성하는 것을 막지 못하게 하십시오, @freerider7777! :smile:) -- 문제, 저는 WF를 종속성으로 만드는 것을 지지합니다 .NET Core에 들어갈 수 있도록 가능한 한 무료입니다. 👍

@Mike-EEE 오래전에 거기 찬성했어요!! :)

코드를 통해 워크플로를 만들 수 있다는 점을 감안할 때 EF Core와 유사한 Fluent API를 사용하는 것이 WF Core에 생명을 불어넣는 데 유효한 옵션이 될까요? 그런 다음 런타임에 대한 직렬화/역직렬화를 나중에 구성할 수 있고 훨씬 더 쉽게 구현할 수 있습니까?

FluentAPI는... 지금 매우 뜨겁습니다. 또는 적어도 그들이 도입된 이후로. 😄

FluentAPI, Builder Pattern, 둘 다 본질적으로 동일합니다. 연결 가능하고 사용하기 쉬운 코드 기반 방식을 제공하는 것이 이 이면의 견고한 원칙이어야 한다고 생각합니다.

디자이너가 없으면 아무 소용이 없습니다. 물론 우리는 모든 것을 스스로 코딩할 수 있습니다. 모든 논리, 모든 사슬 등(유창하거나 없는). 그러나 WF의 멋진 점은 처리 흐름을 시각적으로 볼 수 있다는 것입니다. 관리자(및 기타 '이해관계자')와 개발자 간의 연결 고리입니다! 관리자는 코드를 이해하지 못하지만 이러한 높은 수준의 다이어그램은 모두가 이해할 수 있습니다. WF를 사용하면 분리된 경우 별도의 다이어그램(visio 또는 기타)이 필요하지 않습니다. 일반적으로 실제 코드와 동기화되지 않습니다. :)

@freerider7777 WF 정의 직렬화는 xaml에 국한되지 않습니다( @dmetzgar 의 https://github.com/dmetzgar/corewf 참조). JSON용으로도 구현할 수 있습니다. 그러면 NodeRed http://nodered.org/ 와 같은 기존 프로젝트를 통합/포크할 수 있는 가능성이 열립니다. 이는 여러 면에서 WF Designer 기능 및 UX와 유사합니다(+ 웹 브라우저에서 WF의 새로운 사용 사례 열기)

WF를 .NET Core뿐만 아니라 .NET Standard로 이식하는 것이 가장 좋습니다. 이전에 링크된 WF 런타임은 이미 .NET Standard 1.3에서 작동합니다(WriteLine 활동을 삭제하면 더 낮아질 수 있음). 곧 2.0 표준이 나오면서 자동 캐시 메타데이터, DynamicActivity 및 트랜잭션 범위와 같은 많은 기능 격차를 채울 수 있습니다. 요금제 모델이 있도록 구성 요소를 다른 패키지로 분리해야 합니다. 런타임만 원하면 1.3 표준을 고수할 수 있지만 DynamicActivity를 원하면 2.0 표준이 필요하고 플랫폼을 제한해야 합니다.

WF 런타임 코드에는 확실히 개선할 여지가 많습니다. 예를 들어 활동 확장을 종속성 주입으로 대체합니다. Fluent API는 코드로 워크플로를 작성하는 데 흥미로울 것입니다(이 라인을 따라 @knat의 https://github.com/knat/Metah 참조). 그러나 다이어그램을 사용하여 경영진 및 BA와 통신할 수 있다는 @freerider7777 에 동의합니다. 실제로 생산에 사용되는 것으로부터 생성된다는 것은 큰 장점입니다. @helmsb 는 이에 대한 많은 경험이 있습니다(http://dotnetrocks.com/?show=1236 확인).

새로운 디자이너는 웹 애플리케이션이어야 합니다. WPF 또는 UWP를 대상으로 하면 대상이 제한됩니다. OmniXAML이 실행되면 사람들은 오늘날과 동일한 도구(VS 또는 재호스팅된 솔루션)를 사용하여 워크플로를 생성/편집할 수 있습니다. 문제는 현재 디자이너가 .NET Framework에 내장되어 있기 때문에 모든 기능이나 수정 사항이 .NET Framework 릴리스를 기다려야 한다는 것입니다. 시작하기에 충분하지만 장기적인 해결책은 아닙니다. @erikcai8 은 nodered와 유사한 웹 디자이너로 몇 가지 실험을 했습니다. 공유하도록 설득할 수 있는지 알아보겠습니다.

워크플로 디자이너 프런트 엔드의 경우 github: https://github.com/gary-b/WF4JSDesigner 에서 사용할 수 있는 첫 번째 시도가 있으며 http://gary-b.github.io/WF4JSDesigner/ 에서 라이브로 사용할 수 있습니다.

이것은 이미 다음과 같습니다.

@ewinton : 웹 워크플로 디자이너 POC를 만나서 반갑습니다. 아래 스크린샷과 같이 또 하나를 만들었습니다.

꺄오오오오오오오오오오오오오오오오오오오오오오오오오오오오오오오오오옹!!! WF POC-OFF입니다!!! 🎉

헤헤. @erikcai8 Xaml로 내보내기는 어디에 있습니까??? ㅋ. 슬픔을 뒤집을 뿐입니다. 정렬. 👼

두 가지 노력 모두 훌륭해 보입니다. 둘 다 보기 좋습니다. 지금은 이것이 당연해 보이지만 원래 WF에 웹 기반 비주얼 디자이너가 있었다면 얼마나 좋았을까요? 모든 것이 잠기고 로드되며 사용할 준비가 되었습니다. URL을 방문하기만 하면 됩니다. 브랜딩과 채택에 큰 도움이 될 것이라고 생각합니다. 불행히도 모든 사람이 설정하기가 매우 어렵고 장황한 Xaml로 이어진 TFS 기반 편집기에 착륙한 것 같습니다. 이것은 그것을 처리해야 하고 경험(WF 또는 Xaml)과 관련하여 나쁜 이름을 부여해야 하는 일반적인 개발자에게는 좋지 않은 경험이었습니다.

OTOH는 훌륭한 접근 방식인 것 같습니다. 르네상스를 시작하자!

@Mike-EEE 내 E2E 실험은 XAML 형식이 필요하지 않도록 기본적으로 JSON 워크플로를 로드하도록 워크플로 코어 엔진을 향상했습니다. JSON 워크플로를 로드하면 XAML 워크플로를 Workflow Engine에서 내보낼 수 있습니다.

그것이 핵심이야. 런타임과 해당 개체 모델을 WF 4.5에서와 같이 디자이너 및 직렬화된 형식에 연결해서는 안 됩니다.

@galvesribeiro 요점을 이해했습니다. 실험에서는 JSON 형식이 Workflow Core의 또 다른 옵션으로 지원된다고 가정했습니다. 위에서 논의한 바와 같이 XAML은 아직 최신 웹 기술에 적합하지 않습니다.

우리는 WF를 좋아합니다. .NetCore로 이식하세요.

웹 기반 워크플로 디자이너가 필요합니다. 워크플로를 실행하기 위한 .NET Core 지원은 두 배로 굉장할 것입니다. 가다

Daniel Gerlag는 여기에서 정말 멋진 경량 코어 호환 워크플로 엔진을 작업하고 있습니다.

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

Daniel's는 매우 짧은 기간에 먼 길을 왔습니다. 이 프로젝트를 보시고 장점이 있다면 적극 동참해 주셨으면 합니다.

이 모든 관심과 함께 Net Core 호환 엔진을 처음부터 구축하지 않는 이유는 무엇입니까?

@ccpony 지금 바로 dot net core에서 CoreWF를 사용할 수 있기 때문에 -> https://github.com/dmetzgar/corewf . 중앙 구성 요소가 이식되어 작동합니다. 몇 가지 사항이 .net 표준 2.0을 기다리고 있습니다.

@ewinton 응답해 주셔서 감사합니다. 그러나 나는 이것을 받지 못합니다. WF는 성공적인 MS 제품이 아니었으며 MS는 수년 동안 이를 개선하기 위해 아무 조치도 취하지 않았습니다. 커뮤니티는 시도하고 실패한 구현에 대한 간증으로 가득합니다. 기업에서 널리 채택되지 않았습니다. 다루기 힘들고, 기능이 너무 많으며, 배우기 어렵고 (여전히) 버그가 있습니다. 그것의 인터페이스는 널리 악의적입니다. 최종 사용자에게 친숙한 기술이 되는 데 실패했습니다. 내부는 본질적으로 쉽게 강화할 수 없는 블랙박스입니다. 단순한 워크플로 이외의 모든 것은 SLOW입니다. 테스트하기가 매우 어렵습니다. 오래된 기술(WCF, XAML)을 기반으로 합니다. Ron Jacobs가 아팠을 때부터 WF는 쇠약해졌고 MS에 친구가 없습니다.

내 추정에 WF는 모든 사람을 위해 모든 것을 시도했지만 실제로는 누구에게나 작은 것으로 판명되었습니다. Microsoft는 모든 것을 삭제했습니다. 우리는 왜 그런 것을 부활시키려 합니까? 중요한 기술이 다시 생각하고 다시 작성해야 하는 경우 이것이 바로 IT입니다.

Daniel Gerlag의 신생 프로젝트를 보십시오. 새롭고 미숙합니다. 그러나 개선하기 쉬운 워크플로에 대한 현대적인 접근 방식이 필요합니다. 여기 있는 모든 사람들이 복잡하고 구식이며 솔직히 지나치게 엔지니어링된 프로젝트를 개조하려는 시도를 중단하고 대신 새롭고 더 나은 무언가에 노력을 기울인다면 우리는 가치 있는 장소에서 끝낼 기회가 있을 것입니다. 처음부터 거대 기업을 다시 작성하려고 하는 대신 세계적 수준의 워크플로 엔진을 사용합니다. 솔직히 말해서, 저는 매우 가치 있는 노력에 참여하고자 하는 여기 있는 모든 사람을 존경합니다. 마침내 잘 엔지니어링되고 기능적이며 가벼우며 배우기 쉬운 크로스 플랫폼 워크플로(상태 머신?) 도구를 만드는 것입니다. 그러나 유감스럽게도 여러분 모두가 이 길을 계속 따라가면 여러분의 모든 노력이 헛되이 사라질 것입니다. 모.

@ccpony 의견을 공유해 주셔서 감사합니다. 어떤 버그를 말씀하시는지 자세히 설명해 주시겠습니까? .NET Framework의 문제를 해결하기 위해 우리가 할 수 있는 일이 있다면 기꺼이 알고 싶습니다.

@dmetzgar 응답해 주셔서 감사합니다, Dustin. WF 응용 프로그램을 개발하는 동안 버그가 발생했습니다. 예상치 못한 동작뿐만 아니라 복잡한 WF가 "폭발"되어 XAML 코드에서 수정하기 어려운 XAML UI에서 오류를 생성하는 경우가 여러 번 있었습니다. 저는 WF 기술에 대해 큰 자신감을 갖게 된 적이 없습니다. 정말로, 800파운드의 고릴라와 씨름하는 것처럼 느껴질 정도였습니다. 한 발짝 앞으로 나아갈 때마다 나는 결국 두 발짝 뒤로 물러날 것입니다.

버그에 대해 자세히 설명해 달라는 친절한 요청에서 그것이 당신이 찾고 있는 것이 아니라는 것을 압니다. 솔직히, 나는 그 버그들을 해결할 수 있었다. 그러나 나는 이전 게시물에서 언급한 다른 모든 이유로 WF를 결국 포기했습니다.

당신은 이 노력을 주도하고 있으며 나는 당신에게 경의를 표합니다. 그러나 복잡한 기술을 개조하려는 시도가 역효과를 내는 시점이 분명히 옵니다. 이 전체 스레드에 따르면 진행이 매우 느리고 결국에는 이 모든 것으로부터 아무것도 표시되지 않을 것이라는 느낌을 지울 수 없습니다. 나는 오래된 워크플로가 여기에서 생성된 모든 것에 이식될 가능성이 매우 낮다는 것을 알았습니다. 이 스레드의 사람들은 클라이언트 기반 워크플로(예: JavaScript), REST 호환성, 종속성 감소, 크로스 플랫폼 등에 대해 이야기하고 있습니다. 예를 들어 XAML은 오래된 WF 기술의 중요한 부분입니다. XAML은 그 일부가 아니겠습니까?

그래서 더스틴, 저는 당신에게 이것을 묻고 싶습니다. 이제 우리는 이 프로젝트를 시작한 지 18개월이 지났고 실질적인 진전이 이루어지고 있다는 합의가 없는 것 같습니다. 나는 당신의 노력을 존중하고 당신이 훌륭한 코더라는 것을 알 수 있습니다. 하지만 여기에 제 질문이 있습니다. 이 모든 에너지와 열정을 모아 새로운 것을 만드는 것이 훨씬 더 합리적이지 않을까요?

@ccpony 이 주제의 논의는 WF .Net Standard를 지원하는 것이며 그 반대는 아닙니다.

그냥 궁금해서요... Sharepoint 배포를 실제로 사용하거나 본 적이 있습니까? 그렇게 하면 WF에 정말 많이 의존한다는 것을 알게 될 것입니다. BizTalk 배포를 본 적이 있습니까? 똑같다.

엔터프라이즈 세계의 주요 MSFT 제품이므로 예, WF에 관심을 가진 사용자가 있고 사용하는 경우가 있습니다. 말씀하신 것처럼 버림받은/중단된 프로젝트가 아닙니다.

즉, @dmetzgar repo를 보면 일부 항목이 유사하거나 WF의 이전 구현에서 일부 동작을 상속한 만큼 경량으로 재설계되었음을 알 수 있습니다. 지속성은 분리되며 사람들은 쉽게 새로운 것을 만들 수 있습니다. 디자이너는 분리되었고 사람들은 이미 여러 테스트를 만들었습니다.

새로운 것을 원하는 것에 대한 당신의 좌절감을 이해합니다. 저를 믿으십시오. 저도 그렇게 되기를 바랍니다. 하지만 @dmetzgar 와 그의 팀을 이해해야 합니다. 고객의 95%가 내가 언급한 것처럼 기본적으로 BizTalk 및 Sharepoint에서 실행되는 이전 WF 사용자이기 때문에 이것은 우선 순위가 아닙니다. 나는 매우 높은 tps 환경(은행 및 금융 거래)에서 수년 동안 이전 WF를 사용했으며 매우 잘 작동했습니다.

내 새로운 기술은 .Net Core와 함께 작동하고 있으며 지금 다시 사용하지 않는 유일한 이유는 아직 .Net Core용이 없기 때문입니다.

내가 @dmetzgar 에게 이미 제안한 것은 WF 리포지토리를 .Net Foundation으로 가져오고, 이정표를 정의하고, 거기에 코드를 넣고, 문제로 작업을 추가하고, 커뮤니티에서 시작할 수 있도록 up-for-grabs 로 태그를 지정하는 것입니다. 그러나 여전히 그의 팀이 이 작업을 수행하는 데 약간의 시간이 필요하며 가능한 (아직) 시간이 없을 수 있습니다.

@galvesribeiro 나는 당신의 요점을 이해합니다. 예, SharePoint 배포를 작성했습니다. 그리고 BizTalk 배포가 실제로 실행되는 것을 보았습니다( * 셔터 *). SharePoint와 WF 간의 관계를 이해합니다. (BizTalk가 어떻게든 WF에 의존한다고 제안할 때 무슨 뜻인지 모르겠습니다. 그렇지 않습니다.)

그러나 한 가지 중요한 점에서 귀하와 동의하지 않을 수 없습니다. WF는 버려진/중단된 프로젝트 입니다 . 이 시점에서 SharePoint 개발자의 우려를 진정으로 이해합니다. MS가 SharePoint에서 WF의 기능을 향상시킬 것이라고 믿을 이유가 없습니다. @dmetzgar 의 노력이 SharePoint(또는 BizTalk)의 미래와 관련이 있을 것이라고 생각하는 이유를 이해하지 못합니다. MS가 @dmetzgar 의 코드로 SharePoint를 개조하는 것과는 다릅니다. 죄송합니다. SharePoint의 미래는 여기에서 수행되는 노력과 관련이 없습니다.

따라서 정말 중요한 것은 이 모든 것에서 좋은 워크플로 엔진이 나올지 여부입니다. 그리고 WF와 같은 거대 기업을 미래에 강요하는 것은 최선의 행동이 아니라는 것이 제 주장입니다. 처음부터 빌드하는 것이 좋습니다.

@ccpony 이 프로젝트가 실현되는 것을 적극적으로 찾고 있는 수많은 사람들이 여기 있으며 일부는 실제로 시간을 들이고 있다는 것을 상기시키고 싶습니다. 개인적으로 WF는 Microsoft의 실패한 제품으로 볼 수 있지만 WF는 계속 .NET의 일부로 남아 있으며 여기에서 우리뿐만 아니라 더 많은 사람들이 사용합니다.

이 스레드는 다른 사람이나 제품 자체에 대한 비방이 아니라 전환을 현실로 만들기 위한 건설적인 비판과 입력을 위한 것이어야 합니다. 귀하의 견해는 존중되지만 이는 귀하의 것이며 다른 사람들은 WF가 그들에게 얼마나 중요한지에 대해 다르게 생각할 수 있습니다.

제품을 개선할 수 있는 방법과 시도에 적극적으로 참여하는 사람들을 도울 수 있는 방법에 대한 귀하의 의견을 적극 환영합니다.

감사합니다 =^_^=

@ccpony

(BizTalk가 어떻게든 WF에 의존한다고 제안할 때 무슨 뜻인지 모르겠습니다. 그렇지 않습니다.)

죄송합니다. 표현이 서툴러요(저는 모바일입니다). 나는 둘 다 함께 사용하는 응용 프로그램을 가지고 있었고 다른 것도 많이 알고 있습니다.

MS가 SharePoint에서 WF의 기능을 향상시킬 것이라고 믿을 이유가 없습니다.

그럴 것이라고 말하는 것이 아닙니다. WF Today와 함께 일하는 팀은 Sharepoint 배포 지원에 전적으로 집중하고 있습니다. 최신 버전의 Sharepoint도 동일한/현재 버전의 WF를 사용하고 있습니다.

@dmetzgar 의 노력이 SharePoint(또는 BizTalk)의 미래와 관련이 있을 것이라고 생각하는 이유를 이해하지 못합니다.

나는 그것이 Sharepoint의 미래에 영향을 미칠 것이라고 말하는 것이 아닙니다. 내가 올바르게 이해했다면 팀이 Sharepoint를 지원하느라 바쁘다는 뜻입니다. ( @dmetzgar 는 내가 틀렸다면 나를 고칠 수 있습니다)

MS가 @dmetzgar 의 코드로 SharePoint를 개조하는 것과는 다릅니다. 죄송합니다. SharePoint의 미래는 여기에서 수행되는 노력과 관련이 없습니다.

MS가 Sharepoint vNext에서 WF vNext를 사용할지 여부는 그들만이 확실히 알 수 있습니다. 다시 말하지만 문제는 WF 팀이 두 가지 모두를 처리할 수 없다는 것입니다.

따라서 정말 중요한 것은 이 모든 것에서 좋은 워크플로 엔진이 나올지 여부입니다. 그리고 WF와 같은 거대 기업을 미래에 강요하는 것은 최선의 행동이 아니라는 것이 제 주장입니다. 처음부터 빌드하는 것이 좋습니다.

아무도 그것을 그대로 이식하지 않습니다. @dmetzgar 의 repo는 처음부터 다시 디자인되고 있다는 증거입니다. 다시 말하지만 문제는 팀이 두 가지를 모두 처리해야 하는 백로그와 대역폭입니다. 그렇기 때문에 Dotnet Foundation에서 "개방"하고 WF 팀의 안내 와 큐레이션 을 통해 커뮤니티 주도의 주요 노력으로 만들 것을 제안하여 가능한 한 그들의 일정에 영향을 미치지 않도록 노력했습니다.

다시 말하지만 @InariTheFox 와 제가 언급했듯이 이 스레드는 포트에 대한 푸시 포워드이며, 이 모든 기능이 포함된 이전 버전을 새 버전으로 강제 푸시해야 하는 것은 아닙니다. 그러나 사람들이 현재 WF 기반 제품에 많은 노력(과 돈)을 들이고 있다는 것을 이해하는 것이 중요합니다. 따라서 @dmetzgar 가 이전 워크플로와 최대한 많은 호환성을 유지하는 데 관심을 갖는 것은 실제로 돌봐야 할 일입니다.

확인. 여기서 열정이 보입니다. 사실, 제가 앞에서 언급한 모든 문제를 해결하는 WF에 대한 좋은 대체품이 있었다면 우리는 이 대화를 나누지 않았을 것입니다. 기록을 위해 우리 중 많은 사람들이 WF에서 멀어지고 다음 일이 올 때까지 기다렸습니다. 그것은 결코하지 않았다. 내가 아는 한, 널리 인정되는 현재의 지원되고 기능적인 .Net 기반 워크플로/상태 시스템 솔루션은 없습니다. 이해해 주십시오. 저는 WF가 Microsoft의 관점에서 볼 때 죽은 기술이라는 제 주장을 지지합니다.

하지만 그렇게 말했으니 이해를 도와주세요. @dmetzgar 의 repo는 있는 그대로 작동합니까? 워크플로를 어떻게 작성합니까? 예제 코드가 없고 설명서도 없습니다. 어떻게 진행할까요?

WF를 제품 전략의 중심으로 만든 제품/회사가 많이 있다고 생각합니다. 지원 모드에서 Sharepoint 종속성만 있는 것은 아닙니다. 현재 회사에서 WF가 핵심 기술인 자동화 플랫폼을 개발했습니다. 제품에 WF를 사용하는 이 시장의 다른 2명의 경쟁자); 또한 나는 insurtech에서 그것을 사용하는 사람들과 논의했습니다.. 그래서 나는 WF의 청중이 여전히 거기에 있다고 굳게 믿습니다.

그렇긴 하지만 .net 코어는 Microsoft의 초점 영역 중 하나인 것으로 보이며 다음 기간에는 많은 기술 혁신이 여기에 포함될 것입니다. WF를 일부로 포함하지 않는 것은 큰 손실이라고 생각합니다.

내 관점에서 이를 가능하게 하는 올바른 경로는 WF 코어를 xaml과 독립적으로 만들고 다른 형식(예: json)에서도 워크플로를 더 쉽게 (역)직렬화하도록 만드는 것입니다. 이것은 또한 웹 브라우저에서 호스팅되는 워크플로 디자이너와 같은 시나리오의 구현을 단순화합니다. 그리고 https://github.com/dmetzgar/corewf repo를 통해 출발점이 있습니다.

WF의 현재 상태(MS에서 포기한 것으로 보이지 않음)에 대한 개요에 관심이 있는 사람들을 위해 얼마 전에 WF에 대한 사용 가능한 정보를 게시물 및 프레젠테이션 http://andreioros.com/blog 에 집중시켰습니다.

우리와 우리 고객은 WF에 의존하고 있으며 WF가 클라이언트와 서버에서 작동하는 것을 보고 싶습니다. XAML 및 기타 종속성이 없는 WF는 가벼우면서도 MS에서 지원하는 커뮤니티이기도 한 기존 WF의 표현력을 갖춘 흥미롭고 가치 있는 제품이 될 것입니다.

다시 한 번 묻겠습니다. @dmetzgar 의 포트를 사용하여 실행하려면 어떻게 합니까? 현재 상태는 무엇입니까?

@dmetzgar 의 포트가 현재 구현된 버전에서 실제로 사용할 수 있는지 몰랐습니다...

위의 @ewinton 에서:

"지금 dot net core에서 CoreWF를 사용할 수 있기 때문에 -> https://github.com/dmetzgar/corewf . 중앙 구성 요소가 이식되어 작동합니다. 몇 가지 사항이 .net 표준 2.0을 기다리고 있습니다."

어떤 경우에 나도 그 사용법을 듣고 싶습니다 ...

예, 핵심 기능의 핵심입니다. 코드 기반 워크플로를 실행할 수 있습니다. netstandard2.0 에서 누락된 기능은 대부분 트랜잭션 지원과 관련이 있습니다.

그것이 내가 여전히 그것을 시작하고 사람들이 중앙 장소에 기여하도록 제안하는 또 하나의 이유입니다. 그것을 퍼뜨리면 미래의 언젠가는 최종 제품에 도달하기가 훨씬 더 어려워질 것입니다.

Core의 일부로 최신 Roslyn 기능에 대한 테스트 및 지원으로 WF 재작성에 찬성표를 던집니다. 서버리스 및 컨테이너가 아키텍처, 특히 고유한 도메인 컨텍스트 및 비즈니스 프로세스 내에서 규칙 세트의 배포 및 확장에 어떤 영향을 미칠 수 있는지 알고 싶습니다. 저는 개인적으로 WYSIWYG 디자이너보다 간결한 DSL을 선호합니다. 나는 개인적으로 디자이너를 사랑했지만 거의 항상 기발하게 느껴졌습니다. WF 자체는 매우 견고할 수 있는 잠재력이 있었지만 깊은 전문 지식이 필요했습니다. 실제로 WF Manager와 SQL Server의 지속 흐름을 포함하는 WF의 대규모 롤아웃에는 MS 컨설팅 및 버그 수정이 필요했습니다. 지금은 지난 몇 년 동안 Java 팀을 지원하지만 주로 MS 기술에 중점을 둔 15년이 조금 넘은 후 .NET을 계속 주시하고 있습니다. 나는 Nick Harrison의 "Code Generation with Roslyn"을 읽고(나는 그와 그 책과 아무 관련이 없다) Business Rule Engine 영역에 다시 한 번 접근하는 것에 대해 궁금해했고, 그로 인해 WF의 운명에 대해 다시 한 번 생각하게 되었습니다... 솔직히 말해서 Azure Functions는 MS 리소스뿐만 아니라 어디에서나 WF에 대한 깊은 투자를 지원하려는 일반적인 기업의 의지와 경쟁한다고 생각합니다. 그들이 당신이 그것을 사용하기를 바라는 것이 분명해 보입니다. 그래서 아마도 해결책은 대신 OpenWhisk의 오픈 소스 .NET 버전에 집중하는 것입니다. 하지만 컨테이너화된 세상에서는 ... OpenWhisk를 서비스로 사용할 수 있습니다. 그래서...

PS는 외부화된 표현식을 가져오는 강력한 방법을 지원하기만 하면 WF가 필요하다고 생각하는 앱 요구 사항의 60%를 해결할 수 있습니다. CSharpScript였나요? 간단한 API를 사용하여 기본 비즈니스 규칙 구성을 가져오는 간단한 방법은 먼 길을 갈 것입니다(다양한 지속성, 검색 및 캐싱 옵션). 일회용 가상 인프라(인프라, 컨테이너 및 서비스로서의 플랫폼에 대한 자동화)를 통해 WF vNext는 버전 변경 사항을 앱에 인라인하려고 시도하는 것보다 서비스로 배포하는 데 집중할 수 있습니다(즉, WF를 위한 더 나은 솔루션 WCF에서)

저는 이 대화에 매우 관심이 있습니다. 우리 팀은 XAML의 불만도 처리해 왔습니다. 우리의 딜레마는 고객이 Visual Studio나 재호스팅된 디자이너 없이도 고유한 워크플로를 만들 수 있도록 고유한 UI 디자이너를 만들고 있다는 것입니다. 고객이 항상 해당 비트를 다시 작성할 필요가 없도록 XAML 청크를 재사용 가능한 비트로 저장할 수 있는 기능이 필요합니다(이를 워크플로 기능으로 생각). 이를 위해서는 XAML 청크를 함께 병합하는 방법을 알아야 하며, 이는 매우 실망스러운 일입니다. 우리가 하려고 생각하는 것은 단순히 다양한 활동과 그 연결의 데이터베이스 모델에 의존하고 XAML을 완전히 무시하는 추상화를 만드는 것입니다. 그런 다음 워크플로가 실행될 때마다 프로그래밍 방식으로 활동 등을 만듭니다. 이 접근 방식을 연구하는 동안 이 스레드를 우연히 발견했습니다. 대화를 이어가세요. 저는 다른 사람의 의견을 듣는 데 매우 관심이 있습니다.

@erikcai8 워크플로 디자이너는 아주 좋은 아이디어입니다. 워크플로 디자이너의 소스를 얻을 수 있습니까?

저는 자동화 프로젝트에서 5년 이상 WF를 사용해 왔으며 정말 훌륭했습니다. 많은 개발자들이 이 요청을 지원하고 이루어지기를 바랍니다. 저는 일을 시작한 이후로 항상 .Net 기술을 사용해 왔으며 계속 사용하고 싶습니다. 그러나 크로스 플랫폼을 지원할 수 있다는 것이 회사의 방향이므로 .Net Core에서 전체 WF를 볼 수 있기를 정말 기대하고 있습니다.

net standard 2.0이 출시되면 corewf 문제에 대한 업데이트가 있으면 좋을 것입니다.

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

추가된 API가 포팅 프로세스를 어떻게 차단 해제했으며 우리가 무엇을 도울 수 있습니까?

netstandard2.0 에 관계없이 이 포트는 IMHO가 된 대로 가야 한다고 생각합니다. 다시 작성하면... 외부 작업 스케줄러, async/await/Task 및 기타 현대적인 것들에 친숙하게 만듭니다. WF를 사랑하는 만큼 현재 버전은 꽤 구식입니다...

아무 예의 없이 하는 말입니다. 솔직히. 그러나 이 프로젝트가 희망이 없다는 것을 이해하는 유일한 사람이 여기 있습니까? 우리는 .Net을 위한 우수한 워크플로 엔진이 절실히 필요하지만 이것이 전부가 아닙니다. 여기서 대화를 바꿔야 하지 않겠습니까?

저는 새롭고 더 나은 워크플로 엔진에 열려 있습니다. 결론적으로 .NET Core에 하나가 필요합니다. 우리는 수년 동안 WF를 사용해 왔으며 우리에게 정말 잘 작동했기 때문에 대안이 없다면 없는 것보다 낫습니다.

@kalokamgit , 소스는 참조 소스에서 사용할 수 있습니다. 두 개의 어셈블리에 있습니다.
System.Activities.Presentation 및 System.Activities.Core.Presentation .

불행히도 참조 소스를 게시하는 도구는 C# 코드만 수행합니다. 여기에는 XAML 파일이 포함되지 않습니다. 이에 대한 피드백을 [email protected] 으로 제공하거나 사용자 목소리 문제 에 대해 투표할 수 있습니다.

코드는 .NET Framework에 있으므로 자신의 도구에서 자유롭게 사용할 수 있습니다. 몇 가지 예는 @orosandrei 의 프로젝트 와 여기 에 있는 예제 프로젝트입니다.

아무 예의 없이 하는 말입니다. 솔직히. 그러나 이 프로젝트가 희망이 없다는 것을 이해하는 유일한 사람이 여기 있습니까? 우리는 .Net을 위한 우수한 워크플로 엔진이 절실히 필요하지만 이것이 전부가 아닙니다. 여기서 대화를 바꿔야 하지 않겠습니까?

글쎄, 당신이 _정말로_ 무례하지 않다는 것을 의미한다면. :) Flow 에 대한 모든 분들의 생각이 궁금합니다. 그것이 내가 "현대"를 위한 "워크플로"를 생각할 때 생각하는 것입니다. 또한 요즘 Azure가 꽤 열심히 팔고 있는 것입니다.

나는 정말로 정말로 그것을 의미한다 :)

Flow가 Zapier 성장에 대한 답이라고 생각하십니까? 나는 그것이 어떤 식으로든 WWF를 대체할 것인지 알지 못합니다.

WF가 중단되었거나 여기에 누락된 것이 있습니까? 그것은 매우 슬플 것입니다!

어디에서 WF에 투표할 수 있습니까?

이번 호의 탑 포스트가 베스트 플레이스입니다.

@rjacobs (WF 전문가)는 이 문제에 대해 어떻게 생각하는지 궁금합니다.

@ronljacobs를 의미합니까?

@dmetzgar 아마도 그렇습니다. 그는 진정한 WF 영웅입니다

이게 내 대답이야
https://github.com/danielgerlag/workflow-core

Ron Jacobs는 수년 동안 WF에 마음과 영혼을 바친 사람이었습니다. 그는 Dercum's Disease에 걸려 2013년에 Microsoft를 떠났습니다. (여기) 그가 떠날 때 WF는 그게 전부였습니다. 다시 한 번, 그리고 마지막으로 WF는 죽었습니다.

그리고 다시 한 번 -- 저는 모든 사람과 모든 사람이 위의 Dan Gerlag의 프로젝트를 보도록 권장합니다. 유창하고 아름답게 구상되었으며 Core에서 실행됩니다. 실행 가능한 워크플로 솔루션에 기여하려는 사람은 누구나 볼 필요가 있습니다.

또한 Durable Task Framework 를 살펴보십시오. 이것은 Azure Functions에 추가되고 있습니다( Durable Functions 참조).

@dmetzgar 이 프레임워크는 WF의 대안으로 간주되는 기저귀에 있습니다. 나는 마이크로소프트가 이런 종류의 것을 제안하는 것이 심각하다고 생각하지 않는다. 바퀴를 재발명하고 WF를 .NET Core로 마이그레이션하고 모든 Microsoft 프로젝트의 기반으로 재사용하는 것보다 훨씬 낫지 않을까요? 가혹한 말을 해서 죄송합니다만, WF의 현 상황에 많이 실망하신 많은 분들의 심정을 대변하는 것 같습니다.

@Suriman , 공정한 지적

WF를 .NET Core로 이식하는 것과 관련된 내용을 더 잘 설명하기 위해 corewf 리포지토리 의 추가 정보를 업데이트했습니다. 한 번 보시겠습니까?

@dmetzgar 설명과 WF를 .NET Core로 이식하는 방법을 명확하게 보여주셔서 감사합니다. Microsoft가 이 모든 마이그레이션 작업을 수행하지 않을 것이며 커뮤니티가 수행하기를 희망한다는 귀하의 말을 이해합니다. 그렇죠? 이 질문에 대한 답이 핵심입니다. 응답에 따라 기업은 대체 경로를 선택하거나 Microsoft가 해야 하는 작업을 수행할 수 있습니다.

Microsoft는 .NET Core에 대한 WF의 공식 포트를 수행하지 않습니다. 우리 팀과 나는 여가 시간에 이 작업을 할 것이지만 공식적으로나 예정된 릴리스에서는 그렇지 않습니다. 나열된 모든 문제가 해결되었습니다. 우리가 수행하는 일부 프로젝트에는 이러한 포트가 사용됩니다. 그것은 우리의 기여의 대부분이 오는 곳이 될 것입니다. 나는 지금 이 문제를 닫고 사람들이 최신 작업을 따르기 위해 corewf repo 를 가리키도록 하는 것이 공정하다고 생각합니다.

안녕,
Future 마일스톤에서 2.1로의 변경은 Microsoft가 WF를 .NET Core로 이식한다는 의미입니까?

마감된 이슈에 대한 마일스톤 변경은 이슈가 마감된 릴리스를 반영합니다.
이 특정 문제는 기본적으로 "수정되지 않음"으로 종료되었습니다. https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275 위의 설명을 참조하세요.

@karelz 정말 유감입니다. 순간 복권이 당첨된 것 같았습니다.

우리는 WF를 기반으로 하는 솔루션을 가지고 있습니다. 우리는 WF를 사용하여 활동 단계를 만들고 있으며 이 워크플로는 모든 구독자에게 전달되며 WF를 기반으로 작업을 처리합니다. 우리는 WF를 매우 사랑합니다. 크로스 플랫폼을 지원하는 것이 우리 회사의 방향입니다. 우리는 .NET CORE에서 WF를 사용하는 데 매우 관심이 있습니다.

.net core에 부분적으로 이식된 Workflow Foundation의 코드인 CoreWF 가 있습니다. 이제 Workflow Foundation 크로스 플랫폼을 사용할 수 있습니다. 지금은 XAML 기반 워크플로를 사용할 수 없습니다.

Net Standard 2.0 위에 Dynamic Activity 에 대한 지원을 추가하는 작업을 한 지점이 있습니다.

XAML 구문 분석 프로세스를 수행하려면 Microsoft에서 파일을 올바르게 구문 분석할 수 있도록 충분히 System.XAML을 열어야 합니다.

https://github.com/dmetzgar/corewf/issues/6 에서 이 문제에 대한 진행 상황을 추적할 수 있으며 이 문제를 알리기 위한 다양한 시도를 할 수 있습니다.
CoreFX에서
참조 소스에서

.Net 호환성 팩 에는 System.XAML 전면에 "미정"이 있습니다. 그러나 포함에 대한 뉴스는 필터링되지 않았습니다. Ship .Net Framework Compatibility Pack 문제는 현재 System.XAML에 대한 "계획 없음"을 나열합니다.

또한 Customer Adoption Epic 이 Workflow Foundation(및 System.Xaml)을 추가하면 회사에서 제품을 배송할 수 있는 방법에 대한 이야기를 전달하는 데 사용할 수 있는 문제일 수도 있습니다.

우리 회사도 WF에 투자하고 있습니다. 우리는 고객이 Workflow Foundation을 사용하여 워크플로를 만드는 에너지 회사를 위한 제품을 보유하고 있습니다.

당신의 답변에 감사드립니다.
매우 유용했습니다.

2017년 11월 2일 18시 22분에 "Eric Winnington" [email protected] 이 다음과 같이 썼습니다.

코드인 CoreWF https://github.com/dmetzgar/corewf 가 있습니다.
Workflow Foundation이 부분적으로 .net 코어로 이식되었습니다. 워크플로를 사용할 수 있습니다.
지금 재단 크로스 플랫폼 . XAML 기반 워크플로를 사용할 수 없습니다.
이 시간에.

Dynamic Activity에 대한 지원을 추가하는 작업을 한 지점이 있습니다.
Net Standard 2.0 https://github.com/ewington/corewf 위에 있습니다.

XAML 구문 분석 프로세스에서는 Microsoft에서 System.XAML을 열어야 합니다.
파일을 올바르게 구문 분석하는 과정을 진행할 수 있을 만큼 충분합니다.

여기에서 문제의 진행 상황을 추적할 수 있습니다. dmetzgar/corewf#6
https://github.com/dmetzgar/corewf/issues/6 및 내 다양한 ​​시도
이 문제에 대한 통지:
CoreFX에서
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
참조 소스에서
https://github.com/Microsoft/referencesource/issues/39

.Net 호환성 팩
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
System.XAML 전면에 "아마도"가 있습니다. 그러나 그것에 대해 필터링 된 뉴스는 없습니다.
포함. 문제 Ship .Net Framework 호환성 팩
https://github.com/dotnet/corefx/issues/24909 는 현재 "아니오
계획"에 대해 설명합니다.

어쩌면 또한 문제 고객 채택 에픽
https://github.com/dotnet/corefx/issues/24751 을 사용하여 알 수 있습니다.
Workflow Foundation(및 System.Xaml)을 추가하는 방법에 대한 귀하의 이야기
귀하의 회사는 제품을 배송합니다.

우리 회사도 WF에 투자하고 있습니다. 에너지 회사를 위한 제품이 있습니다.
고객이 Workflow Foundation을 사용하여 워크플로를 만드는 곳입니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

안녕,
이것은 마이크로 서비스의 세계이며 전체 항목이 구성 요소로 나뉩니다. 이제 이를 오케스트레이션해야 하는 경우 워크플로에 대해 프리미엄을 청구하는 Azure 논리 앱 또는 기타 외부 공급업체에 의존해야 합니다. Netflix Conductor와 같은 비 .NET WF 제품은 거의 없지만 순수한 .NET 코어 버전을 갖고 싶습니다. https://github.com/Netflix/conductor 에서 Netflix 지휘자로부터 단서를 얻고 거기에서 구축을 시작할 수 있습니다. 이는 Logic Apps를 사용할 수 없는 Azure Stack에 대한 액세스 권한이 없는 프라이빗 클라우드 개발자에게 큰 도움이 될 것입니다.

인식을 위해 여기에 게시 할 것이라고 생각했습니다. 나는 다음 문서를 읽고 있었고 이 스레드를 생각하게 되었습니다.
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

Dynamics365와 PowerApps가 마인드 멜드를 하고 있고 현재 워크플로 처리를 위해 Windows Workflow를 어느 정도 사용하고 있는 것 같습니다. 물론 이것은 모두 Windows 전용이지만 크로스 플랫폼 등의 새로운 시대에... 얼마나 오래 지속됩니까?

무엇을 사용해야하는지 모르겠습니다. MSFT가 했으면 좋겠습니다. 명확성을 제공합니다. Microsoft.

@VenkateshSrini , Cadence도 살펴봐야 합니다: https://github.com/uber/cadence
이 모델은 Amazon의 SWF와 비슷하지만 오픈 소스입니다. 아직 .NET 클라이언트가 없습니다.

찾고. 네트 코어 버전

그런 일은 없을 것이다.

보낸 사람: VenkateshSrini [email protected]
보낸 날짜: 2018년 9월 26일 수요일 오전 12:30
받는 사람: dotnet/corefx [email protected]
참조: Jeffrey Michelson [email protected] ; 멘션 @noreply.github.com
제목: Re: [dotnet/corefx] Workflow Foundation을 .NET Core로 포트(#2394)

찾고. 네트 코어 버전

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 회신하거나 GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 에서 확인하거나 스레드 https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7uewZ 를 음소거하세요.

너무 나쁨

그렇다면 비 Azure 에코시스템에서 ifttt 또는 워크플로에 대해 Microsoft가 제공하는 것은 무엇입니까? Azure에서 ml와 같은 것을 활성화하려는 경우 워크플로가 아닌 이유

Dan Gerlag의 작업을 확인하십시오.

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

보낸 사람: VenkateshSrini [email protected]
보낸 날짜: 2018년 9월 26일 수요일 오전 8:34
받는 사람: dotnet/corefx [email protected]
참조: Jeffrey Michelson [email protected] ; 멘션 @noreply.github.com
제목: Re: [dotnet/corefx] Workflow Foundation을 .NET Core로 포트(#2394)

그렇다면 비 Azure 에코시스템에서 ifttt 또는 워크플로에 대해 Microsoft가 제공하는 것은 무엇입니까? Azure에서 ml와 같은 것을 활성화하려는 경우 워크플로가 아닌 이유

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 에서 확인하거나 스레드 https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- 를 음소거하세요.

Workflow 기반을 .net 코어로 포트하는 CoreWF 가 있습니다. 이 포트는 진행 중입니다. 도와주실 분들을 찾고 있습니다.

다음 주요 디딤돌은 Roslyn으로 로드된 워크플로를 컴파일하여 워크플로 매개 변수의 코드를 사용할 수 있도록 하는 것입니다. 이는 XAML 정의 워크플로에 필요합니다. Imperative core에서 워크플로를 정의하면 이제 CoreWF를 사용할 수 있습니다.

@ewinton 과 @dmetzgar 의 작업에 감사드립니다! CoreWF의 Portable.XAML을 통한 XAML 지원은 이러한 노력에 대한 엄청난 일입니다. @dmetzgar 곧 NuGet에 새 버전을 게시할 계획입니까?

안녕하세요 여러분,

이 모든 생산 준비가 완료되었습니다. 우리는 외부 Ui에서 수행할 워크플로 정의를 롤링하고 있습니다. 그러나 엔진은 정의를 로드하고 계속 작동할 수 있어야 합니다. 더 뻣뻣한 종류

@VenkateshSrini , Microsoft가 플랫폼 간 워크플로 프레임워크를 제공할 필요가 없다고 생각합니다. .NET Framework 시절에 Microsoft는 전체 커뮤니티에 피해를 주는 모든 것을 제공했습니다. 더 많은 .NET 오픈 소스 라이브러리가 조직에서 채택되고 "프로덕션 준비"가 되었으면 합니다.

@watertree , 저는 Portable.Xaml의 새로운 릴리스를 기다리고 있습니다. CoreWF XAML 지원에 필요한 중요한 수정 사항이 있습니다.

현재 장기 실행 워크플로의 대안은 무엇입니까(지속성 포함)? 유료만?

@freerider7777

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

우리 회사에서 매우 좋은 결과로 그것을 사용합니다.

여전히 팔로우하는 사람들을 위해 CoreWf 프로젝트는 동적으로 로드된 XAML 워크플로를 실행할 수 있도록 Roslyn을 통합하여 중요한 이정표를 진행했습니다. 여전히 dotnet core에 Workflow Foundation이 필요한 경우 확인하십시오.

안녕 ,
기존 XAML 워크플로를 그대로 사용할 수 있다는 의미입니까? 우리에게 어떤 제한이 있습니까

우리에게 어떤 제한이 있습니까

인스턴스 저장소가 아직 이식되지 않았으며 디자이너가 코어에 없으며 WCF 서버가 아직 코어에 없기 때문에 WCF 서비스를 사용할 수 없습니다.

CoreWf 리포지토리 에 문제를 만들고 요구 사항을 나열하십시오. 우리는 그곳에서 대화를 계속할 수 있습니다.

corewf에 대한 현재 너겟은 오래되었으며 방금 병합된 Roslyn 기반 런타임 Xaml 실행을 포함하지 않습니다. 우리는 여전히 작동하는 것과 작동하지 않는 것을 보기 위해 피드백을 찾고 있습니다.

이것은 결코 일어나지 않을 것임을 의미합니까?

그것은 일어나지 않을 것입니다. 그것은 결코 일어나지 않을 것입니다. 최선을 다한 사람들에게 불쾌감을주지 않았습니다. Dan Gerlag의 프로젝트(https://github.com/danielgerlag/workflow-core)를 확인하거나 총알을 깨물고 Azure LogicApps 기차에 탑승하세요.

안녕하세요 2020년 10월 콜링입니다. .NET Core의 Workflow Foundation에 대한 뉴스/업데이트/릴리스가 있습니까?

아니면 우리 모두 엘사로 이사해야 할까요? https://elsa-workflows.github.io/elsa-core/

@wstaelens 나는 MS의 대답이 꽤 명확했다고 생각합니다 . WF는 공식적으로 .Net Core로 이식되지 않을 것입니다. 제안된 대안은 CoreWF 입니다.