1

I've been suffering through an issue I haven't managed to find much documentation on over the past several weeks as I've begun working on my first custom workflow project. I have a workflow solution deployed to the farm with a single feature which is activated on a single SharePoint site instance. Whenever I want to make a change to the workflow, I deactivate and uninstall the feature, then retract the solution and redeploy, but the following always occurs, no matter if I retract and deploy the solution using Visual Studio 2010, stsadm, or the SharePoint Management Shell:

  • Any time my workflows are activated by the System Account when an item is created or changed, the previous codebase is used to run the workflow. That means the changes I've made have taken no effect.
  • Any time the workflows are activated manually using the Workflows form under "Start a New Workflow," the updated codebase is used to run the workflow. The changes I've made appear to work just fine.

How do I completely root out the previous version of the solution? I've already read through this article detailing the same scenario, but this solution is deployed to the farm and the guidelines there were unfortunately no help, even if I changed the parameters to stsadm so that it did not target a web application. I've also enabled "Restart Web Server" on the package and set "Always Force Install" to "True" on the feature when using Visual Studio 2010's deployment.

Improve this question

3 Answers 3

Reset to default
1

Ultimately I believe this problem may be resolved by running iisreset to cycle the web server. Until that is done, the previous version of the library seems to live inside a temporary folder created by SharePoint and will not be updated until the restart occurs. There is a small check box in the package designer for Visual Studio 2010 which reads "Reset Web Server" which should likely be checked when deploying the solution, although I personally ran iisreset to be certain the service cycled entirely.

Improve this answer
1

A little extra explanation on lthibodeaux's answer:

.NET (so sharepoint as well :-D) uses a JIT compiler, meaning it will load assemblies into the AppDomain when the app starts.

Have a look in your Windows Directory in the .NET install folders (i.e. C:\Windows\Microsoft.NET\Framework64\v4.0.30319). This folder contains a Temporary ASP.NET Files folder. (So it's not SharePoint that creates the assembly "copies", but the (ASP).NET runtime!).

In it you will find JIT compiled assemblies, satellite (resource) assemblies etc. for each ASP.NET web app running on that machine. (P.S. delete the contents of this folder to make IIS recompile the assemblies used in an AppDomain)

The above is also the reason why a first visit to a recycled / restarted ASP.NET (and especially SharePoint) web app will take longer, seeing as .NET is "creating" and loading all the asselby code into the AppDomain.

A process (i.e. w3wp) will keep referencing an assembly (compiled copy) loaded on app start, UNTIL the process is terminated and restarted.

Improve this answer
0

You do not need to reset iis (as in iisreset), all you need to do is recycle the application pool of the web applications the package is being deployed to. When you deploy a package using stsadm this happens as part of that process (on deploy when the stsadm -o execadmsvcjobs command is run.

Restarting the application pool is also not constrained to deploying custom (code) workflows. It is all farm (non-sandbox) packages. Sandbox packages run in a separate process and not w3wp worker process.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.