My SharePoint development environment is my laptop. In this environment I have developed various kinds of web parts and have been deploying them to my local instance of SharePoint. So of course, the day came when I wanted to deploy my web part to an actual server. (why else would you be doing development!)

Many of the blogs I read say that you need to develop and deploy on the actual server. This strategy has never made sense to me. And, of course, the strategy wasnt where my confusion ended. There are any number of references for doing this. MSDN Library: Create Visual Web Parts for SharePoint 2010 for creating a web part. Technet – Deploy Solution, and Technet – Deploy Feature for deploying. Essentially the steps are to (using Visual Studio 2010)

1. Create a web part
2. Deploy
3. Copy solution file (.wsp) to the SharePoint server
4. Add the solution to the web site using the SharePoint Management Shell console.
5. Deploy using either the SharePoint Management Shell or Central Administrator.

So I build and deploy my solution and copy to file to the server. You can find the solution file by opening the Solution Explorer in VS2010 and checking the “Project Folder” property of your project. For me this path is “C:\Users\tlisko\Documents\Visual Studio 2010\Projects\mywebpart\”.  Then open the “\bin\Release” folder where you should find one “.dll”, one “.wsp”, and one “.pdb” file of your solution.

I logged in to the SharePoint server as the administrator, then added and deployed the solution just fine. Opening my SharePoint site I inserted the new web part into a page. I decided that I wanted to make a change to it. No problem, just make the change in Visual Studio and repeat the deployment process.

Doesn’t work that way, at least not completely. I copied the file, but since the old wsp file was there I had to use a different file name. No big deal. Then I tried to execute the “update-spsolution” cmdlet in the SharePoint Management Shell. That seemed to run fine. When I opened the Central Administration web site the solution status indicated that it was updating(deploying). Funny thing, the status never changed! To me that meant something wasn’t working – perhaps had I waited longer it would have worked, but I don’t think so.

So, I cancelled the deployment and tried to retract. Once again, once status was set to “retracting” there was no completion. I then removed the new web part from the web site where it was deployed. Tried retracting the solution again, but no luck. Ok, now I’m getting serious! 🙂 Going back to the SP Management Shell I see that the the solution appears as deployed. So – I run the “uninstall” cmdlet but, of course, it says the solution is deployed. Run again with -AllWebApplications flag. Seems to work. Now I want to remove the solution. When I run that cmdlet I get an error about only machine administrators being allowed to create service job definitions!

Ok – now what. It made sense to me that the admin user I was logged in as needed to be owner of the content databases in SQL Server (though I wouldn’t have been able to deploy in the first place if that wasn’t the case). SQL Server permissions are fine. But, I observed that the SQL Agent wasn’t running. Not sure if that would help I started it anyway. What else can I do? Well there is a “force” flag in the “Remove” cmdlet. Yup, same results as before. Still get the error.

When all attempts fail, try rebooting…That made things worse  – SP wasn’t working anymore! (for reasons I do not wish to disclose on the grounds it will incriminate me!) I got the SP site working again, but naturally the problem of removing the solution remained.

Doing a web search I found a blog by JPPinto.com that addressed this very error! As unlikely as it seemed the cause of all this pain was due to the infamous User Account Control (UAC). Once I disabled that everything worked!

Just another day at the office…