Posts Tagged ‘2010’

Useful SharePoint script to restart SharePoint services and IIS

Friday, December 2nd, 2011

A SharePoint developer’s life is filled with many things, but one of the most common is the old faithful iisreset, coupled with a reset of the Timer Service and the Admin Service. When you’re working on timer jobs, it can get tedious quickly to have to  keep resetting things.

So I’m sharing a useful batch script I knocked together to do it for you. It will perform three functions – restart the SharePoint 2010 Timer Service, the SharePoint 2010 Administration Service and do an IISReset. It will prompt you if you want to do each of them, and if you don’t reply within 5 seconds automatically do it.

Simply save it as a .cmd file, and then create a shortcut to it, and put that shortcut on your start menu/quick launch. Restarts ahoy!

Enjoy.

@echo off
@echo Quick SharePoint services restart - from www.thorntontechnical.com
@echo Stopping Sharepoint services...

:P1
REM - SharePoint timer service
CHOICE /C:YN /M "Restart Timer Service?" %1 /T 5 /D Y

if ERRORLEVEL ==2 GOTO P2
if ERRORLEVEL ==1 GOTO A1
:A1
net stop "sharepoint 2010 timer"
net start "sharepoint 2010 timer"
:P2
REM - SharePoint timer service
CHOICE /C:YN /M "Restart Admin Service?" %1 /T 5 /D Y
if ERRORLEVEL ==2 GOTO P3
if ERRORLEVEL ==1 GOTO A2
:A2
net stop "sharepoint 2010 administration"
net start "sharepoint 2010 administration"
:P3
REM - reset IIS
CHOICE /C:YN /M "Reset IIS?" %1 /T 5 /D Y
if ERRORLEVEL ==2 GOTO END
if ERRORLEVEL ==1 GOTO A3
:A3
iisreset -restart -noforce
:END
echo Finished. Thanks. Have fun.

More fun with deploying Document Sets via XML

Thursday, September 15th, 2011

To finish a set of posts about the fun I’ve had in deploying document sets as XML content types, here’s a fun little bug vagary I encountered. In the video walkthrough, there’s a section on deploying the custom WelcomePage to your site, and provisioning some WebParts automatically to that page.

You achieve this in the Elements.xml file of your WelcomePage module by including some <AllUsersWebPart>> sections. Within those tags, you enter the definition of the webpart, and you can reuse the built-in webparts.

(Hint: to get at the required definition for built-in SP webparts, find the webpart in the Webparts Gallery in Site Settings, save a copy of the file to your hard drive (as a .dwp file) and then open that file in Visual Studio. You get the required info. Neat.)

You can then deploy your feature, and assuming you’ve covered all the bases your Document Sets, with custom Welcome Page should be deployed. But here’s a problem. Let’s say you make some changes to it, and redeploy the feature. You may experience one of a series of behaviours:

1) None of your changes are displayed
2) Your changes are displayed OK
3) You end up with multiple webparts on your custom Welcome Page.

It’s the third issue I tripped over, and it seems to occur if/when you manually deactivate and reactivate your feature (using the “deploy” feature from VS doesn’t seem to cause this.) It makes some sense – the Elements.xml file says “add these webparts to this page”. Assuming you’ve not added any FeatureDeactivating event receiver to remove the webparts when the feature is deactivated, well, you’ll end up with lots of webparts on the one page.

This being the case, how do you actually go about getting rid of the extra webparts on the page? Retracting the solution doesn’t help. You could completely bin your site content type, site or even site collection. That would probably do it. But it’s a bit drastic. The alternative? Update the database manually. You can decide if this is more drastic than the previous options.

To be clear, you should never, ever, on any account, ever, manually hack the SharePoint content database!

But if you want to do it, here’s how:

(more…)

Updating declarative XML content types

Thursday, September 15th, 2011

Becoming a SharePoint developer is always a journey – every new day you spend doing something, the more you learn. More often than not, the more “little subtleties” you uncover about the great wide SharePoint platform. I recently tripped over one such example. This “issue” is not new in SharePoint development – it certainly goes back as far as MOSS2007, but unless you’re actually doing it, it’s not something you’d instinctively just know.

Creating content types via XML Visual Studio

