We have just experienced this exact issue.  We have had to redownload and reimplement unfortunately, as it doesn't seem there is any other solution.

Hi,

One solution I can suggest is to add reference to Mediachase.Commerce.Workflow.dll, and then override the activity you want to have custom implementation. Then you define your own xoml file and register it in ecf.workflow.config. In this way when you update Mediachase.Commerce.Workflow.dll you won't need to update the code manually.

Regards.

/Q 

Hi, we experience issues with the current setup too currently we are maintaining a git repository of the releases from which we branch . This allows for a 3-way merge when we get new releases and makes this process a little easier. 

The syncing of workflow code and NuGet releases is not ideal. New code is released onto http://world.episerver.com/download/Items/EPiServer-Commerce/episerver-commerce-8-tools-and-code-samples/ against a major revision i.e. 7.5 or 8 with a release date rather than a update revision i.e. EPiServer - update 58 (there is also no archive that I am aware of). As such unless we note the release dates we dont know that theres been a modification. When a new update is released we are having to take an educated guess if its safe to update based on the listed changes of that update, forum posts and the date of the latest workflow source release.

I understand that modifiying such code whilst expecting updates is going to be somewhat painfull but it would be easier if an archive of the released workflow code versioned by the major release and update increments was available and if every update had a paired code release removing any ambiguity.

Creating a public repository from which releases were tagged and clients could branch\make use of externals to include the source and leverage 3 way merge when integrating your changes into what are likely heavily modified workflows\activities would be even better.

Andrew

Currently the latest source release appears to be from January and we have integrated this against update 57 (we required another fix so had no choice even though it may not match). This made assumptions that we are not missing breaking changes which would have been in the compiled versions compared to the released source and that if it was workable we could catch up with the fixes with a subsequent release. If we assume this was the correct version, since then update 58 has been released seemingly without a new release of the source. Update 58 specifically comments about changes to the workflow to accomodate a promotions change so we know we will be missing changes if we upgrade but do not know the impact.

I hope there is a release page I am unaware of but at the moment we are unable to upgrade and have an expectation of functioning code aftwards unless we first decompile the latest released dll's and diff them to see whats actually changed.

Andrew

Thanks for the feedback.  I was thinking Andrew, that we could just put it in a github repo but hopefully the replacement for workflows will mean this is no longer an issue.  For now I have added everything to our repo and will do a compare each time.  I like Quan's idea but not sure we are ready for that route yet.