I have a dev environment with VS2010 and SP2010 installed in and a production environment running SP2010. I have created a state machine workflow in VS2010 and deployed to my dev environment for testing. Now that I have things working the way I want I need to deploy the workflow into my production environment.
In VS2010 I have selected "Package" and taken the resulting .wsp file and attempted to deploy them on my production site by going to Site Settings -> Solutions and uploading. I have also activated the solution within the solution gallery and ensured that it is also activated in "Site collection features". However, the workflow does not show up in Site Settings -> Workflows and I can't seem to out what to do. I have also tried deploying the .wsp through stsadm addsolution.
What am I missing when deploying a custom built workflow packaged as a wsp?
Your first method of deploying solution by uploading it to Site Settings -> Solutions applies to only sandboxed solutions. Are you sure yours is a sandboxed solution ?
The second method which you tried is a global method of deployment through stsadm.
I would suggest, start from scratch i.e. clean up your local Solutions gallery. and use stsadm operations addsolution, deploysolution and activatefeature to deploy this workfow.
Note that deploysolution and activatefeature can also be done via UI.
Related
A website with webjob not deploying to Azure.
I am having an issue getting a website with an associated webjob console application to deploy using continuous deployment via Visual Studio Online. I am using VS2013 with update 4 and latest Azure SDK.
The website, and the associated webjob, will publish to Azure using direct publish for Visual Studio and works perfectly, so I am confident the publish settings are fine.
The solution will build and work locally fine.
The solution, once checked in, will build and (seemingly) deploy fine in VSO (using CI) and Azure notes the build was successful and shows it as 'Active deployment'.
However, the website and associated webjob will not be updated.
When I have browsed the deployed files after the VSO build and deploy on Azure, all that is happening, is the binaries of the console app are being copied into the bin/ folder of the website.
None of the website files are being updated. It is almost as if it is deploying the wrong project!
If I remove the Webjob and just deploy the website, it will build and deploy fine through VSO - the website will update.
It is adding the webjob that causes some issue with the deployment via VSO.
I am confident all steps are correct to add the webjob to the WebApp, with the correct webjobs-list.json being added to the webapp and webjob-publish-settings.json to the Console app - as I said, publishing the website (with the webjob) direct to Azure works perfectly, and both the site and webjob get updated.
I have searched post after post and tried all manner of things, but none have worked.
Given the fact this published fine direct from VS, and also that the build is completing, it would suggest that something is wrong with the VSO Build Defintion.
My first guess would be to change it from building the solution to instead building the web project only, but this does not seem to work.
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set.
I have been battling this for a couple of days now an I'm a bit stumped!
This also happens if you have a static website being deployed using a Visual Studio solution via VSO with an automated build - unless the Visual Studio project / solution containing the website is changed then the actual site contents will not be redeployed.
I think your hunch that it's deploying the wrong project is correct. If you have multiple "deployable" projects in your solution (and the console app is considered deployable, as this is one way you can host/deploy a webjob), you need to tell Kudu which one to deploy.
You can control it adding a new setting under "app settings" on the "configure" tab for the webapp.
The setting you want is Project and it's a relative path from the solution root to the .csproj file of your web project.
Alternatively, you can specify the setting in a custom .deployment file.
Relevant Kudu documentation here
From the documentation:
You can specify the full path to the project file. Note that this is not a path to the solution file (.sln), but to the project file (.csproj/.vbproj). The reason for this is that Kudu only builds the minimal dependency tree for this project, and avoids building unrelated projects in the solution that are not needed by the web project.
Here is an example:
[config]
project = WebProject/WebProject.csproj
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set
That's the root case of problem.
You can't have SingleFolder as it sets the OutDir which mess up with web job packaging.
I had to introduce a wpp.targets files in each of my web app project to create the publish package to a particular path (using PackageLocation)
So, let each project have that and set the setting to AsConfigured (or Per Project) instead of SingleFolder.
See this
I created a wsp solution that which create 2 custom workflow actions. I want to deploy it to my 2 servers farm which have an application server and a webfront end server. SPF Web application is not activated on the app server.
My visual studio solution goes like this:
-One project which create the dll, where actions code is.
-One project which create the wsp package, feature, etc. The package references the other project as additional assembly.
My problem is, when I deploy my wsp package with Deployment Server Type WebFrontEnd, the feature is only installed on the wfe and I can't activate it. I can't see the feature in the manage feature page (the feature is farm level). When I change the Deployment Server Type of the package to ApplicationServer, I get the following message:
"This solution must be deployed to application servers, not front-end Web servers. It cannot contain a resource that is scoped to a Web application."
I did some tests. I removed the additional assembly from my package and then I can deploy my wsp solution as ApplicationServer type (but can't use my custom actions..). Then I created a dummy dll with nothing in it, added it as additional assembly to my sharepoint package and I realised I can't deploy my wsp as ApplicationServer type again.
So, can I reference an additional assembly from my wsp solution and still deploy as ApplicationServer type??
How can I deal with this? Any idea?
I did it again, I've been looking for answers for this all day, I finally post something here and one hour later, I got myself the answer. Here it is anyway.
I deployed independently both solutions using 2 wsp packages. One simply deploys the dll into the gac (and is ApplicationServer), the other one is using it without deploying it itself (and is WebFronEndServer). Now I have to deal with making sure the first one is deployed before using the other one... Feature activation dependency should do it.
Regards.
I have made my first webpart using WSPBuilder. When I try to deploy it using STSADM, I get an error stating access is denied. I am an admin on the machine (well it's a VM).
Also, with WSPBuilder, do I need to change the config files (I assume no as the point of the tool is to automate this)?
Thanks
There could two reasons for your problem
Even though you are the admin of the system you may not have privilege in central Administration. So login in the system with the user name of sharepoint administrator and try to deploy it.
There may be a problem in the way you created the WSP. if you deploy webpart using WSP then there is no need to edit the config file manually. Recently I have created a blog which explain how to create simple webpart, creating WSP and deployment. If interested check it out http://www.allaboutmoss.com/index.php/2010/03/22/hello-world-sharepoint-webpart-for-beginners/
It sounds like you don't have enough permissions to add the webpart. What OS are you on? If it's Windows Server 2008 R2 etc you will have to run the command prompt as an administrator or turn off UAC for administrators. As for the config WSP builder will create you a file called solution.txt which contains the Id for your solution. For more control over what it is doing you can add a WSP Builder config file to your project called "WSPBuilder.exe.config". An example one can be found in "C:\Program Files\WSPTools\WSPBuilderExtensions".
Go to --> RUN--> SERVICES.MSC--> check the following service is started or not.
Windows SharePoint Services Administration, if not pls start this service. if the wsp is deployment done. go center admin--> Operations -->Global Configuration -->Solution management . This page has a list of the Solutions in the farm. check ur wsp in this list.
Why does Microsoft suggest using WSPs for production deployment in SharePoint? What are the other methods for production deployment?
WSPs are suggested as they are deployable 'bundles' of functionality, whether that is an Event Handler, Application page or Web Part. By using WSPs you can create and test them in Dev and then roll them out to production once they have been tested. A WSP can be easily managed from the Solution store in Central Administration
It is possible to deploy features by putting the necessary files into the 12 Hive (SharePoint ambiguously named folder), but this requires manual changes to the system. If you have several Web Front Ends (WFEs) in a web farm, then you would need to manually maintain each of them. When using WSPs for deployment, the updates can be deployed to all Servers from one location.
WSP files are designed for deploying functionality to SharePoint in a consistent manner. Although technically they don't do anything you can't do by just copying files to the server, relying on manual deployment is a great way to put the system into an inconsistent state. It may work at first, and even be quicker/easier in some cases, but sooner or later you will permanently break your production environment.
The wsp was specifically designed for the purpose of packaging and deploying SharePoint 2007 solutions. That's why Microsft suggests using it!
While there are a few limitations to it, it's by far the best way to deploy solutions into a prod environment.
You should use WSPs to deploy in SharePoint.
I have used this WSP builder and it's makes your life a little easier.
http://www.codeplex.com/wspbuilder
I have the exact problem of not getting any webcatalog entry for a webpart if i deploy via stsadm. The project of this webpart is generated with vsewss and build with it. The very webpart entry can be accessed if its deployed through vsewss' "deploy" command. But i have to make the deploy process with stsadm because of an automation reason.
any ideas ?
thanks a lot.
koray.
You need to activate the features when deploying via stsadm, VSeWSS does that for you and hides the need while you are developing.