Writing a SharePoint console app is quite simple.
On your SharePoint development machine, create a new Console Application in Visual Studio 2010. As shown in Figure 1, make sure your target framework is .NET 3.5. This is because SharePoint 2010 is built on .NET 3.5 SP1.
Add
a reference to Microsoft.SharePoint.dll. You will find this reference
under the .NET tab of the Add References Dialog within Visual Studio.
Look for Microsoft.SharePoint.
Right-click
your project and choose properties. Under the Build section, change the
platform of your console application to AnyCPU or x64. The default in
Visual Studio 2010 is x86, because it is envisioned that for a very
long time to come x86 apps will be the default application of choice
unless an application needs to deal with massive amounts of data. x64
apps require too much segment calculation for them to be efficient in
most scenarios. On the other hand, AnyCPU apps have an initial starting
overhead, but once they are started, they run quite well. (I prefer to
go with AnyCPU in most instances.)
Finally, write some code in your static void main, as shown in the following:
using (SPSite site = new SPSite("http://sp2010"))
{
Console.WriteLine(site.RootWeb.Title);
}
Remember to add a using statement for Microsoft.SharePoint.
That's basically it. Hit F5 to run your application and now you should be able to view the title of the Site at http://sp2010.
There is plenty else to learn in the SharePoint object model. Luckily,
most of it is named well so it is easy to figure out what most of it
does. You will see many classes, but for now please go ahead and
familiarize yourself with the following basic classes in the SharePoint
object model:
SPFarm
SPWebApplication
SPSite
SPWeb
SPList
SPListItem
SPDocumentLibrary
There are many more objects to be familiar with and
throughout this book as well as while working with SharePoint you will
learn them as you go.
As I said earlier, you will never deploy new
functionality to production using console applications. Also, when you
write new functionality for SharePoint 2010, the only good and
maintainable way to deploy such functionality is as a SharePoint
solution. A solution is simply a .cab file, renamed to a .wsp file. If
you were to simply rename a .wsp file to a .cab file and open it, you
will most definitely see a manifest.xml file in there. The manifest.xml
file is what SharePoint would use to understand what the solution
contains.
What can any solution contain? A solution
can contain plain artifacts being deployed to the file system, content
database, or any new executable artifacts such as web pages, server
controls, or WebParts. So, what does it take to write a simple feature
or solution that deploys a new WebPart? Before I describe how to write
a WebPart, first let's define WebParts.