In this chapter you'll learn everything you need to start developing on the new SharePoint 2010 platform. In particular this chapter will explore in detail the primary development tool: Visual Studio 2010. You'll learn the strengths and weaknesses of SharePoint Designer 2010 and how it compares with Visual Studio.
The topics covered in this chapter are
SharePoint developer support
Debugging your code
Installation scenarios and how to set up your development environment
Visual Studio 2010 and the SharePoint tools
Developing on 64-bit computers
Not all developer tasks can be accomplished using visual tools. The SharePoint SDK (software development kit—for SharePoint it's a collection of help files, manuals, and examples) is a great collection of tools, code examples, and documentation. This chapter will introduce the SDK and highlight the most useful tools.
SharePoint projects tend to become large. Visual Studio Team System and the Team Foundation Server are good bases for team development. We recommend, for optimal output from multiple developers, that you establish a shared environment based on a SharePoint farm. You'll learn how to set up and use such an environment and how to incorporate desirable software development practices such as continuous integration and rapid deployment.
This book assumes that you're already familiar with SharePoint—at least SharePoint 2007—and its underlying technologies and platform. However, it begins by clarifying some matters that might be unclear even for an experienced developer.
First and foremost, SharePoint is an application platform. An application platform is a software development foundation that consists of an operating system, one or more frameworks, and interfaces that applications use to accomplish tasks. Primarily, an application platform has the user in mind. Microsoft SharePoint is an example of a very good application platform.
The platform is a reliable, reusable, and well-documented set of products, technologies, and tools. While some of these modules are highly usable out of the box, others may be replaced, customized, or modified according to specific needs. The platform components are dedicated to specific services they provide and that other components can consume.
An application provides business capabilities to its users via its components. A platform is classified as having a service-oriented architecture (SOA) if the components provide a standard way to communicate via services. The services use providers that act as a transparent layer between the underlying data source and the service. SOA has evolved predominantly by using XML-based web services. However, these services are not limited to XML, and modern platforms may support many other data transmission standards. An application platform provides many ways to access the services, and this is true for SharePoint. As a developer you not only consume such services, but also create services, customize existing ones, and install providers appropriate to the business cases.
The production environment for the SharePoint application platform consists of the following:
Windows Server as the common server platform. For SharePoint 2010, Windows Server 2008 (64 bit) is the minimum requirement. As parts of the operating system, you have to have access to the following:
SQL Server 2005, SQL Server 2008/2008 R2, or a corresponding version of SQL Server Express edition. SQL Server must be a 64-bit platform regardless of the actual version.
There are several ways to set up a development environment. It depends on whether you're on a team or you're a single developer, and whether you work for an enterprise or a small shop. First, consider your own development machine. The whole process of coding, packaging, installing, and running a SharePoint component takes time.
When developing for SharePoint, the first impression is often that a new 64-bit development machine is required to run the server and the development environment together. We'll examine this scenario and its advantages and disadvantages in the next sections. The simplest option is to keep your client machine and work against a remote server running SharePoint. It makes you independent of local configuration requirements and reduces your cost outlay, particularly for your first, simpler projects. In Chapter 2, we explain what types of development are possible with SharePoint. As a preview, the different outputs are
A legitimate concern as a developer on a disconnected machine is, "Won't my SharePoint projects require dependencies from SharePoint assemblies?" The most common development targets, Web Parts, have no such dependency. You simply derive your control from the ASP.NET WebPart
class and use the SharePoint web services to access data. While this is not the most powerful tool set, it's easy to set up and maintain.
For a more professional and versatile environment, consider using a remote development configuration.
Whatever configuration you choose, you should try to develop on your own server machine. That's the only way to get the Visual Studio 2010 F5 deployment feature. It makes your development cycles shorter and increases productivity.
For a team-working arrangement there are several extra prerequisites. SharePoint 2010 is a 64-bit–only product. That means your whole environment must run on 64 bits. If this is overkill, there are alternatives. We strongly recommend setting up a virtual server on a physical machine, such as Hyper-V or VMware on Windows Server 2008. Create your virtual development machines there and access them remotely. A cheap Windows 7 machine will suffice as such a client computer. SharePoint projects occasionally crash the server during heavy development. Re-creating a virtual machine is much easier than losing your whole personal computer.
The following installation scenarios list the options you currently have to install SharePoint as a core component of a development environment. The 64-bit prerequisite limits the choice of operating system to the following:
Windows Server 2008 x64
Windows Server 2008 R2 x64
Windows Vista x64
Windows 7 x64
These descriptions are two-pronged, including instructions for the clients and the SharePoint server.
The following list is the minimum needed for a working SharePoint development system. Depending on your specific needs, you may need to install additional components. The order is obligatory—meaning that SharePoint must be installed before Visual Studio. The help files are, of course, optional.
The server is now ready to act as a powerful development machine.
The following section details the more complicated process to install SharePoint on Windows Vista or Windows 7. These instructions are intended for professional developer workstations and follow Microsoft's recommendations for such a development environment running Visual Studio 2010 and SharePoint Server 2010 on the same machine.
There are two limitations with this development environment: you cannot create a SharePoint 2010 farm, and SharePoint 2010 must not run in production on Windows Vista or Windows 7.
This installation can be disabled through Active Directory group policy if your organization wishes to prohibit SharePoint 2010 installations on Windows Vista or Windows 7 machines.
Be sure to run all the installation steps as a local machine administrator.
The recommended machine configuration is
x64-compatible CPU (64 bit)
Windows 7 x64 or Windows Vista SP1 (or SP2) x64
2GB of RAM minimum (4GB recommended)
Start with the SharePoint.exe
file for SharePoint Foundation or SharePoint Server 2010. Extract the files from SharePoint.exe
with the following command line. A user account control (UAC) prompt might appear at this point.
SharePoint.exe /extract:c:SharePointFiles
This extracts all of the installation files to your hard drive. Use a folder you can recognize easily later, such as c:SharePointFiles
. This allows you to repeat the installation steps without extracting the package again and enables access to the configuration file that needs tweaking, to permit installation on Windows Vista or Windows 7:
c:SharePointFilesFilesSetupconfig.xml
Add the following line to the end of the config.xml
file:
<Setting Id="AllowWindowsClientInstall" Value="True"/>
The complete file should now look like this:
<Configuration> <Package Id="sts"> <Setting Id="SETUPTYPE" Value="CLEAN_INSTALL" /> </Package> <DATADIR Value="%CommonProgramFiles%Microsoft SharedWeb Server
Extensions14Data" />
<Logging Type="verbose" Path="%temp%" Template="Microsoft Windows
SharePoint Services 4.0 Setup *.log" />
<Setting Id="UsingUIInstallMode" Value="1" />
<Setting Id="SETUP_REBOOT" Value="Never" />
<Setting Id="AllowWindowsClientInstall" Value="True"/>
</Configuration>
If you miss this step, you will see an error dialog, as shown in Figure 1-1, when you run the installation.
Before running the SharePoint setup, install the prerequisites described in the "Installing Required Windows Features" section of this chapter.
These three components are not required on Windows 7, because they are included with the operating system. For Vista with no service pack or SP1 only, they are required.
First, install the .NET Framework 3.5 SP1 from http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe
.
Second, install PowerShell x64 from www.microsoft.com/downloads/details.aspx?FamilyID= af37d87d-5de6-4af1-80f4-740f625cd084
.
Third, install the Windows Installer 4.5 redistributable from www.microsoft.com/downloads/details. aspx?FamilyID=5a58b56f-60b6-4412-95b9-54d056d6f9f4
.
The SharePoint 2010 prerequisite installer does not run on Windows Vista or Windows 7. You must manually configure the necessary Windows features and install the requisite software. The requirements include enabling almost all the IIS (Internet Information Services) features. Instead of checking almost all the boxes in the IIS section in Windows Features, you can enable them programmatically. At a command prompt, paste in the following command (for clarity the options are shown line by line, though you're supposed to enter them as a single line):
start /w pkgmgr /iu:IIS-WebServerRole; IIS-WebServer; IIS-CommonHttpFeatures; IIS-StaticContent; IIS-DefaultDocument; IIS-DirectoryBrowsing; IIS-HttpErrors; IIS-ApplicationDevelopment;
IIS-ASPNET; IIS-NetFxExtensibility; IIS-ISAPIExtensions; IIS-ISAPIFilter; IIS-HealthAndDiagnostics; IIS-HttpLogging; IIS-LoggingLibraries; IIS-RequestMonitor; IIS-HttpTracing; IIS-CustomLogging; IIS-Security; IIS-BasicAuthentication; IIS-WindowsAuthentication; IIS-DigestAuthentication; IIS-RequestFiltering; IIS-Performance; IIS-HttpCompressionStatic; IIS-HttpCompressionDynamic; IIS-WebServerManagementTools; IIS-ManagementConsole; IIS-IIS6ManagementCompatibility; IIS-Metabase; IIS-WMICompatibility; WAS-WindowsActivationService; WAS-ProcessModel; WAS-NetFxEnvironment; WAS-ConfigurationAPI;
This may take some time. When it is finished, your Windows Features dialog settings should look like Figure 1-2.
A reboot is required after the Windows Features update. Next, install FilterPack by running the command:
c:SharePointFilesPrerequisiteInstallerFilesFilterPackFilterPack.msi
This command runs a Windows installer application. There are no configuration steps—it simply installs its contents.
Install Windows Identity Foundation (WIF). This framework was formerly known by the code name Geneva. This is an update package and it's described in Knowledge Base article KB974405. It also has no configuration settings. The SharePoint Foundation needs the Microsoft.IdentityModel
assembly with version 1.0.0.0.
Now you're ready to install SharePoint 2010 using setup.exe
. After the start screen, you must accept the license terms. In the next step, choose Standalone as the server type, as shown in Figure 1-3.
A Complete installation allows you to add more servers. However, this requires access to Active Directory. If you install on a client operating system, this is probably not available. Using a Standalone installation is preferred on a client operating system intended for development purposes.
Click Install Now to start the installation.
When the installer ends, you will be prompted to optionally start the SharePoint Products and Technologies Configuration wizard. With the check box checked, click Close to run it, as shown in Figure 1-4.
The wizard leads you through several steps:
A splash screen outlines the information you might have to provide. Clicking Next displays a warning that installation on a client operating system does not support a production SharePoint environment (see Figure 1-5).
After this a second warning appears—explaining that several services might be restarted—confirm by clicking Yes.
Next, choose "Create a new server farm."
A standalone version runs on the internal embedded SQL server, requiring no further information. Otherwise, SQL Server 2008 Express is used, and you will need to enter the database server name, username, and password.
Let the wizard complete the remaining steps. No additional information is required. After this, Central Administration loads.
If the configuration is successful, you should install SQL Server 2008 SP1. If you install Visual Studio 2010 in the next step, this is not required, as the current release comes with the required service packs for SQL Server 2008 Express.
When it finishes, create a new SharePoint site using SharePoint 4.0 Central Administration under Administrative Tools.
To avoid user authentication prompts, add your new local SharePoint site to the trusted sites list in the Internet Explorer options.
Now install Visual Studio 2010 and the SharePoint development tools. The tools add several useful templates for creating SharePoint objects. The installation is straightforward, though you'll need to restart the computer once in the middle of the installation cycle.
We recommend using Visual Studio 2010 Ultimate for this book (and in general).
For team development, each team member needs access to the same code. Setting up a Team Foundation Server with its source code management feature is part of the solution. Each person should add his or her development machine as a farm computer to the SharePoint installation.
There should be one database server. It can run Central Administration, too. In large teams, we recommend restricting access to Central Administration to one or two people, not necessarily developers. You must ensure that the developers only use tools, plug-ins, features, and even Web Parts that are approved by the administrator to run on the production machine. The benefit is a much smoother deployment process later.
Even on a fast machine, the development experience could be better. SharePoint is optimized for servers, and it runs a lot of background services that are not needed during development, so you could turn them off. There are a few exceptions—for example, when testing a deployment scenario, the SPTimer service might be needed in a farm environment. In the most common installations, such an optimization provides noticeable advantages.
To have the services available when they're needed, we recommend you create a suitable batch file. You can easily start up the server, stop the services, and restart later. Rather than stopping services manually in the Services snap-in and setting them to Manual, run a console command:
c:>net stop <Service>
The following services are not normally required on a development machine (the names are in the form that you'd use them from the command line):
WebAnalyticsService
OSearch14
SPUserCodeV4
SPSearch4
SPTimerV4
SPTraceV4
FontCache3.0.0.0
MSSQL$RTC
ReportServer
mqsvc
MSASCui
ntfrs
OSPPSVC
PresentationFontCache
sqlwriter
SYNCPROC
ExcelServerWebService
Some services might not be installed or may already be stopped, depending on your machine's configuration. You can safely ignore such services.
When creating the batch file, be aware of the inconsistent naming of SharePoint 2010 services using the suffixes "4," "14," and "V4" (in no particular order).
By default, SharePoint compiles using the C# 2.0 compiler. If you create an assembly using the 3.5 settings, you have all features of the C# 3.5 language available. However, if you have pages with embedded code, such as generic handler or web services, the ASP.NET compiler uses .NET 2.0. Features such as the var
keyword will not work. To overcome this limitation, you must extend the settings in the web.config
file. It's recommended to set this on a per–site collection basis to avoid side effects. The corresponding web.config
can be found in the appropriate VirtualDirectory folder of IIS.
First, add the following section anywhere beneath the <configuration>
node:
<system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"> <providerOption name="CompilerVersion" value="v3.5" /> <providerOption name="WarnAsError" value="false" /> </compiler> </compilers> </system.codedom>
This sets the required compiler version to 3.5.
Second, look for the <assemblies>
node and compare carefully the list of assemblies, as shown here:
<compilation batch="false" debug="false"> <assemblies> <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" /> <add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" /> <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" /> <add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" /> <add assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="Microsoft.Office.Access.Server.UI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </assemblies>
The list might look slightly different on your system. You can extend the list if you need other parts of .NET 3.5 in your project. The changes take immediate effect and do not require a restart or an iisreset
call.
SharePoint 2010 opens a new era in developer support. It's moving from being just a powerful platform for collaboration, search, and content presentation, to becoming a developer framework. To increase developer productivity, it comes with tight integration within Visual Studio 2010. The Developer Dashboard gives an in-depth look into the state of the current request and the processing within SharePoint. A rich set of platform services are available for comprehensive data access. LINQ for SharePoint is a fast and reliable data access layer for type-safe access to lists, files, and folders. The business connectivity services allow smooth integration with line-of-business (LOB) systems. The deployment of applications within such a complex environment is just another challenge addressed by the improvements in SharePoint 2010. Team Foundation Server now supports the whole application life cycle. A standardized packaging solution allows easy deployment of your creations.
SharePoint is a very large platform, especially from a developer perspective. It's not just an API (application programming interface) that you can hook into and start coding. Rather, it's a conglomeration of interrelated tools, administration sites, data, database schemas, and more. SharePoint sits on top of ASP.NET, which is another huge framework and another challenge to developers. ASP.NET in turn is built on the .NET Framework—yet another vast empire.
In the application development environment, there is another set of tools, too. Visual Studio is just one of the instruments in a powerful, reliable, and team-friendly development orchestra.
The first question that usually arises when starting development with SharePoint concerns how all these disparate parts fit together. What procedure do you have to follow to get the code running, the debugger watching, and the final application displayed in the browser?
It's helpful to start from the perspective of a web developer. In essence, SharePoint is a web application—a large one, but nevertheless just a web application. Each instance of SharePoint can have one or more web applications, and any number of SharePoint instances may reside in your farm. We'll explain later what roles these parts have. For now, consider a single SharePoint instance and a single web application in it. For this case, the architecture is as shown in Figure 1-6.
If you plan to work with Web Parts, code-behind with ASP.NET application pages, or web controls, you should hook up with the SharePoint object model. (Chapter 2 gives an overview and Chapter 3 contains a detailed explanation of the SharePoint object model.) The object model is used widely throughout the whole book. It is a rich set of classes that perform almost all required actions quickly and reliably. As shown in Figure 1-6, the web application occupies a central position. It builds the context in which your code runs. That means that the object model should primarily work within one web application. It's not intended to span multiple applications, even if this might be technically feasible.
To work on a higher level—against another web application or SharePoint instance, or somewhere beyond the boundaries of a SharePoint farm—use web services or REST-based data access. Web services provide another integration level and an even more reliable way to access your application. Due to the nature of web services, they might appear to perform poorly. It's a question of configuration, hardware, and usage scenarios as to whether the performance matters. As a best practice, we advise using web services and confirming that the required performance is supplied by a particular configuration. Using web services is easy, and the support to integrate them using Visual Studio is excellent. For several SharePoint-based applications, such as Project Server, web services provide extensibility without in-depth knowledge of another API.
When maximum performance is imperative, direct access is recommended if an API is explicitly exposed. That means, for example, when you program against Active Directory's LDAP protocol, the API is a better choice than using LDAP queries. The same applies for the Project Server Interface (PSI), for example. If the data source is supplied by a LOB system that provides either web services or direct database access, Business Connectivity Services (BCS; formerly known as Business Data Catalog) is a good choice. Even here you have an API to program against if the basic features provided out of the box lack power.
Never program against SharePoint's internal configuration or content databases. Even if it seems easy or the objects are publicly accessible, it's bad practice. Microsoft could change the data model, data structure, or internal behavior without warning. In that situation your application will eventually fail and you will have to rewrite it. However, sometimes under special circumstances you might need high-speed read access to the data. Then it's possible to code against the database as long as you strictly use read-only access and monitor schema changes.
When you first explore the SharePoint object model, you might feel lost. It's a vast desert of classes, classes, and more classes. Occasionally, you'll find an interface. As a result, developers tend to ignore the SharePoint object model for small projects and create their solution completely with standalone code. Even for big projects, some software developer teams follow this approach. They start creating wire frameworks, UML diagrams, and class models, and taking other preparatory steps. These methods are appropriate if the underlying framework is just a free programming platform, such as the .NET Framework. SharePoint is different. While it limits the freedom developers usually have, it empowers them by providing a rich infrastructure—an amazing number of functions all ready to use.
Instead of designing a project including the entire basic infrastructure, use the functionality that already exists in SharePoint. Handling the lists within your web application's administration, using the object model, and employing LINQ to SharePoint are much easier than writing it all yourself. You'll find out sooner or later that the object model empowers you and that it's worth learning at least the basic structure, the object hierarchy, and how the objects relate to each other.
SharePoint, like any other platform, has its strength and weaknesses. This book contains a collection of best practices and approved methods of coding, and a few warnings concerning some flaws. Because of the sheer volume of features, no book can describe all parts of SharePoint completely. So in case you get lost or can't find the right information, remember this advice: never leave the object model.
Do not start developing your own infrastructure. Do not start creating features that are supposedly part of SharePoint. Take the time to search and research. Sometimes you won't find the necessary information, either in the book or on MSDN. SharePoint 2010 is new and the documentation is patchy. With the previous versions of SharePoint, some information did not appear at all during the entire life cycle. Worse still, the deeper you dig into the internals and the more you use the features provided by the API, the less information you find. Sooner or later, even the blogosphere will fail and return nothing but garbage. You have to have techniques to help yourself and quickly devise a solution. (We understand the scenario where you're under pressure and your customer is yelling for results.)
This book will explain the API as deeply and broadly as space allows. However, even that will not be enough. We'll even point to the entry points within the official documentation on MSDN. That's not enough either. If you need to know how something works internally to understand how to use it (instead of reinventing the wheel), use a tool like Reflector—it is priceless. Reflector is a free download from Red Gate—originally written by Lutz Roeder—and is able to decompile .NET code and reformat it into a few common languages, such as C#. Figure 1-7 shows Reflector in action.
You can get your free copy of Reflector at www.red-gate.com/products/reflector
.
There are some exceptions, but almost all major parts of SharePoint 2010 are written in .NET, and you can peek into the code and learn the Microsoft internals.
Whatever your intention and whatever sort of code you're about to write, the API is your partner. Using the SharePoint controls and methods is the recommended approach. You can extend, customize, reformat, configure, preset, and generally do whatever you want with the existing components. But never reinvent something and write your own as long as you can find something comparable inside SharePoint. These components fit very well into the platform and they have many useful features. Adopting and changing is almost always better than writing your own from scratch.
Only if you can't find anything usable within SharePoint should you consider backing up a step and trying an ASP.NET component. Imagine a table you wish to use to present some data. First, try the SPGridView
control. It's feature rich, and end users know it because it's the standard control used to present lists. It has such features as sorting and grouping. It's almost public, so you can easily hook into the interfaces and events and customize it. It's there for you. Only after you've experimented with customizing the SPGridView
control and found it inadequate for your purposes should you try its base class, GridView
, from ASP.NET. It might be simpler, but you can add your own features more easily. If even this fails, use the .NET Framework and write your own grid.
Once you have adopted, customized, and modified a component, think about team productivity. Repackage your component as another custom component, add configuration features, and make it installable. Redistribute it in your team and encourage others to make use of it. That way you ensure that your colleagues struggling with the API do not stray from the recommended approach.
SharePoint developers face many challenging tasks. With the appearance of Visual Studio 2010 and SharePoint 2010, some things are easier. The integration is improved and the support for server- and client-side programming is much better than it was in previous editions. With the new possibilities, however, a new level of application programming arises, and things become more challenging again. These challenges include
How to distribute the results—creating and installing packages
How to debug client-side code, especially Ajax behavior
How to handle code issues on the server
How to deal with issues that only arise on the production system (where there is no debugger)
If you develop on a team—and we assume that you do—things are even more complicated. You have to synchronize your work with others, take over their code, or provide yours to others. You must deal with configuration settings, farm maintenance, and the data stored in the shared database.
Having Visual Studio 2010 properly installed might look like the perfect environment to debug the code. We assume that you're already familiar with your IDE. In the section "Introducing Visual Studio 2010's SharePoint Support" is a brief introduction to the basic features concerning SharePoint.
A web application consists of several parts. IIS plays a significant role—each request and response passes through IIS. Debugging the server includes a way to debug IIS to see what data is transmitted from the browser to the server and back. Despite debugging, performance issues often arise. To test your SharePoint application under load, a stress test tool is essential.
If your SharePoint server does not respond as expected and the debugger does not reveal useful results—probably because an internal module beyond your access scope fails—you need more tools. SharePoint hides error message and replaces stack traces, exception messages, and logs with almost useless information. It's primarily designed for end users, and they might get frightened when a NullReferenceException
is displayed (e.g., "Did I lose all my data now?"). In your development environment, you can turn on developer-friendly (and therefore user-unfriendly) error messages by setting the appropriate parameters in the web.config
file:
<configuration> <SharePoint><SafeMode CallStack="true" ... />
... </SharePoint> <system.web><customErrors mode="off" />
... </system.web> </configuration>
However, not all errors throw exceptions, and not all such messages are helpful. You need a plan for how to find the source of the trouble:
Let's consider each of these alternatives in more detail.
The event log (see Figure 1-8) contains a special section for SharePoint, and the application event log can also contain some relevant information. It is even worth looking for events sent here from IIS. If the SharePoint application causes the worker process to die ungracefully, it can help to know when and why.
SharePoint itself writes a lot of data into the logs if it is enabled in Central Administration. During the development and test cycle, we strongly recommend activating the logs. You can find the logging files in
<%CommonProgramFiles%>Microsoft SharedWeb Server Extensions14LOGS
<%SystemRoot%>System32LogFiles
The IIS logs contain information about each request and the response. If you match certain reactions of SharePoint with the event of a specific request, there is a good chance of finding the reason for some unexpected behavior.
If you suspect that your code is causing the misbehavior and the debugger disturbs the data flow, a private trace is a good option. Just write useful information from your code to a trace provider. You can turn tracing on and off by setting the appropriate options in the application's web.config
file:
<configuration> <system.web> <trace enabled="true" requestLimit="40" localOnly="false"/> </system.web> </configuration>
The tracing framework is highly extensible and you can write the data to text files, the event log, or databases, or as XML. A full explanation is beyond the scope of this book. You can start here to learn more about tracing using the .NET Framework:
http://msdn.microsoft.com/de-de/library/1y89ed7z(en-us,VS.85).aspx
In addition to these specific techniques, you should consider using advanced .NET debugging methods such as the following:
Attaching a debugger to the working process and watching for exceptions
Considering remote debugging if the target machine has no debugger installed
Adding tracing to your code and watching the traces
These methods are not SharePoint-specific, but are nonetheless quite helpful.
Several tools are quite powerful, though not always appropriate on a production machine. The Developer Dashboard built into SharePoint 2010 provides at least basic information about internal processes.
By default the Developer Dashboard is switched off. To activate it on your machine, you can run a stsadm
command:
stsadm -o setproperty -pn developer-dashboard -pv ondemand
The command switch -pv
accepts the following settings:
on
: Activate the Developer Dashboard (always appears at the end of a page)
off
: Deactivate
ondemand
: Activate on Demand
The ondemand
option is usually the best choice, as it allows you to show or hide the information using the dashboard icon in the upper-right corner, as shown in Figure 1-9.
Launching this command takes some time even on a fast machine.
The on
option is helpful if the layout of a page is destroyed or you can't reach the Dashboard icon for some reason.
To activate the Developer Dashboard via PowerShell, use a script such as this:
$level="Off" [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") [void][System.Reflection.Assembly]::LoadWithPartialName ("Microsoft.SharePoint.Administration") $contentSvc=[Microsoft.SharePoint.Administration.SPWebService]::ContentService $contentSvc.DeveloperDashboardSettings.DisplayLevel= ([Enum]::Parse( [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel], $level)) $contentSvc.DeveloperDashboardSettings.Update() Write-Host("Current Level: " + $contentSvc.DeveloperDashboardSettings.DisplayLevel)
The supported properties for the $level
variable are the same as those for stsadm
:
"On"
: Activate the Developer Dashboard (always appears at the end of a page)
"Off"
: Deactivate
"OnDemand"
: Activate on Demand
This code is good for running in a batch file using a parameter. To copy a command-line parameter to the variable, use something like this:
param($level)
There is neither error handling nor user help in this batch file. Consider adding such lines to turn this sample batch file into production-quality code.
You're probably going to write some clever tools for SharePoint. Using code to activate the dashboard may help others to investigate what they are doing. A simple piece of code does the trick:
SPWebService svc = SPWebService.ContentService; svc.DeveloperDashboardSettings.DisplayLevel = SPDeveloperDashboardLevel.OnDemand; svc.DeveloperDashboardSettings.Update();
Note that the usage of the SPFarm
object, which is shown in several blogs regarding earlier versions of SharePoint 2010, is no longer supported in the final SharePoint product.
This tool will give you the following:
A breakdown of the request/response cycle with timings for each operation
A breakdown of the response times for each database query that the rendering process triggers
A breakdown of the load times for each Web Part on the page
Use this information to narrow down the source of any error (see Figure 1-10).
To access the dashboard, click the icon in upper-right corner to the left of the help button question mark. The dashboard analyses the current page only. The underlying ASP.NET engine has a lot more information beyond what the dashboard shows. It is written to the file Trace.axd
, and can be displayed by clicking the small link at the end of the dashboard screen showing "Show or hide additional tracing information..." (see Figure 1-11).
The ASP.NET trace shows virtually everything available from the current request/response cycle, such as headers, cookies, and form data. This includes internal traces, stack traces, and names of stored procedures and the time that they appeared. That makes the dashboard not only a perfect tool to find errors, but even more helpful to find performance flaws. The complete control tree is exposed and makes it possible to find the reason an element is not where you expect it or why it is missing altogether.
The dashboard displays any useful information that's available from the runtime environment. However, the reason for a malfunction, bad performance, or unexpected behavior could be in your code. It's good practice, in addition to using debugging tools, to add diagnostic output to your code that generates content to the dashboard.
You can use the SPMonitoredScope
class to create a section that is logged and explicitly exposed to the dashboard's output.
The logging output generated by the SPMonitoredScope
class is not available in sandboxed solutions.
Let's assume you create a visual Web Part and you want to know what happens inside the Load
event, when is it called, and how much time a specific operation consumes. The following code explains how to use the SPMonitoredScope
class:
using System; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using Microsoft.SharePoint; using Microsoft.SharePoint.Utilities; namespace VisualWebPartDashboard.VisualWebPart1
{ public partial class VisualWebPart1UserControl : UserControl { protected void Page_Load(object sender, EventArgs e) {using (SPMonitoredScope scope =
new SPMonitoredScope(this.GetType().Name))
{ Button b = new Button(); b.Text = "Click me!"; Controls.Add(b);using (SPMonitoredScope scopeInner =
new SPMonitoredScope("Inner Scope"))
{ System.Threading.Thread.Sleep(500); // lengthy operation } } } } }
In this code, the SPMonitoredScope
class exposes two lines to the dashboard output. The first uses the current internal name of the control, while the second uses a constant string. The inner operation is delayed to show the effect of the timer.
The advantage of this method is that the output appears within the context of the execution tree, and you see not only your information, but also when your code is executed. You can also see in Figure 1-12 how the artificial 500-millisecond delay in the code affects the whole page.
To get more information about programming Visual Web Parts, refer to Chapter 6.
On the client, the same effort has to be made to ensure that it's working correctly. The situation here is more complicated because several different browsers need to be supported. The developers of SharePoint 2010 did well to support all common browsers, such as Internet Explorer 7 and newer versions of Safari, Opera, and Firefox.
Note that Internet Explorer 6 is explicitly not supported by SharePoint 2010.
The application pages or Web Parts you create will programmatically send HTML, styles, and other content straight to the browser. You have to ensure that it runs without errors in the designated environment. Because SharePoint relies heavily on Ajax (asynchronous JavaScript and XML) and your customers invariably demand it, you may decide to use Ajax, too. Asynchronous calls from the browser to the server, while the page is visible, complicate things even further.
Sniffing the protocol activity on the connection with SharePoint requires a tool like Fiddler (see Figure 1-13). It shows the data flow, headers, cookies, and raw data sent down to the server and back to the browser. Fiddler is a web-debugging proxy that sits between the browser and the network socket. It logs all incoming HTTP (and HTTPS) traffic. You can inspect the headers received and sent, investigate the raw data, and edit data to test your server. Fiddler itself is independent of a specific browser and works well with Internet Explorer, Firefox, Opera, and others. For advanced scenarios, Fiddler can be extended using .NET-based plug-ins to automate traffic analysis. There are several add-ons available.
SharePoint makes heavy use of Ajax. Such calls to the server (called postbacks) run in the background. Fiddler is able to sniff this traffic and show what—if anything—happens.
To start Fiddler, you can use the icon that appears in the toolbar of Internet Explorer (
When you close Fiddler, it unregisters itself automatically and restores previous settings.
Fiddler supports breakpoints. Because there is now code, breakpoints are based on conditions. If an incoming response or outgoing request matches your criteria, Fiddler will pause, allowing you to investigate the data further.
Fiddler has one serious limitation when sniffing local traffic—a common situation when debugging SharePoint. IE and the .NET Framework are hard-coded to not send requests for localhost through any proxies, and as a proxy, Fiddler will not receive such traffic. The workaround is to use your machine name as the hostname instead of localhost or 127.0.0.1. So, for instance, rather than navigating to http://localhost/Default.aspx
, instead visit http://machinename/Default.aspx
.
The latest version of Fiddler also supports some other monikers such as http://ipv4.fiddler
to reach localhost on the IPv4 adapter, or http://ipv6.fiddler
to access localhost on the IPv6 adapter. This works especially well with the Visual Studio 2010 internal web server, which is internally using the IPv4 loopback adapter.
Eventually the page is rendered in the browser. If the rendered page does not display correctly, you will need to check the HTML, styles, and resources. The Internet Explorer Developer Toolbar will unlock those and more. You can download a free copy from www.microsoft.com/downloads/details.aspx?familyid=E59C3964-672D-4511-BB3E-2D5E1DB91038&displaylang=en
.
Using this add-on you can
Explore and modify the Document Object Model (DOM) of a web page.
Locate and select specific elements on a web page through a variety of techniques.
Selectively disable Internet Explorer settings.
View HTML object class names, IDs, and details such as link paths, tab index values, and access keys.
Outline tables, table cells, images, and selected tags.
Validate HTML, CSS, WAI, and RSS web feed links.
Display image dimensions, file sizes, path information, and alternate (alt
) text.
Immediately resize the browser window to a new resolution.
Selectively clear the browser cache and saved cookies. You can choose from all objects or those associated with a given domain.
Display a fully featured design ruler to help accurately align and measure objects on your pages.
Find the style rules used to set specific style values on an element.
View the formatted and syntax-colored source of HTML and CSS.
To get started with this tool, press F12 when working within Internet Explorer. You will see several tabs that give access to parts of the loaded data (e.g., HTML, CSS, and scripts).
For the Firefox browser, a similar tool exists, called Firebug. You can get more information at http://getfirebug.com
.
In this section you'll get a brief overview about SharePoint-related features included in Visual Studio 2010 and its SharePoint Extension.
In this section I'll introduce the support especially for SharePoint 2010 developers. If you already have experience with SharePoint 2007 and Visual Studio 2008, this may seem like a long list of obvious extensions. In essence, they will make third-party tools obsolete.
If you use the SharePoint templates and create solutions or features for deploying, everything works well. However, if you start creating regular ASP.NET web applications that simply reference SharePoint and run standalone, the internal debugger and web server will fail. There are some requirements that you can easily fulfill using IIS. For details, refer to the "Handling 64-Bit Quirks" section later in this chapter. For Visual Studio 2010 it turns out that it's not trivial. One solution is to replace the internal web server with IIS, even for debugging purposes. To accomplish this, you have to set a few settings in your project. First, a web site is required. To create one, use IIS Manager. Follow the steps described in the "Configuring IIS to Run with the Right Account" section to set the correct application pool settings. Then configure your project as follows:
Open the Properties page of your web application project.
Change to the Web tab.
Select "Use Local IIS Web server" and enter the URL of the root web site—Localhost:81, for instance (see Figure 1-15). Use any port number that is not in use on your system. It must be configured in IIS as well.
You can now create a new virtual directory if several projects run under the same web. Enter the name of your project. If the root web points to the path above the project, the current project's leaf folder is converted into a virtual directory.
You can now start debugging against IIS without worrying about the limitations of the internal web server.
Visual Studio 2010 comes with a set of templates ready to create SharePoint features. Table 1-1 gives an overview and short description of each template. Visual Studio supports SharePoint 2010 completely and SharePoint 2007 for workflow projects only. When you create a new project, you can find the appropriate path under the language selection. SharePoint templates are available for both VB .NET and C#. You can also choose to program against any of the supported .NET Frameworks: 2.0, 3.0, 3.5, or 4.0. This book uses C# as the preferred language, and you must use Framework 3.5.
Table 1.1. SharePoint Project Templates for C# Developers
Name | Icon | Description |
---|---|---|
Import SharePoint Solution Package | Creates a new solution based on an existing WSP (Windows SharePoint Solution Package) | |
Sequential Workflow | Creates a new sequential workflow | |
State Machine Workflow | Creates a new state machine workflow | |
Event Receiver | Creates an event receiver that handles events fired by SharePoint | |
Empty Project | An empty project to which you can add any item | |
Module | Creates a SharePoint module that can contain files | |
Business Data Connectivity Model | Creates a SharePoint Business Data Connectivity model that makes use of the Business Data Connectivity services. | |
Content Type | Creates a custom content type | |
List Definition | Creates a list definition for programmatically built lists | |
Import Reusable Workflow | Imports an existing declarative workflow from a WSP file created with SharePoint Designer | |
Site Definition | A template for defining a site programmatically | |
Visual Web Part | Creates a new web part using a visual designer |
Each of these projects allows the addition of several items. Some of the templates are just an empty solution with at least one item predefined.
After choosing the most suitable template, a wizard appears. You can now choose against which site the project is to be deployed for debugging purposes (see Figure 1-16). Visual Studio takes care to deploy the required files and register the assembly in the Global Assembly Cache (GAC).
The remaining tasks of the wizard depend on the item selected. Clicking Finish will create the project skeleton. As an example let's investigate a new list definition and its various settings. First, check the settings of the project by pressing F4 to open the properties pane (see Figure 1-17).
You can change the site and the assembly deployment target. If the project consists of only ASPX files or resources, you may deploy directly against the web application. If it is an assembly, it must be deployed into the GAC.
If you have a project created by some of the templates shown previously, you can add items from item templates. Apart from those available for any project type, such as Class
, you can add SharePoint-specific items, as shown in Table 1-2.
Table 1.2. SharePoint Item Templates for C# Developers
Name | Icon | Description |
---|---|---|
Visual Web Part | Web Part with an ASCX user control to create the visual part | |
Web Part | A regular Web Part with no designer support | |
Sequential Workflow | Creates a new sequential workflow | |
State Machine Workflow | Creates a new state machine workflow | |
Event Receiver | Creates an event receiver that handles events fired by SharePoint | |
Business Data Connectivity Model | Creates a SharePoint Business Data Connectivity model that makes use of the Business Data Connectivity services | |
Application Page | Adds an application page for highly customized applications | |
Module | Creates a SharePoint module | |
Content Type | Creates a custom content type | |
List Definition | Creates a list definition for programmatically built lists | |
Creates a list definition for programmatically built lists based on an existing content type | ||
List Instance | Creates an actual list within a deployable project (the list can contain predefined data) | |
Empty Element | An empty element you can add code or configuration files to | |
User Control | An ASP.NET user control for further usage in Web Parts or application pages |
Apart from these SharePoint-specific templates, you can add most of the item templates in the Web section to your project, such as JScript files, HTML, and other common resources.
The package contains several folders, even if it is something like a simple list definition. This structure represents a part of SharePoint's 14 hive—the SharePoint root. An item defined in the project is usually not able to act standalone. To deploy, it must be part of a feature or solution package. Hence, the project must meet specific requirements, and the templates take care of this. At least two items are required:
Features
Package
Under the Features folder, you'll find a feature definition as a configuration file. Each feature has a specific name. Just select the predefined name (Feature1) and rename it to whatever you choose. The files under the folder are then automatically renamed. A feature consists of at least an XML file. You could immediately start typing XML to create the feature. However, in a world of designers and graphical user interfaces (GUIs), you can also launch the Feature Designer.
The Feature Designer (see Figure 1-18) is primarily a collection of files comprising the solution. You can decide which files are parts of the feature.
The list definition template contains the support files for a list template and a list instance.
There is an import wizard to import workflows created and designed with SharePoint Designer 2010. Power users can now create workflows with SharePoint Designer and export them to a developer. The developer can import them and add further code or include them in a deployment package for further processing.
The common package format *.wsp
can now be imported and further used as the basis for a professional development package.
Once the feature and its contents are defined, a package is required to transport the feature to another SharePoint server. You don't need a package to debug your solution; rather, you need one to make the results available to anyone else. A package creates a WSP file that merely consists of the resources, a manifest file, and assemblies. We'll dig deeper into the internals of the package definition in the Chapter 9.
There are several options for building a package and deploying it to the connected server. Deploying directly to the server allows a fast check of your work and provides immediate debugging capabilities.
The build step performs two tasks:
Building the solution and creating the assembly
Packing and creating the WSP package
The deploy step includes the build step and performs several more tasks:
Checking the WSP package
Recycling the application pool
Retracting a previously installed version
Deploying the current solution as a new version
Activating the features in the package
There is also a retract option to remove the current solution from SharePoint. Furthermore, the package option isolates the packaging step from the build step to refine the process in case you're hunting a difficult bug.
While Visual Studio gives you low-level access to all programmable parts of SharePoint, SharePoint Designer provides a top-down approach (see Figure 1-19). Basically, SharePoint Designer starts by opening or creating a site. Once the connection to the existing or new site has been established, the user can apply various customization steps. That means the user can create a list, as it is possible with Visual Studio, but cannot easily export the list as an isolated installable instance. This means that SharePoint Designer is an end-user tool, empowering people working with an existing SharePoint server.
However, the biggest difference between the two products is the programming approach in Visual Studio. While you need direct access to a SharePoint system and the assemblies to program against, SharePoint Designer is limited to communicate via web services. The advantage is that you can use a 32-bit machine to run the appropriate version (an x64 version exists, too). A non-server operating system like Windows 7 is perfectly adequate for SharePoint Designer 2010 development.
When reading about SharePoint Designer in previous versions, professional developers used to regard it as a "forbidden" tool. SharePoint Designer 2007 operates against the database (read: production database) and has a number of powerful yet nontransparent functions. These aspects discourage developers from using SharePoint Designer, instead encouraging them to prefer Visual Studio.
With SharePoint 2010, the SharePoint Designer behavior is improved and some features seem to be sufficiently good to complement Visual Studio 2010. This section presents the more developer-oriented features.
Primarily, SharePoint Designer is positioned as a tool for power users. You can accomplish many common tasks, and it's quite helpful in smaller installations where the extensive effort required to create reinstallable components is unwarranted. For development and experimental installations, SharePoint Designer greatly complements the Visual Studio development approach. Hence, we recommend that all SharePoint developers attain an understanding of the basic features of SharePoint Designer 2010.
Among the many SharePoint Designer features, the most important ones are
SharePoint Designer rights: Administrators can decide per site collection what exactly a power user operating SharePoint Designer is permitted to do.
New dashboard interface: The new ribbon-based Office 2010 environment is now context sensitive.
Simplified object creation: It's easy to create pages, lists, and workflows.
Easy usage of content types: It's easy to create content types and use them immediately for a list or library.
Resource management: You can use assets to store and deploy resources such as graphics, stylesheets, and support files.
XSLT views: You can get the list views as XSLT and modify the views by editing the underlying XSLT.
Access data sources: You can get access to external data sources such as web services, databases, XML files, and scripts.
Manage BCS: The new BCS data sources can be created, modified, and connected easily.
Manage workflows: You can create and modify list workflows, site workflows, and reusable workflows.
The installation itself is straightforward. The only noteworthy aspect is deciding whether to install the 32-bit or 64-bit version. While your SharePoint development machine must run 64 bit, you can still use SharePoint Designer from this or another machine running either 32 bit or 64 bit. The SharePoint Designer version must match the version of an Office installation on the same machine. That means that if you run 32-bit Office 2010 on your development system, you must install 32-bit SharePoint Designer. If you already have 64-bit Office, the SharePoint Designer version must follow suit.
In this section you'll find some information about features that can simplify your life as a developer. Primarily, these options extend the capabilities of the browser-based user interface (UI).
Administrators can decide per site collection what exactly a power user operating SharePoint Designer is permitted to do. This gives the administrator the opportunity to manage the power users directly and without the need to check their systems for "forbidden" instances of SharePoint Designer.
You can change the required permissions via the "Site permissions" selection on the Site Actions menu. Choose Permission Levels on the ribbon's Permission Tools tab. Click Design to view the permissions associated with this level (see Figure 1-20).
SharePoint Designer communicates remotely using web services; hence, the Use Remote Interfaces permission must be activated.
The new ribbon-based Office 2010 environment is now context sensitive (see Figure 1-21).
Commands available only for specific elements appear on colorized tabs at the end of the ribbon bar. These tabs may be grouped, and several such tabs may appear. For example, if you edit an image within a Web Part, both the tabs for Web Part and Image Editing become visible.
It's easy to create pages, lists, and workflows (see Figure 1-22). The main screen allows you to browse any items of the currently opened site. For each element type, you can use the ribbon's first group, New, to create one.
Once created, you can edit all settings of the list, such as the content types, columns, views, and edit forms.
It's easy to create content types and use them immediately for a list or library. You can also associate workflows and set the appropriate forms for editing, viewing, and creating new elements based on this content type (see Figure 1-23).
Once the content type exists, you can add new columns from the list of site columns.
You can use assets to store and deploy resources such as graphics, stylesheets, and support files. An asset such as a CSS or JavaScript file can be edited directly using the integrated code editor (see Figure 1-24).
By assigning Visual Studio as the default editor, you can also edit files in Visual Studio directly from SharePoint Designer.
You can get the list views as XSLT and modify them by editing the underlying XSLT (see Figure 1-25).
XSLT allows dynamic changes to existing view forms. It's especially helpful when the generated HTML needs adjusting.
You can access external data sources such as web services, databases, XML files, and scripts via the Data Sources option. Any SharePoint list can be used as a data source too. Both SOAP and REST web services are supported.
The new Business Data Connectivity data sources can be easily created, modified, and used. In SharePoint Designer, this option is called External Content Types (that's what it is internally, by the way).
You can create and modify list workflows, site workflows, and reusable workflows. Workflows can be bound to lists or content types.
This book presents and teaches SharePoint as a toolkit and framework. It assumes that you're a web developer working with ASP.NET to create sophisticated web sites for intranet and Internet applications. Those applications are usually database intensive, with connectivity to LOB applications; they often implement an Enterprise Service Bus (ESB) and run inside a managed environment.
The .NET Framework, Visual Studio, and the Windows SDKs provide everything you need to get and build what you want. However, there are a lot repetitive tasks for every application. You need a UI for administrative purposes, pages to log users on and off, the ability to handle identities, and so on. With SharePoint, you get many of these features, providing more than 80 percent of a typical web application out of the box. That includes but is not limited to the administration functions, a set of powerful components, logging and maintenance capabilities, reporting and connectivity, and workflow and search engine support.
Even if you only need a few parts, the built-in functionality saves considerable time because you gain more than features. You get ready-to-use components that don't need any further testing or documentation.
SharePoint comes with several command-line tools to support administration and automation tasks. Some of the tools particularly aid developers.
This tool configures a fresh SharePoint installation or repairs a damaged one. It's the same as the graphical SharePoint Products and Technologies Configuration Wizard, but the console mode allows it to be executed in batch files for automation purposes.
The most important tool is stsadm.exe
. Almost all administrative tasks can be performed using this command-line program. Developers can extend it by adding private commands. It gives your administrators more power without introducing more tools. stsadm
was the only automation tool for SharePoint 2007. With SharePoint 2010, Microsoft made a major shift to supporting PowerShell. PowerShell uses so-called cmdlets (pronounced commandlets).
It's important to note that stsadm
supports several operations that have no equivalent in the Central Administration or Site Administration UI. That means that unless you program against the API, there is no alternative way to perform certain tasks without using stsadm
(or its successors, PowerShell's SharePoint cmdlets). However, using PowerShell is the preferred way, because Microsoft is going to move all administration tools to cmdlets. Sooner or later, Microsoft is going to drop the antiquated batch support, whether you like it or not.
Some graphical tools accompany the installation and support administrators and developers installing and configuring SharePoint properly.
SharePoint 2010 runs on 64-bit hardware only. For you as a developer, this means that you have to create and build against the 64-bit version of the .NET Framework running on x64 processor architecture. Even with Visual Studio 2010 installed on the same machine, some settings need to be changed to support the right architecture.
For projects running inside the context of SharePoint, the templates ensure correct functionality. However, if you plan to develop administrative support tools, such as console applications or even a web site running in IIS and dedicated to helping administrators running advanced tasks, things are rather different.
For a console application, you merely set the processor architecture to 64 bit. Proceed with the steps shown in the following exercise.
The project is now able to run against the SharePoint assemblies.
The target framework is version 3.5, even if 4.0 is available on the target machine. The SharePoint assemblies are built against 3.5 and therefore can't interoperate with version 4.0. That means in turn that the features available are limited to what .NET 3.5 provides. In addition, it means that the ASP.NET runtime is still using 2.0, because .NET Frameworks 3.0 and 3.5 did not change the runtime. The next runtime version for ASP.NET is 4.0, and this is not available to program against SharePoint 2010.
To create web applications, you don't have to run inside SharePoint. For administrative tasks in particular, it's recommended to use separate applications. While console programs are fine for scripting automated tasks, a web application provides an advanced UI, including help and support information. Administrators lacking skills on the platform and users who help manage the servers may struggle with command-line tools. Therefore, creating administration web applications is common.
However, for ASP.NET, the same restrictions apply as for console applications. They must be configured to run on 64 bit. In addition, the application must run under the same account you would use to administer your SharePoint central administrations.
To prepare ASP.NET for the x64 platform, you need to configure the application pool of your web site. The following exercise shows you how to set the appropriate property, enable32BitAppOnWin64
, to false
.
For an ASP.NET application, two settings are required. First, you must set the application pool to run under the administrative account. The following exercise shows you how to configure it.
Next you must ensure that the user you use is able to log onto your web site. You can either edit your web.config
file or use the IIS Manager management console. In the web.config
file, the following settings apply:
<configuration> <system.web> <authentication mode="Windows" /> <authorization> <deny users="?" /> </authorization> </system.web> </configuration>
This code sets ASP.NET to authenticate using Windows authentication. The <authorization>
tag prevents anonymous users from accessing the pages. Setting Windows authentication mode via the IIS management console requires the steps shown in the following exercise.
For the authorization part, a similar set of settings are required.
While the settings in IIS change the web.config
file immediately, it seems that some settings changed in the web.config
file do not automatically create similar entries in the IIS management console. If you use both approaches, watch carefully what finally appears in the web.config
file (which is the master settings store). We recommend using web.config
only, and using the IIS management console solely for tasks that set properties elsewhere.
Once everything is done, you can deploy and run your application.
This chapter first gave a short overview of why and how SharePoint is used as a development platform, how it is related to IIS, and what's so special about debugging custom code.
In this chapter you learned how to prepare your development environment for SharePoint 2010 and get the right tools for developing, debugging, and monitoring your work—tools such as the Internet Explorer Developer Toolbar, the web proxy Fiddler, and the Developer Dashboard. You also learned how to use command-line and graphical tools supplied by SharePoint. Some are intended to automate tasks or run as a prebuild event in Visual Studio.
Using Visual Studio 2010, you learned how to prepare ASP.NET and console applications to run code against SharePoint and the steps needed to run in a 64-bit environment.
Using SharePoint Designer 2010 enables power users to create sites, lists, libraries, workflows, and content types. The site administrator can control access through the SharePoint Designer tool. Developers can import projects created with SharePoint Designer and use them as the basis for professional development projects. The complete chain of tools is SharePoint UI for office workers, SharePoint Designer for power users, and Visual Studio for developers.