SharePoint Development Environment Set-up For Custom Solutions

Introduction

This document aims to explain which permissions are required to provide users for custom solution development using Visual Studio. When we develop and debug solutions using Visual Studio, we need to provide some permissions in SQL server as well as in SharePoint Server. Development using SharePoint Designer is required to provide some permissions in the specific sites. Hope this document will help you always whenever you set-up a new farm for custom solution development.

Initial Setup

My environment is running over three servers (Active Directory, SQL Server, and SharePoint Server) where I have tested all permissions.

In the SharePoint Server, I have also installed the following tools for the following purposes.

1. SharePoint Designer: For creating and modifying SharePoint sites, lists, libraries, pages and so on
2. Visual Studio: For developing and debugging all kinds of custom solutions
3. Fiddler: It is helpful while developing using REST API
4. ULS Viewer: For monitoring ULS log files in SharePoint Server

Action

Basically, there are two types' custom solutions available in SharePoint Development like Sandboxed and Farm. Before starting development, it is very necessary to understand the difference between them. Following differences are taken from MSDN¹.

Sandboxed Solutions: Sandboxed solutions, which are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe), run code that can only affect the site collection of the solution. Because sandboxed solutions do not run in the IIS worker process, neither the IIS application pool nor the IIS server must restart. Visual Studio attaches the debugger to the SPUCWorkerProcess process that the SPUserCodeV4 service in SharePoint automatically triggers and controls. It is not necessary for the SPUCWorkerProcess process to recycle to load the latest version of the solution.

Farm Solutions: Farm solutions, which are hosted in the IIS worker process (W3WP.exe), run code that can affect the whole farm. When you debug a SharePoint project whose Sandboxed Solution property is set to "farm solution," the system's IIS application pool recycles before SharePoint retracts or deploys the feature so as to release any files locked by the IIS worker process. Only the IIS application pool serving the SharePoint project's site URL is recycled.

For any kinds of solution development, we have to give some permissions in SharePoint server as well as in SQL server.

Permission for Sandboxed

SharePoint Server

1. User must be in Administrator Group: You can follow the below steps:

• Go to Administrative Tools
• Double click Computer Management
• Expand Local Users and Groups from left side
• Click on Groups. You will see all local groups in right side
• Double click on Administrators. Then click on Add button and add your desired user

Now you can open your Visual Studio and create a Sandbox solution, but you will get the following error while validating your site for debugging.

The local SharePoint server is not available. Check that the server is running and connected to 
the SharePoint farm. You may try re-running the custom tool by right-clicking on the file 
in the Solution Explorer and choosing Run Custom Tool.

The name 'InitializeControl' does not exist in the current context

The Site URL property of the project does not contain a valid URL. To ensure that designers work 
as expected, set the Site URL property of the project to the URL of a SharePoint server. 
Close all designers, and then open them again.

The main reason is insufficient permissions in Database but Web Application host header could be an issue if you use public/private DNS URL instead of local URL. URL issue can be fixed editing host file only. Host file locates at the following path:

C:\Windows\System32\Drivers\etc

Let's assume our web application URL portal.atishlab.com, then add the following entry at the bottom of the host file.

127.0.0.1 portal.atishlab.com

That's all for public/private DNS. Now you must have to fix the database permission issues.

SQL Server: Login in the SQL Server and set the following permissions using SQL Server Management Studio.

1. Expand Security and then expand Logins
2. Right click on the Logins and select New Login...
3. A new will be opened. Type login name and click Search button
4. Click on Server Roles from left side and check the following roles:
   • dbcreator
   • public
   • securityadmin
   • sysadmin
5. 5. Now click on the User Mapping and map the user in the following databases:
   • SharePoint_AdminContent
   • SharePoint_Config
   • "Content database of your web application"

   

That's all for Sandbox solutions. Now you can debug and deploy your solution by attaching SPUCWorkerProcess.exe process. Click Debug --> Attach to Process...

In some cases, I noticed that sometime break point does not hit. In that case, if it happens, then right click on the project ----> hover mouse on Debug ----> Click on Start new instance. I found that it works always.

Permission for Farm Solutions

For farm solutions, you have to provide the same permissions as Sandboxed. There is an extra database permission that you have to provide, otherwise break point does not hit, I found.

• Expand Databases ---> Your content database ---> Security ---> Users
• Right click on your user and change membership as db_owner

Now you can debug and deploy your farm solutions by attaching W3WP.exe process. Sometimes, you may need to Recycle Application pool manually. There is an extra work for Timer Jobs (Though it's a farm solution) otherwise break point does not fire, I found. For Timer Job, you have to attach OWSTIMER.exe instead of W3WP.exe process. Finally, add your user in WSS_ADMIN_WPG local group to make your break points working.

Note: For debugging Time Job, follow the below steps. I found that it works always.

• Right click on your project and deploy
• Restart SharePoint Timer Service
• Attach OWSTIMER.exe process
• Go to Central Administration ---> Monitoring ---> Review job definitions ---> "Your Timer Job" -- Run Now

Your break point will hit within a few seconds.

Points of Interest

I have tested everything in my above mentioned environment and found everything working. Please feel welcome to let me know in the comments section if you can optimize those permissions or if I missed mentioning anything.

References

1. Differences Between Sandboxed and Farm Solutions - MSDN