While saving a workflow using SharePoint designer on a SharePoint site, I get the following error:
Server-side activities have been updated. You need to restart SharePoint Designer to use the updated version of activities.
Steps to recreate error:
Login to the WFE server hosting IIS and workflow manager, open SharePoint Designer 2013 and login to a SharePoint site.
Access the list using SharePoint Designer 2013, in the workflow section, click new workflow.
In the new workflow dialog, enter workflow details, click save
Error message is displayed as below:
Server-side activities have been updated. You need to restart SharePoint Designer to use the updated version of activities.
After restarting SharePoint Designer, the saved workflow is not seen in the site/workflows or list/workflow section.
Workaround
When the above steps are repeated while accessing the site via SPD from any other box besides the WFE/Workflow manager host server, the error is not encountered and its possible to save/publish workflows.
Notes
Workflow Manager 1.0 is installed.
The site has been registered with Workflow manager using Register-SPWorkflowService cmdlet.
Any clue on why is this happening?
Copy Microsoft.SharePoint.WorkflowServices.Activities.Proxy.dll assembly to WebsiteCache folder (%USERPROFILE%\AppData\Local\Microsoft\WebsiteCache{Site Name}\15.0.0.4745)
http://www.jrjlee.com/2014/10/server-side-activities-have-been-updated.html
Experienced with Windows 8.1
During setup/configuration of a remote SharePoint Server on Windows Server 2008 R2, I managed to install Workflow Manager on my client Windows 8 machine while following instructions erroneously as I was supposed to do this on the server.
I accomplished what was necessary with Workflow Manager on the server, but never removed this from my workstation client. After searching through google a ton, I kept finding this page and eventually realized the fix:
Since workflow manager is designed for server edition of Windows, this simply shouldn't be on your client that you are attempting to use SharePoint Designer on to create workflows with.
I was using SharePoint Online with SharePoint Designer 2013 and ran in to this issue when trying to create a workflow. I uninstalled the Workflow Manager as recommended and it started working. Workflow Manager was most likely installed when I installed Visual Studio 2015. I am on Windows 10.
Update WorkflowManager and WorkflowManagerClient to CU4
Uninstall Visual Studio
Uninstall SPD
Deactivate Distributed Cache
Delete WebApplications (Except Central Admin)
Run CMD commands:
cd "%APPDATA%\Microsoft\Web Server Extensions\Cache"
del *.web /S /Q "%APPDATA%\Microsoft\Web Server Extensions\Cache"
cd "%USERPROFILE%\AppData\Local\Microsoft\WebsiteCache\"
rmdir /S /Q "%USERPROFILE%\AppData\Local\Microsoft\WebsiteCache."
mkdir "%USERPROFILE%\AppData\Local\Microsoft\WebsiteCache"
dir "%APPDATA%\Microsoft\Web Server Extensions\Cache"
dir "%USERPROFILE%\AppData\Local\Microsoft\WebsiteCache"
Run iisreset
Restart VM
Create Web Application
Install SPD
Execute iisreset
Restart VM
Open SPD
Go to "Options > Application Options > General Tab" and let -only
the following- boxes checked: "Show status bar" and "Show catalog
lists and system objects" > OK > OK
Open the site via SPD
Create new Workflow 2013 via SPD
Thats what I did. Hope it helps.
I faced the same issues. The workarround was to install sharepoint designer on another machine than the host machine where sharepoint, workflow manager and visual studio is installed. That fixed the issue, however i faced other problems later, specially with workflow 2013, specially when trying to save them as workflow templates, or publish them as global workflows. So i tried to fix the original issue in order to avoid differences between both environements and to be sure to have the right permissions. After long days i found another workarround for my problem:
When comparing the folders
user profile\AppData\Local\Microsoft\WebsiteCache\sitename\version of both environements, i figured out that there were a lot of dll's missing on de developement machine. So I have copied them from the working machine, then i was able to edit workflows 2013 on the buggy machine.
By updating the SharePoint designer you can resolve this issue. Click on the link and follow all the steps mentioned on the blog.
1 Install Microsoft sharepoint designer service pack 1
2 install the update for the sharepoint designer
Enjoy it will work.
Your answer is here
Related
I have developed a custom sharepoint 2010 action and succesfully deployed through wsp
ADD-SPSolution, Install-SPSsolution + modification of web.config for port 80 and deployment was successful and I see this action also in Designer and action can be used within workflow.
I need to deploy it to Sharepoint 2013 foundation workflow platform 2010, so I used the same process, deployment to GAC, GlobalDeployment, compatibilityMode 14,15.
I also added authorized type to web.config, but I can not see activity in sharepoint designer 2013.
I created developement server Sharepoint 2013, I have created the activity on this new dev server and succesfully deployed to dev server, but despite this, I can not deploy it to production server as mentioned at the begining of this paragraph.
The only difference is that developement servers (SP Foundation 2010/2013) use PORT 80 /HTTP/ and production server uses port 443/HTTPS.
Is there any difference when deploying to this web aplication with SSL/TLS configured? Do I need to modify somehow source code? Or installation process?
I have lost 2 days and I have seen probably all forums in the web...
Kind regards and thank for help upfront.
This might be silly, but have you activated the feature that contains the workflow activity on the particular production site? SPD reads from the site.
Close SPD.
Check your %LOCALAPPDATA%\Microsoft\WebsiteCache and %APPDATA%\Microsoft\Web Server Extensions\Cache - clear out the site that your SPD has cached and then restart - see if SPD brings down the site definitions again.
I Try to deploy a application using Microsoft Release Management for Visual Studio or better known as "InRelease". But i face unexpected Problems using the MSI-Deployer.
The deployment fails with the flowing error:
Setup.msi XXX139W8 10/1/2014 11:19:18 AM 00:00:00 Package location '\\Server\drop\Application\Build_20140930.5\Setup.msi' does not exist or Deployer user does not have access. Failed
First suggestion(incorrect Path) is not the case, i double checked that.
So why does my Deployer user not have access to my server? And how to fix that?
I tried out running the DeploymentAgent as Administrator, as Local Service adding XXX139W8$ permissions to the drop folder, running as domain user with admin rights on the drop folder.
Sadly the deployment agent is totally unreachable or the error mentioned above shows up.
Here are some system specs:
TFS and RM Server run on a Windows Server 2012 R2 with SQL Server Express 2012 Installed.
The client i am Working on uses the Release Management Client for Microsoft Visual Studio 2013
The Target Machine is a Windows 8.1.
The deployer user is defined in the MS Deployment Service, ensure that this account has access to your Drop folder. I give the domain\EVERYONE account read access to the drop folder so that anyone can read the data
I resolved this Problem.
The cause was that i specified a File as Package (quite confusing if you try to deploy a single msi file) but the Component should only specify a Folder "Package".
The deployment agent fails to access the Folder (Setup.msi) and fails with the error i showed above.
Then i wasted hours in trying to fix my access problem, because if i enter the "Package location" everything worked fine._.
I need on clarification that I have a development server where according to the policy I shouldn't login and run the commands.
So, is there any way that I can deploy my solution using central admin just like as we did through power shell commands.
I search before, but I couldn't get the satisfactory answer?
If you're deploying new wsp, you can run Powershell command "Add-SPSolution -LiteralPath ". If it's an existing wsp, you should retract the existing wsp first before adding the updated wsp. You can check if the wsp either deployed or not in the Central Admin > System Settings > Manage Farm solution. You can also deploy the SP Solution(once added) in Central admin. After deploying it, make sure to restart the Timer Service. Here's how you can deploy the wsp using powershell.
you can setup powershell to run remotely and then use powershell commands to deploy the wsp.
Check this link on enabling powershell to run remotely Configure Remote PowerShell in SharePoint 2010
What kind of solution are you deploying? Is it a farm or sandboxed solution? You can deploy your solutiions via VS2010 without having to login to the server. Or are you referring to items that needs to be deployed via GAC?
I developed a sample application in visual studio 2010. I created an Empty SharePoint Project and gave the local site url for debugging. Checked "Deploy as Farm" as the trust level of the SharePoint solution. Added a visual webpart and also a class to the solution. I am able to build and successfully run the application using visual studio. In my local machine am using SharePoint foundation 2010 to debug the SharePoint application.
Now i want to deploy this application in the SharePoint server 2010 which is in a virtual machine.
1. I copied the .wsp file of the application i created to the virtual machine.
2. From the central administrator in the VM I created a web application and the site collection.
3. Then using Site Actions -> Site Settings -> Solution(Galleries), choose the .wsp file for uploading. it showed a "Warning: You should only activate this solution if you trust this solution. An activated solution can read, modify and delete your data. " and the activate button is disabled.
Then I tried to do same in my local machine on a different site collection. Here Activate button is enabled but when clicked it threw exception
Server Error in '/' Application.
This solution contains invalid markup or elements that cannot be deployed as part of a sandboxed solution. Solution manifest for solution 'aee60282-765d-4c9f-b67a-5981f18a6d3b' failed validation, file manifest.xml, line 10, character 4: The element 'Solution' in namespace 'http://schemas.microsoft.com/sharepoint/' has invalid child element 'TemplateFiles' in namespace 'http://schemas.microsoft.com/sharepoint/'. List of possible elements expected: 'FeatureManifests, ActivationDependencies' in namespace 'http://schemas.microsoft.com/sharepoint/'.
What could be this error?
The "TemplateFiles" element refers to items that will be copied onto the web server. This is allowed for farm solutions (which are deployed via CentralAdmin), but is not allowed for sandboxed solutions (which are deployed via the Solution Gallery).
When you deploy your wsp with visual studio, you deploy it as farm solution.
When you deploy your wsp from site settings into solution galery, you deploy it as user solution (sandbox solution) with some limitations :
first, avoid using out of the box visual webparts, it's prohibited !
Deploy your wsp by writing powershell script.
A good starting point here :
patrickboom.wordpress.com/2010/05/31/using-powershell-to-deploy-sharepoint-solutions-wsp-2/
Le_Fredo is correct here, when attempting to deploy a WSP file into the site collection directly under the site settings, you won't be able to. I found this article from microsoft to be extermely helpful
http://technet.microsoft.com/en-us/library/ff607688(v=office.14).aspx
Just went from TFS 2008 to 2010 at a client site and now wondering what happened to the TFSBuild.proj files from the TeamBuildTypes folder. I've already got the builds and drops working and now I need to get the old deployments working again. We used to do this with AfterBuild targets in the TFSBuild.proj. That mechanism seems to have moved or disappeared in 2010.
Can anyone point me to an article or describe how the deployment options have changed in 2010?
Specifically, I need to support running psexec to install and enable Windows Services on remote deployment targets and I need to deploy some web sites / web services to remote IIS nodes as part of the automated builds.
EDIT: Just found this: http://blogs.msdn.com/jimlamb/archive/2009/11/03/upgrading-tfs-2008-build-definitions-to-tfs-2010.aspx I'm more than a little taken back by the breaking changes between 2008 and 2010. I'm gonna need advice on how to deploy remote sites and services in the new default build process template mechanism.
Check out Vishal Joshi's PDC talk on Deploying Web Applications with VS 2010 and MSDeploy. On his blog, you'll also find tips on building MSDeploy packages with MSBuild. You can run psexec from your MSBuild script or, potentially, from a customized build process template. With TFS 2010, you can use MSBuild and Windows Workflow to solve your build automation problems.
Alternatively, you can use the "Upgrade" build process template and continue using your TFSBuild.proj file. This is the default behavior for upgraded build definitions for backwards compatibility. In that case, your build is still primarily driven by MSBuild with just a thin workflow to allocate an agent and run MSBuild.
Another option is to use TFS 2010 Build Agent on the server that you deploy to. This is how Visual Studio Lab Management deploys.
I have written a blog post about this: Continuous deployment with TFS 2010 Build Agent