I’m working with Windows Workflow Foundation 4.0 and I need to assign a specific ID to my WorkflowApplication instance. Back in WF 3.0 and 3.5, we could manually set the workflow ID when starting it, which was really handy for tracking purposes.
Now in version 4.0, I can’t figure out how to do this. The Id property seems to be read-only and there’s no constructor that takes an ID parameter. I’m wondering if there’s maybe some special key I can use in the input dictionary when creating the WorkflowApplication.
Has anyone found a way to control the workflow ID in WF 4.0? Any help would be appreciated.
You’re right - WF 4.0 totally changed how workflow IDs work. WorkflowApplication auto-generates a GUID for the Id property and you can’t override it.
I hit this same problem when migrating old workflows. Instead of fighting the WorkflowApplication’s Id, I used workflow input arguments to pass my custom tracking ID.
Just create a workflow argument like “CustomTrackingId” and pass your ID through the input dictionary when you create the WorkflowApplication. Use that custom ID for tracking and logging.
You could also use a correlation handle or store your identifier in the workflow’s context. Either way, you get the tracking you need without battling the framework.
WorkflowApplication.Id is really just for the runtime’s internal stuff now. Better to treat it as an implementation detail and roll your own tracking system.
This workflow foundation tutorial covers arguments and data flow - should help with the custom ID approach.
yeah, ran into the same frustation when i upgraded. i ended up storing custom IDs in a static dict (or db table) that maps WorkflowApplication.Id to my biz ID. not pretty, but it works great for trackin and you can still query by your custom identifier.
The WorkflowApplication constructor takes an optional Guid parameter for instanceId, but it’s barely documented anywhere. Just do new WorkflowApplication(workflow, yourCustomGuid). I found this after digging through the API docs when I hit the same problem. Works great in production - we needed consistent IDs for workflow correlation across service restarts. Make sure your GUID is actually unique or you’ll get runtime conflicts. The framework uses your ID instead of generating one.
