We have a long running workflow which uses SQL tracking service (.Net WF 4.0). In the next update, we would like to introuduce a public property in one of the arguments of the workflow. Since this is breaking change, the persisted workflow inatances throw the following error on re-loading:
System.Runtime.DurableInstancing.InstancePersistenceCommandException: The execution of the InstancePersistenceCommand named .. LoadWorkflow was interrupted by an error.
InnerException: System.Runtime.Serialization.SerializationException: 'Element' '_x003C_BookmarkName_x003E_k__BackingField' from namespace '...' is not expected. Expecting element '....'
I understand this is a typical versioning issue and one of the recommendations I noticed on some of the sites is to override OnActivityExecutionContextLoad method and fill in the missing values. But I am not sure where and how to do this! OnActivityExecutionContextLoad is declared in System.Workflow.ComponentModel.Activity (.Net 3.5?) whereas what we have is a code-based top-level custom activity derived from System.Activities.NativeActivity (which receives the argument in question). Can something be done in this class to initialize the missing property of the argument?
All suggestions are welcome :)
Related
Using Data Fusion Argument Setter, I've defined all parameters in it for a reusable pipeline. While executing it, I provide runtime arguments for some parameters which are different from default arguments provided in the JSON URL embedded in Argument Setter.
But a number of times, the pipeline ends up taking the default values from Argument Setter URL instead of Runtime Arguments causing failures.
This behavior is not consistent in every pipeline I create - which confirms that Runtime arguments are supposed to supersede any prior value defined for an argument.
The workarounds I use is by deleting the plugin and re-adding it for every new pipeline. But that defeats the purpose of creating a re-usable pipeline.
Has anyone experienced this issue ?
Current Runtime Options
This wiki https://cloud.google.com/data-fusion/docs/tutorials/reusable-pipeline provides the sample of how to create re-usable pipeline using Argument Setter. From there, it seems like the runtime arguments was used to notify the data fusion pipeline to use the macro from Argument Setter URL. Argument Setter is a type of Action plugin that allows one to create reusable pipelines by dynamically substituting the configurations that can be served by an HTTP Server. It looks like no matter how you change the runtime arguments, as long as long the same marco can be read when pipeline is running, the arguments will be override.
Assume having these models first:
Method that has one OriginalCode
OriginalCode that has many Mutants
Mutant that has many ParseSubTrees
Now when querying on Method I want the other being loaded. So I have the following:
Method targetMethod = dBContext.Methods
.Include(me => me.OriginalCode)
.ThenInclude(oc => oc.Mutants)
.FirstOrDefault(me => me.Id == id);
and the next step is to include additionally the ParseSubTree. But the thing is that I can't access it. See the following Image:
the problem is "mu is a list instead of being an object reference"!
Where is my mistake!
TG.
This is a known Intellisense issue with the ThenInclude overload for collection type navigation properties, tracked by the Completion missing members of lambda parameter in fault tolerance case #8237 Roslyn GitHub issue.
Until it gets fixed, simply type the name of the property and it will compile successfully and work as expected.
.ThenInclude(mu => mu.ParseSubTrees)
Update: Now it's even specifically mentioned in the Including multiple levels
section of the EF Core documentation:
Note
Current versions of Visual Studio offer incorrect code completion options and can cause correct expressions to be flagged with syntax errors when using the ThenInclude method after a collection navigation property. This is a symptom of an IntelliSense bug tracked at https://github.com/dotnet/roslyn/issues/8237. It is safe to ignore these spurious syntax errors as long as the code is correct and can be compiled successfully.
In my case there was a conflict between the namespaces System.Data.Entity and Microsoft.EntityFrameworkCore. Just delete the first using line.
Something I ran into recently.
I have a project which dynamically generates connection strings and I'm trying to use MigrateDatabaseToLatestVersion on the context that wraps these. Every time I would do this I would see my dynamic db not be created, but instead the db on my default constructor connection string (used for testing) migrated over and over.
After digging through the EF migrations source code I find that MigrateDatabaseToLatestVersion has a constructor
// Summary:
// Initializes a new instance of the MigrateDatabaseToLatestVersion class specifying
// whether to use the connection information from the context that triggered initialization
// to perform the migration.
//
// Parameters:
// useSuppliedContext:
// If set to true the initializer is run using the connection information from the
// context that triggered initialization. Otherwise, the connection information
// will be taken from a context constructed using the default constructor or registered
// factory if applicable.
public MigrateDatabaseToLatestVersion(bool useSuppliedContext);
Not being flippant but what is the reason why you would want to ever migrate the context that is not the one that is being migrated? Why is that the default? Does anyone have any insight into the thinking here?
I want to know the answer to this question myself. I do not know why the context was designed that way. However, I can venture a guess as to why the current default is useSuppliedContext=false.
I decompiled the first version of EntityFramework to include migration support, EntityFramework-4.3.0, because I suspect that the default behavior is for backwards compatibility purposes. I looked at the decompiled implementation of IDatabaseInitializer<TContext>.InitializeDatabase(TContext context) in MigrateDatabaseToLatestVersion. Guess what? In EntityFramework-4.3.0, the context parameter of that method is completely ignored. So it can’t possibly respond to explicitly-provided connection parameters/settings because those are only accessible through that context variable.
It looks like support for respecting context was added in EntityFramework-6.1.1. Prior to that, your only option was to pass a connection string to MigrateDatabaseToLatestVersion’s constructor. I think this would have prevented you from using the same DbContext type for different backends in the same process. I bet that the new feature of respecting the context (and behaving correctly, IMO) would not have been accepted into EntityFramework if it was enabled by default because that would change behavior which stable projects may be relying on and otherwise prevent projects from adopting it.
The exact reasoning is actually given as a comment in commit 777a7a77a740c75d1828eb53332ab3d31ebbcfa3 by Rowan Miller:
Also swapping the new useSuppliedContext parameter on MigrateDatabaseToLatestVersion`.cs to be false by default since we are going to be shipping this change in a patch release.
the context of the problem is like this: we create workflows, we save it and after a while a new implementation request comes and we change an activity. After this the workflow instances that were saved cannot run anymore. We get this error:
StateMachine Error : Cannot convert object 'True' to type 'System.String'.
It seems that the new argument added brakes the serialization order?
You'll have to implement Dynamic Update in some fashion.
We are currently in the process of getting some infrastructure set up to update existing instances, and having lots of issues. Hopefully your scenario is easier to solve than ours!
Start here: https://msdn.microsoft.com/en-us/library/hh314052(v=vs.110).aspx
Word of caution: I've found various issues with Microsoft's provided code that required a lot of investigation to fix.
I have two workflow foundation (.NET 3.5 SP 1) application which compiles fine. It has two declarative rule conditions in it. Both are very simple, examples:
- !this.Shutdown
- this.Runtime == null
The project builds correctly without error or warning, however when I run the application it fails with the exception: error 1342: Activity 'whileNotShutdown' validation failed: Can not find the condition "Shutdown not requested".
In the other application I am using a more complex ruleset in policy which generates the following exception: error 1398: Activity 'Defaults' validation failed: Can not find the rule set "Rule Set1". Check if rule set is defined in the rules file.
I have tried removing the .rules file and recreating it by recreating the two rules and that did not help.
The question is: What is wrong that is causing this error?
Some things I have tried:
Placing the workflow rules in the larger workflow makes no difference to the issue.
The issue is effecting all workflows in the solution now (even those that used to work).
Using a code rule condition doesn't have the same problem - the issue is related to the rules file somehow.
Rebuilding workflow didn't help
Declarative workflow rules are not checked by the compiler so there is no help there. When you reference 'this' in rule it means the workflow. So your properties Shutdown and Runtime must be declared at the workflow level. I presume the Runtime refers to the WorkflowRuntime and that is kind of unusual, and not recommended, to have inside of your workflow so there may be a design issue here.
Eventually found the cause - it was caused by spaces in the class name, which causes the rules file to have spaces in it, which seems to cause the issue.
For example this will cause the error:
alt text http://img512.imageshack.us/img512/661/clipboard01wdu.png
However this will not:
alt text http://img140.imageshack.us/img140/9366/clipboard02t.png