If I have a state machine created in version 3.5 will I be able to upgrade to .NET/Windows Workflow Foundation 4.0, or will I have to re-create the functionality? I heard / read that 4.0 does not support state machines. Finally, if you have a state machine in 3.5, what is your plan for migrating to 4.0?
R – Are state machines created in Windows Workflow Foundation 3.5 compatible with version 4.0
.net-4.0state-machineworkflow-foundationworkflow-foundation-4
Related Solutions
According to this article:
http://visualstudiomagazine.com/articles/2009/01/01/windows-workflow-changes-direction.aspx
Windows Workflow Foundation 4.0 is a "bottom-up rewrite with entirely new thinking...WF 3.0/3.5 will remain part of the framework and will run side by side with WF 4.0. This lets you manage the transition at a time that fits your organization's broader goals."
...which is code for, "We know we just screwed up your programming model, but we have a long term strategy, so we hope you will forgive us."
The article goes on to say that
The gains are enormous: custom activities take center stage, and authoring them is much simpler; workflows are entirely declarative; and there are three workflow flow styles that you can combine seamlessly. It's possible that you could see a 10-fold improvement in the time required to create and debug workflows, in addition to 10- to 100-fold runtime performance improvements.
The change is not without its detractors. In this article at DotNetKicks, the author states that "Microsoft is seriously damaging the Dot Net developer community and adoption in the industry with these half baked product releases and abrupt about-faces after shipping."
Which is why I generally wait for the 2.0 or 3.0 version of Microsoft technologies, although I made an exception for ASP.NET MVC.
To enable msbuild in Command Prompt, you simply have to add the directory of the msbuild.exe install on your machine to the PATH environment variable.
You can access the environment variables by:
- Right clicking on Computer
- Click Properties
- Then click Advanced system settings on the left navigation bar
- On the next dialog box click Environment variables
- Scroll down to
PATH - Edit it to include your path to the framework (don't forget a ";" after the last entry in here).
For reference, my path was C:\Windows\Microsoft.NET\Framework\v4.0.30319
Path Updates:
As of MSBuild 12 (2013)/VS 2013/.NET 4.5.1+ and onward MSBuild is now installed as a part of Visual Studio.
For VS2015 the path was %ProgramFiles(x86)%\MSBuild\14.0\Bin
For VS2017 the path was %ProgramFiles(x86)%\Microsoft Visual Studio\2017\<YOUR_VS_EDITION>\MSBuild\15.0\Bin
For VS2019 the path was %ProgramFiles(x86)%\Microsoft Visual Studio\2019\<YOUR_VS_EDITION>\MSBuild\Current\Bin
where <YOUR_VS_EDITION> matches the Visual Studio edition that you have installed, i.e., Preview, Community, Professional, Enterprise.
Best Answer
That a state machine workflow is no longer needed in WF4 is not quite true.
Most, but not all, state machine scenarios are easier to model in a WF4 flowchart. That is the case because most developers used state machine because sequential was not flexible enough. All those cases, and those are probably a majority, are well covered by the flow chart.
However the event driven state machine examples are much harder in WF4. Check the WF4 State Machine Guidance here for more details. And the team at Microsoft has announced they are planning on releasing a state machine for WF4 after the initial version ships with .NET 4.