Process ‘SPUCWORKERPROCESS.exe’ is not running

Recently , I tried to create a sand boxed solution for SharePoint 2010 using Visual Studio 2010. I have created a “Hello World” web part. When I pressed F5 in Visual Studio 2010, I got the following warning message even I have already got Microsoft SharePoint Foundation User Code Service started.

---------------------------
Microsoft Visual Studio
---------------------------
Unable to attach. Process 'SPUCWORKERPROCESS.exe' is not running on 'COMPUTER-NAME'.

Do you want to continue anyway?
---------------------------
Yes No
---------------------------


After using google.bing.com, I have found out the Sand boxed solution does not work on DC(Domain controller).If you are using SharePoint on DC, the following Windows PowerShell command would need to be run to enable Sandboxed Solutions.

Reference: http://ybbest.wordpress.com/2010/03/13/process-spucworkerprocess-exe-is-not-running/

Read Full Post »

Sharepoint: Features and Packages {Definition}

The Feature is a container of various defined extensions for SharePoint. It’s a set of XML files which are deployed to web front ends that can be bundled in site definitions or individually turned on in SharePoint sites. Put simply, a feature is something you activate on either the farm, web application, site collection, or a site. By activating a feature on any of these four scopes, you add new things into SharePoint that are logically bundled together by you. What can those things be? Things such as new WebParts, list definitions and instances, event receivers, or content types.

Package is where you specify what gets packaged into the final .wsp your Visual Studio solution will produce. This may contain features and other assets that are not directly a part of your features. By double-clicking the package node, you can view the package designer which lets you decide what gets deployed as a part of your .wsp.

 

Read Full Post »

Sharepoint Trick: View the actual error message

When you’re writing code for SharePoint, and your custom code runs into an error, by default SharePoint will log that error and it will present the user with a generic error through the browser. In order to view the actual error message through the browser, you will need to make three changes to your web.config:

1. Change the SharePoint\SafeMode\@CallStack attribute to true.
2. Change System.Web\CustomErrors\@Mode attribute to Off.
3. Change System.Web\Compilation\Debug mode to true.

Making these changes will allow you to both attach to W3WP.exe and run your code in debug mode, and to view actual error messages through the browser. Whenever I run into an error in SharePoint programming, I usually look at the  following four places in sequence:

1. The browser window, assuming I have made the above-mentioned web.config changes.
2. The ULS logs available at 14\Logs. You may need to tweak the logging level in central administration to view your actual error message. Also, you should try out this fantastic tool at ULS Viewer.
3. The event log, especially for WCF-related errors.
4. The IIS log and tracing facilities.

If all these steps fail, I use the techniques described in this article SharePoint Applied: SharePoint 2007 Ninja Debugging

Read Full Post »