Editor's note: Contributor James Love is a SharePoint Developer Consultant for Intelligent Decisioning Ltd. Follow him @Jimmywim
I thought I'd jot down a few things which I believe fresh SharePoint developers need to know when they're confronted with the daunting task of developing something for SharePoint for the first time.
SharePoint development has a massively steep learning curve. It literally takes years to get good at not only developing solutions in SharePoint, but also using the right techniques and tools to develop those solutions. And the reason for this is because the platform itself is so big. There are so many facets to consider when choosing how to architect a solution, as well as the tools available are themselves quite involved. Not only does it take a long time to learn how to develop, it can take just as long, if not even longer, to understand the full capabilities of the tools at hand.
In this post I'm going to list a few key 'areas' I think any first time developer should look into, gain a brief understanding of, and most importantly, be aware of, when getting started with SharePoint. Not only will this make the new developer aware of the scale of the task ahead, but also (hopefully) give some direction as to what technologies they should research as they go into the journey that is SharePoint Development.
I have added various links to pages I think will give you a start in reading about the various areas. Some of these links may be written for earlier versions of SharePoint but the topic may still be relevant in SharePoint 2010. If I haven't included a link for a specific topic... I'm sure you know how to use Google :)
Microsoft SharePoint Foundation
This might sound obvious, but it is vital. If you are going to develop for SharePoint, you need to know SharePoint. And know it well. If you're new to SharePoint and have been given the task of building a solution in it (I feel for you if that's the case, many of us have been there!), you already have a mountain of a task ahead of you. It won't take too long, and there are plenty of resources out there, but you need to gain an understanding of what SharePoint is already capable of, without customisation.
This brief list is a collection of things I believe you need to have a basic understanding of:
That list is not exhaustive, but I think it's a brief look at the scale of what makes up a SharePoint environment in terms of what's customisable. Also note, that none of the above necessarily means any C# source code is involved, though quite a few are built up of XML files.
Microsoft SharePoint Server
You what? There's more? Damn right. SharePoint Server is essentially a licensed pack of enterprise-level customisations built on top of SharePoint Foundation. Whilst I'm not going to list here what you should know about SharePoint Server, you should at least have a look around on the Microsoft website for SharePoint to see the differences between the editions of SharePoint, and see what's "available" in terms of feature sets. Each of these has a significant amount of documentation already on what they do, how to set them up, and what they're capable of.
A couple of elements I will suggest that a new developer look at are how the Publishing framework works within SharePoint Server 2010, and Variations. You don't at this stage need to know in-depth of how to create a page layout, for example (unless you're being thrown into a Web Content Management project!), but at least have an awareness of how page layouts work, how they're tied closely into Content Types and the special "Pages" library in a Publishing site. Variations is a method of creating versions of content targeted to specific locales (languages) or devices (mobiles, tablets, etc). This is a slightly complex framework that is not at all customisable, but you should have an awareness of how this works just in case it sounds like a feature that you may need one day (and also know when to avoid it!).
Is this necessary if you only have SharePoint Foundation in your environment? Absolutely - if you want to strike up a cost-benefit analysis to see if it's cheaper to develop and support a small piece of functionality that's already available (and fully supported) in SP Server, or if there are features that will satisfy requirements, and benefit the rest of the business by upgrading your licenses to SharePoint Server.
In short, for this and the previous section - a good SharePoint Developer has a clear understanding of the majority of the capabilities of the platform as it comes.
Microsoft Office 365 SharePoint Online
This is yet another SharePoint offering from Microsoft which provides hosted services. If your environment is hosted in this manner, this will affect the decisions you make in terms of your architect for your solution. There are many differences and restrictions to what's possible for customising SharePoint Online in Office 365 compared to 'on premises' environments, and as a developer, you should read up on what those differences are.
Here's a link on MSDN as an overview of SharePoint Online for the developer.
The Tools - SharePoint Designer
Learning what SharePoint is already capable of is a very steep struggle as it's so expansive a platform. There are a fair number of business cases that it can easily satisfy from just configuring a SharePoint site, for example creating lists, libraries, applying simple branding themes, alerts, etc. SharePoint Designer is a client application that can connect to a SharePoint web site and provide an easy way to quickly create lists, content types, and even simple workflows. You can also do slightly more advanced customisations in terms of modifying Publishing page layouts and web part pages, for example to provide advanced List Views with custom XSL style sheets to display data in any way you want.
As a developer you need to understand that this tool connects directly to a SharePoint site, know that restrictions can be put in place as to what can be done in SharePoint Designer, and what is ultimately possible.
Here's a link to an introduction to SPD on the SP365 website.
It's also possible to extend SharePoint Designer - you can add more 'workflow actions' to allow workflow designers in SharePoint Designer to do satisfy more business specific scenarios. This kind of customisation of SPD leads onto the next section...
The Tools - Visual Studio
Visual Studio 2010 is the tool most associated with the developer. The developer is seen as a code hack who lives in VS and swims in C# and XML all day. Whilst this may be true for some, a good developer has a reasonable cause to go to Visual Studio. They want their solution to be easily re-deployable, to be version-controlled, and most likely, the feature set provided with SharePoint Designer and the SharePoint platform itself does not satisfy the original business requirement.
So, what do you need to know about Visual Studio? Hell of a lot, before you even start writing code! There is a good selection of different project and item templates provided with Visual Studio, and they have their shortcomings. The SharePoint community has satisfied many of these shortcomings with the CKS:Dev toolkit available from codeplex. But before diving straight in and getting the template, you need to fully understand the capabilities of the templates already provided, what restrictions you may have if you go straight into a CKS:Dev template - for example if you're in a team environment, other team members may not be able to open your projects if you created it from a CKS dev template!
You also need to understand how Packages and Features are structured within a Solution in Visual Studio, how SharePoint Project Items in Visual Studio can be inserted into Features, how Feature Scope is set up, how to add SafeControl elements to items, how to add extra assemblies into a package (in addition to those generated by a Visual Studio Project).
If you're developing in Visual Studio, or think you may need to do so, then you'll need to understand that will never, ever, EVER deploy to a live environment. You will always develop to a local server. You may need to have a virtual machine with a SharePoint environment set up and running, with Visual Studio also installed, and you develop in that environment. You will also need to understand that what you develop, is tested and debugged in your local environment, but it absolutely must, with no exceptions, be deployed on a test environment (completely separate to your development environment) which closely matches that of the live environment (but again, is completely separate from the live environment).
Already the costs involved here are very high - you need licenses for Visual Studio, Windows Server and SharePoint for your Virtual Machine, you need an environment which can closely match the live environment for testing your solution. As these costs are already quite high (and you've not even spent a day writing code towards your solution yet!), you better have a good knowledge of SharePoint itself, and SharePoint Designer, to justify going to these lengths, and be certain you're not reinventing the wheel, and not redeveloping something SharePoint can already do.
The Technologies - ASP.NET
SharePoint Foundation is a very complex application structure built on top of ASP.NET, which is an application development framework designed to produce web-based systems. The development of ASP.NET is, and has been for the past 8 years, far quicker than that of SharePoint. To give an example, the version number of ASP.NET that SharePoint runs on is ASP.NET 3.5. The most current version of ASP.NET is 4.0. There are quite a lot of very cool features in ASP.NET 4.0 that you cannot take advantage of within SharePoint, as these features are not compatible with SharePoint. We will not see SharePoint use ASP.NET 4.0 until the next version (which may be released next year). At this time, ASP.NET 5 will be under development and may even have a release soon after SharePoint's next release.
The short of that is, if you are coding for SharePoint 2010, ensure everything you do is built towards ASP.NET 3.5.
More of what you need to know about ASP.NET is the basic building blogs, such as master pages, the 'web.config' file, the Page Lifecycle (what events are triggered in code as a page is loaded), caching, etc.
With Visual Studio 2010, there is the Web Application template provided, can you can create and test out simple ASP.NET Web Applications that run on your development environments own debugging web server.
You don't need to have a fantastically in-depth view of ASP.NET, but again, at least have an awareness of what makes up an ASP.NET website and how pages are built.
The Technologies - C#
FINALLY, THE CODEZ! Yup, once you've got an idea of how all the above works, you can finally be let loose on some code. But what to code? And how? Well there are plenty of tutorials for 'simple' projects for getting started with code, but here's what I think a new developer should look at in terms of learning C# for SharePoint Development:
That list is nowhere near exhaustive. SharePoint development in C# is probably the largest topic, as there is many, many ways to solve the same problem using a custom coded solution.
You should also be aware of what restrictions you have when development for the 'Sandboxed' User Code environment, available both in SharePoint Foundation, but also the only option when doing custom development for SharePoint Online in Office 365. The Developer Guide for Office 365 is available on MSDN.
That's NOT all folks...
This post has barely scratched the surface of SharePoint development, and I have not covered Client Side Development Techniques or Infopath! However, I think (and hope) it gives people some direction as to what tools and technologies and areas they need to research and do their homework on, to satisfy that oft-asked question... "How do I get started with SharePoint Development?".