As soon as you start building SharePoint solutions of any real size and complexity, you’ll quickly learn that creating fields and content types via the UI, or SharePoint Designer, is not a great solution. For instance, there’s no supported way to move a SPD designed solution from e.g., Dev to Live – that is, with SPD, you design directly against live. This can be OK for initial deployments, but as soon as the system has data in and you need to start potentially breaking things, this is not a good place to be in. The alternative to this is develop Visual Studio solutions and features, which are deployable pretty much wherever you’d like. You can define fields and content types in XML, and when you’re finished, package it all up and deploy. Simple, right? Well, no, not necessarily – as I mentioned recently, this process is not without its bugs and issues.

I’ve deployed a few solutions in this way, and was (until today) singing the praises of deploying content types via XML, thinking how wonderful it was to have the flexibility to build in dev, test and then deploy (i.e. what you can’t do with SPD). And of course, if you make any changes, you can update your solution and hey presto, nice neat update.
(more…)

Visual Studio 2010 Workflow + Infopath 2010 forms – troubleshooting

Monday, March 28th, 2011

Microsoft markets that Sharepoint Designer workflows are directly exportable to Visual Studio workflows. And in many ways, this is absolutely true. It’s trivial to create a .wsp from an SPD workflow and import it to VS. However, if you then inspect the workflow that has been created for you, a little concern would not be underestimated. If your SPD workflow was what you wanted, then you could be reasonably confident that its VS version would do the same job. But presumably your reason for importing to VS is because you need more control over the workflow in the longer term, in which case, you’re likely to be left underwhelmed by what the import process creates for you. Imagine creating a webpage in Microsoft Word and you’ll get the drift.

So when faced with a similar proposition, recreating the workflow in Visual Studio from scratch immediately became apparent as the best solution. After all, the intent and purpose of the workflow was clear; recreating it in VS ought to have been a doddle. However, to complicate matters, the SPD workflow used Infopath edit forms. This turned out to be easy in SPD, but non-trivial in Visual Studio. Getting an Infopath form to register with a VS workflow project requires various items, that VS may not do automatically for you.

(more…)

new SPSite – FileNotFoundException

Wednesday, February 2nd, 2011

It seems to me that every SharePoint developer, at some point in their career, will encounter this particular error. It’s one of those infuriatingly obtuse errors that could be caused by a multitude of different issues – either individually or cumulatively. In my case, I was in the middle of developing a SharePoint timer job and I had a particular piece of code that I wasn’t too sure about, and so wanted to test very quickly, over and over again – without the rigmarole of deploying/retracting solutions, hunting through Central Admin to run the job, etc. I just wanted to run this particular section of code against the SharePoint object model and see what happened. As is a common technique for this, I started up a fresh Console Application project, pasted in my code and figured that would be enough.

I was quite wrong and have spent the best part of the last 3 hours just trying to get the console app working. Since it was a standard C# console application, I added a reference to Microsoft.Sharepoint (14.0) and a using statement for the same assembly. The start of my code was the generic way just to get “in” to my SharePoint instance:

using (SPSite siteCollection = new SPSite(“http://sharepoint/”)) {

but when I then started debugging, it fell over on that line, with the “FileNotFoundException”. The web application and a site collection at that address definitely existed. Deploying a SharePoint solution in the usual way, worked. Running as the identity of the application pool, worked. So the key problem was in my own “Dev” account that I use to log in to the Dev machine.

So, it was off to Google for some advice. I won’t rehash everything I went through to get it working, but if you’re suffering from a similar issue, then you could start looking in any of these areas.

  • Is your devenv running as Administrator?
  • Does the process that your devenv/vshosts are running under have sufficient privilege to the Sharepoint farm? (Consider Site Collection admin, and possibly Farm Admin)
  • Does the user account have required privileges to the actual databases on the SQL Server?
  • Minimum of read/write on all content databases (common practice to give db_owner)
  • Read/write/db_owner main Config database and Administration Content database
  • WSS_CONTENT_APPLICATION_POOLS role on Config and Admin databases
  • Is your code compiled in 32-bit mode when you’re running on a 64-bit machine?

As it stands, I can’t be certain which of these “solutions” fixed the problem due to the fact that I tried them in various orders and did or didn’t restart various services/devenv/etc. throughout. But a combination of the above sorted me out – hopefully it can help you too. If there are any other common causes/solutions to this issue, feel free to leave them in the comments.

Some helpful links (check especially the comments in some of these):