I have written a sequential workflow in SharePoint on our development environment. After testing, we decided to deploy this workflow as a feature on the staging environment. We did the following:
copied the strongly named assembly to the GAC using gacutil
copied feature.xml and workflow.xml to WebServerExtensions/12/templates/features/someFolder
installed feature (stsadm command)
activated feature (stsadm command)
All worked exactly as planned and the workflow behaved correctly. The problem was, we decided to change something in the code (a message was not very self explanatory), so on the development machine we updated the message as requested and rebuilt the project.
The problem is, we cannot seem to find a way to correctly get rid of the previous version of this workflow/feature.
To deploy the upgrade, we:
deactivated and uninstalled the feature (stsadm commands), removed also from GAC.
increased the version of the assembly
performed steps 1 to 4 from above.
When using the workflow we are still getting the first message, we cannot find a way to get the new message to be displayed.
What are we missing?
All the workflow logic "lives" inside the code assembly you are running. This means you can delete the old version of DLL (don't change assembly version numbers, use AssemblyFileVersion instead) from the GAC and replace it with the new version.
Be aware, though, that if you have changed the workflow in the designer, running instances of the old workflow version will "freeze" and never finish. Ask your users to finish their running WF-s before you upgrade the code.
It seems that the problem was in the Workflow.xml file.
Because I incremented the AssemblyFileVersion, and only replacing the dll in GAC did not work, I checked the two xml files: Feature and Workflow to see which one did not recognize the new dll (if the case). The workflow.xml file had a reference to the old version in it. I updated that, installed and activated the feature again, and it is working perfectly now.
Thanks for your support!
Related
I was in the middle of working on some minor code changes when all of a sudden I started getting the following error on startup:
A host error has occurred during startup operation '78d5d8fd-e81c-4707-87ca-6b801430fef1'.
[2021-01-08T13:02:40.279Z] System.IO.FileSystem: Could not find a part of the path 'C:\Users\schiefaw\AppData\Local\AzureFunctionsTools\Releases\3.17.0\workers'.
I looked at the path and found everything exists until I get to "workers".
I, of course, assumed it was something I did, so I backed out all changes to no effect. Then I uninstalled visual studio and all Azure products I could find and reinstalled to no effect. I created a new user (since the file it is looking for is in my user folder) to no effect.
I then created an entirely new instance of a windows virtual machine and installed the development environment to no effect (same error).
I am completely stuck on this. Does anyone have any ideas on what I can try next?
Thanks!
I think this is a bug from that 3.17 release. But here is a work-around: you can add the "workers" folder (empty folder) and it should work. Another way if you have a copy of the previous version (such as 3.16.x), you can copy the content to the 3.17.0 one.
You can read more here: https://developercommunity.visualstudio.com/content/problem/1304718/azure-functions-local-debugging-broke-with-3170-up.html
I'm building a test website in azure, I'm getting an issue in Azure site, Where as my local code published to a folder and setup in IIS is working fine. I work on vs2015. code written in C#. Error is below one. Could not load file or assembly 'System.Web.WebPages.Razor' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. Please help in this. Thanks
cr
Is the dll in your solution set as copy local? (go to references, right mouse button and then properties.)
If not set it to copy local.
Alternatively:
Do you use different versions of the dll in your solution?
Then set a bindingredirect to the latest version and be sure to use the correct one in your application. http://blogs.msdn.com/b/thottams/archive/2007/01/30/introduction-to-versioning-and-bindingredirect.aspx
Adding to what RoteS answered, if you are using MVC on VS2015 and you are deploying to Azure by Continuous Integration, why not reference the MVC Nuget package instead? You won't need to commit or copy that DLL around, and Azure (Kudu) will handle the package restore for you when it's deployed.
Thanks for your replies.
I've tried by two options
1.Setting copylocal = true
2.Instlling Microsoft.AspNet.Mvc -Version 5.2.3
But still the problem was there. It works on Local system when published.
But it was not working in Azure. seemed to be some publish issue.
Finally as 3rd step,
I've taken all the mvc related dlls and copied to Bin mannually, referred from this location instead of the package location.
Set the option - copyLocal = true
It worked fine :)
Thanks.
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.
I have several custom web parts that I'm in the process of deploying to production. During this process I've found a handful of minor things that need to be tweaked in the various parts. To deploy the new code I create a new solution package, deactivate then delete the features, retract then delete the solution, then do it all again in reverse order with the new package. Needless to say, this can be time consuming. Is it necessary to completely remove a web part in order to upgrade it, or can a web part/feature/solution be upgraded in place?
It depends on what exactly is changing in your solution. There is an stsadm operation specifically for upgrading solutions, but it has some limitations as far as what it takes care of for, most notably the removing of old features and adding of new features. However, if all your new functionality exists in the webpart DLLs, running a solution upgrade will deploy your changes without need for you to do anything further.
http://msdn.microsoft.com/en-us/library/aa543659.aspx
We have used Visual Studio 2008 extensions for Windows SharePoint Services 3.0, v1.3 - Mar 2009 CTP. It has given us some problems, but when you get used to it and make sure that you do things in the right order it works.
http://www.microsoft.com/downloads/details.aspx?FamilyID=FB9D4B85-DA2A-432E-91FB-D505199C49F6&displaylang=en
This tool automates the retact / delete / deploy / activate .... job.
Another thing that we try to do is to keep as little functionality in the web parts as possible. Move what can be moved to separate dll's, then it is often possible to upgrade just by coping in a new version of the dll.
If you are making minor changes to your web parts then you can just replace the DLL's if the assembly version remains the same.
Of course use some discretion here about what is a minor change and won't break anything.
See this topic for how to use FileVersion and AssemblyVersion correctly.
Basically you keep the AssemblyVersion the same for minor updates while the FileVersion changes with ever compile.
This is exactly how Microsoft do it with things like Microsoft.SharePoint.dll - the AssemblyVersion is fixed at 12.0.??? while the FileVersion changes with every hotfix/service pack.
Oh - I just read the "Production Part" of your answer this shortcut may be more appropriate for Dev/Test rather than QA/Production
use this
stsadm -o upgradesolution -name "WSPName.wsp" -filename "c:/WSPName.wsp" -immediate -allowgacdeployment -allowcaspolicies
and then run the sharepoint job
stsadm -o execadmsvcjobs
from the other hand you can update the dlls using SharePoint PowerShell command
Set-location "C:\Users\Documents\WSP"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Users\Documents\WSP\wspcustom.dll")
Can anyone suggest the best deployment approach for VSeWSS 1.2 based development?
I have been working with this for more than 6 months now.. has anyone tried using WSPBuilder for this purpose?
I Personally prefer using stsdev (http://www.codeplex.com/stsdev). I've used both WSPbuilder and STSDEV. Stsdev offers some development project templates that you create using an stsdev gui, not like the standard project templates you create using new > project.
The stsdev projects has got a Rootfiles folder, which corresponds to the '12 hive' on the destination server. All the files you put into Rootfiles folder and subfolders, is automatically added to solutionpackage.ddf and manifest.xml, so you dont have to worry about editing these files and compiling them using makecab.
Another great thing that stsdev offers is build targets, like build, deploy, redeploy, Refresh Assembly in GAC, retract and upgrade. So stsdev projects automatically compiles the binaries, builds the .wsp package, and runs the stsadm commands according to the build type. You can customise the behavior of the build targets if you like, by editing the Microsoft.SharePoint.targets located in the DeploymentFiles folder of the project. As long as you are only working on the code, Refresh Assembly in GAC is a very fast build method, and you can see the changes in sharepoint immediately after.
An disadvantage of stsdev is if you use source control, the manifest.xml and SolutionPackage.ddf if not checked out, are read only, and will result in a compile error (i usually check out all the files in DeploymentFiles folder when working on a project). So you have to check out these files before building. Another thing is that it takes all the files under the Rootfiles, including the hidden vssver2.scc files if you are using source control. The project still builds and deploys without problems, but the files are in the wsp package, and copied to the '12 hive' on the destination server.
I think that compared to WSPbuilder, stsdev lets you customize just about anything of the development project, which i haven't been able to do in WSPbuilder.
You should do yourself a favor and look at VSeWSS 1.3. See Kirk Evans' blog for a good video overview: http://blogs.msdn.com/kaevans/archive/2009/03/13/sharepoint-developer-series-part-1-introducing-vsewss-1-3.aspx.
Major downside could be that it requires Visual Studio 2008.
I have been a STSDEV advocate, but am now leaning towards VSeWSS 1.3. My suspicion is that other WSPBuilder and STSDEV users will feel the same over time, but I haven't finished my evaluation of it yet.
We have always used WSPBuilder. This is best if you are looking to create wsp's.
It also provides a VS Add-in. You can build, deploy, upgrade etc. right from VS. Provides VS templates like Blank features, Web Part Feature, Feature with Receiver, Workflow feature, Event Handler, Item Template etc...
We manage 20+ projects with WSPBuilder
As Kirk Liemohn points out, you really should upgrade to VSeWSS 1.3. We took lots of customer feedback and there's lots of new features for developers in this version.
It includes quick deploy commands for deploying just the new binary or just the files into the SharePoint 12 folder structure. It also runs on x64 OS with Visual Studio 2008. It has command line support.
Available here
I prefer WSPBuilder as well. I don't have any problem with not being able to configure WSPBuilder the way I want it. In the latest version you can override its settings for each project or developer individually should you want to.
There is also a great add-on to WSPBuilder called SPVisualDev (codeplex.com/spvisualdev). Among other features it provides templates for adding ASCX files and it automatically pushes down files you have put in your project 12-hive folder from VS into the real 12-hive folder.. A huge time saver for me.
One downside to VSeWSS 1.2 was the lack of deploy to bin support. 1.3 adds that, but I haven't gotten it to work with referenced assemblies.
I've switched to STSDev 2008, a spinoff of the original STSDev with bug fixes. I've been working with the main contributors to add documentation to the project on CodePlex, but it's had 1900 downloads in little over a year.
I have used VSeWSS 1.2 and 1.3 and it does make deployment pretty easy. The question I had was, what do you guys usually do if you wanted to distribute the Web Parts to a customer administered SharePoint server.
Do you just take the Release folder and tell them to run the setup.bat script? Do you package it differently? Do you create custom installers?
VSeWSS 1.3 CTP is out now, and does have command-line support. That being said, the extensions are IMHO--and based on currently using them for a very large, very complex project--a pain in the rectum for the following reasons:
Every time you open a solution of extensions-enabled projects, you will have to sit and wait while the VSeWSS wheedles through each and every project, checking structure and trying to repackage each solution. The wait seems to grow exponentially with every extensions-enabled project you add to the solution. Given all of the waiting already included in doing SharePoint development inside a VM, the wait can be excruciating.
While VSeWSS is making its way through the projects, no indication is given of any work going on; VS simply becomes unresponsive.
Every time you close your VS solution with extensions-enabled projects, VSeWSS does the whole operation over again. Given that, by this time on my current project I'm usually 10 or so hours in the seat, and the last thing I want to do is wait longer to go home, this process is worse that excruciating (if that's even possible.) Most of the devs on our team just go to Task Manager and kill the devenv.exe. process rather than waiting.
We've had a very bad time of it trying to use the current (CTP) version of the extensions to do an integrated build. We've been having a number of problems using VSeWSS from the command line to do build and packaging of all of our projects.
In brief, use STSDEV. Setting up the folders is kind of a pain, but once you have everything scripted out, you're pretty much set.