Setting Up Your Sharepoint 2010 Development Environment
Setting Up Your Sharepoint 2010 Development Environment
Before you can start SharePoint 2010 development, you need to set up your development environment. There are some new twists with SharePoint 2010 when it comes to the development environments that it supports. One of these twists is that SharePoint can run, for development purposes, on a desktop OS such as Vista or Windows 7. The other twist is that SharePoint, at the time of writing, supports only the .NET Framework 3.5, which will require some extra configuration on your part when you’re building applications and could cause some gotchas if you forget to target the 3.5 framework.
There are a couple of system requirements you should be aware of when setting up your development workstation and also some choices that you need to make. First and foremost, SharePoint supports only 64-bit hardware. If you have a 32-bit desktop or server, then you’re out of luck. You will need access to 64-bit hardware to get started with SharePoint 2010.
Operating System Requirements
Once you have 64-bit hardware, you can decide which operating system you want to run. SharePoint supports Windows Server 2008 with SP2 or above or Windows Server 2008 R2 for server operating systems and Windows Vista or Windows 7 for desktop operating systems. If you are using a desktop operating system, be aware that the prerequisite installer does not work with those operating systems. Instead, Microsoft will be shipping a script that will perform the operations that the prerequisite installer performs such as downloading and installing required DLLs.
Virtual or Physical?
Whether to install SharePoint virtually or physically on your machine is always a tough question. Most times, the answer will depend on the operating system you want to run for your guest OS and also whether you want to trade off performance for flexibility. Let’s step through each issue in a little more detail.
In terms of the host OS, if you don’t mind using Windows Server 2008 as your primary operating system, then you will have many options for installing SharePoint, whether that’s physical or virtual, because Windows Server 2008 supports Hyper-V. Note that you need to make sure you have hardware that supports Hyper-V. Then, you can decide whether you want a physical or virtual deployment of SharePoint. If you’re a developer, virtual is the better way to go, except when you want to do capacity planning or large-scale testing, if your production environment is physical.
If you prefer to run Vista or Windows 7 as your operating system, then your choices are more limited, because these desktop OSs don’t support Hyper-V. This means that, if you want to virtualize, you need to use VMWare or Sun’s Virtual Box, because Virtual PC and Virtual Server don’t support 64-bit.
Once you have the right virtualization technology for your host OS, the question becomes whether or not to virtualize. Virtualization provides a lot of nice features, such as portability, ability to roll back changes, different environments on a single host OS, and so forth. There are many positives to virtualization. The only negative is the performance cost. To run a virtual environment, you need to give the guest OS and SharePoint a few GBs of memory, and you definitely need a fast disk, preferably 7200 RPM and above. If you don’t, performance will be terrible. So, if you have the necessary hardware and you’re developing solutions, then your first choice should be to virtualize. The new boot to VHD capabilities in Windows 7 and Windows Server 2008 R2 makes it easy to build a dual-boot system that is virtual.
An exception to the virtualization choice is if you don’t mind running SharePoint on your client OS. You will need to make sure to turn off the services when not in use, as they can use a lot of memory and you do not want them hogging your machine when you’re checking email or working on other projects.
SQL Server Version
SharePoint supports multiple versions of SQL Server, both 2005 and 2008. The main difference is in the SQL Server features, as most SharePoint features work across both versions. The only exception will be using the new Remote Blob Storage and SQL Server FileStream technology, which is supported only in SQL Server 2008. You can decide whether you want SQL Server Express or another version of SQL Server for your installation and development.
.NET Framework Support
As mentioned, one potential gotcha is that SharePoint supports only the .NET Framework 3.5. With VS 2010, you get the .NET Framework 4.0. Because the .NET Framework supports installing and running side-by-side, this shouldn’t affect your SharePoint development installation. However, when you develop your solutions in VS, you must remember to target the 3.5 framework, because VS will usually target 4.0 by default if it is installed out of the box. If you don’t target 3.5, then you will get errors that can be difficult to track down, as they can appear to be problems with your code rather than framework targeting problems.
Some Things to Check: CPU Type
When you change your targeting from .NET 4.0 to .NET 3.5, you may find that Visual Studio changes the CPU type from AnyCPU to x86. This will break your application if you are running a WinForms or Windows Presentation Framework (WPF) application that runs out of the SharePoint context. So, it’s a good idea to check not only the framework version that you are targeting, but also whether the CPU is x64 or AnyCPU. Otherwise, you may get weird errors that are difficult to track down, for example, a return of null when trying to get the local farm from SPFarm.
Troubleshooting SharePoint Solutions With Debugging, And Testing
As a developer, you write perfect code the first time, right? No one does. This is why debugging, testing, and troubleshooting are critical components in any development lifecycle. With VS 2010, the tools and techniques for doing this against SharePoint are infinitely better than in its predecessor. Having capabilities like one-click deployment and debugging, the new developer dashboard, better logs, and customizable testing will make development and debugging a lot easier. Let’s take a look at these new capabilities.
VS supports the ability to deploy and debug your SharePoint solutions by setting a breakpoint and starting the debugger. The first time you debug a SharePoint solution in VS, VS will ask you if you want it to automatically configure your web.config on your SharePoint server to support the debugging session. Allowing VS to do this will save you a number of steps and will remove the propensity to make mistakes setting this up. Note that you will need administrative permissions to your server, and that you should not do this, if you can avoid it, on your production systems.
VS will take three steps on your behalf. First, it will turn on the call stack in web.config by adding the line CallStack=true. Second, it will disable custom errors in ASP.NET so that you will receive detailed error information if there is an error, using <customErrors mode=“Off” /> in your system.web section. Lastly, VS will enable compilation debugging, which makes ASP.NET compile your binaries with additional information to make debugging easier using <compilation debug = “true” />.
Besides making these changes, VS performs a number of steps when you start the debugging session from deployment to attaching the debugger:
1. Runs your predeployment commands that you can customize.
2. Creates your WSP using MSBuild.
3. If you are deploying to the farm, it recycles the IIS application pool to free resources.
4. If you are deploying a new version of an existing solution, it will deactivate your feature, uninstall your existing solution, and delete the existing solution package on the server. If you have feature receivers, your code will be triggered.
5. Installs your new solution and features onto the server.
6. If you are building a workflow, it installs your workflow assemblies.
7. Activates your Site or Web features. For Web Application or Farm features, you need to activate these yourself. Again, your feature receivers will be triggered.
8. For workflows, it associates your workflow with the list or library you selected in the Workflow Wizard.
9. Runs your postdeployment commands.
10. Attaches the debugger to the SharePoint process (w3wp.exe) for Full Trust solutions and to SPUCSPUWorkerProcess.exe for Sandboxed Solutions.
12. Launches your browser and displays the correct SharePoint site for your solution.
A few notes about these steps. First, if you are debugging a workflow, you need to trigger the workflow through the web browser, the client applications, or custom code that you have written. VS will not automatically trigger your workflow. In addition, for workflows, any additional assemblies you reference must be in the global assembly cache (GAC).
Second, if you are working with feature event receivers, don’t have VS activate that feature event receiver for you. Instead, manually activate your feature event receiver so that it is in the same process as the debugger. You can disable activation in your deployment in your project settings.
Last, because SharePoint builds on many layers below it, such as Windows Communications Framework (WCF), you may want to enable advanced debugging in your VS environment. To do this, go into the registry editor, find [HKEY_CURRENT_USERSoftwareMicrosoftVisualStudio10.0SharePointTools], and change the DWORD value for EnableDiagnostics from 0 to 1. If the DWORD value does not exist, create it as a new DWORD value. When you set this value, you will see in the output window in VS all the information that VS is getting from SharePoint via the stack trace. Figure 2-19 shows debugging inside of Visual Studio.
This article is excerpted from chapter 2 "Developer Tools For Sharepoint 2010 " of the book Professional SharePoint 2010 Development by Tom Rizzo, Reza Alirezaei, Jeff Fried, Paul Swider, Scot Hillier, Kenneth Schaefer (ISBN: 978-0-470-52942-3, Wrox, 2010, Copyright Wiley Publishing Inc.)
About the Author