notes on SharePoint 2010 Tools in Visual Studio 2010 at stlsug

Becky Bertram's SharePoint 2010 Tools in Visual Studio 2010 presentation on
Jun-08-2010 at St. Louis SharePoint User Group was
really well-presented and insightful:

Main takeaways: Visual Studio 2010 has many new features related to
SharePoint 2010, making it easier to be productive in the development
environment. The Feature Upgrading, sandboxing, and easier & enhanced
debugging are some of the useful new features. SharePoint assets live on
the filesystem, database, and the GAC, and projects in Visual Studio for
SharePoint give a unified view into all assets.

Details:
Solution Package structure, files not changed from SharePoint 2007 to 2010.
Visual Studio 2008 can be used to create SP 2010 solutions, but it's more
work.
Visual Studio 2010 can be used to create SP 2007 solution package, but it's
not recommended.
Microsoft says one can use Windows 7 to run SharePoint and create solutions
with VS 2010, but her preference is to always use a VM of Windows Server
2008.

Solution Package
is essentially cab file with wsp extension enabling the systematic
deployment and retraction of assets. The solution package gets added to the
Solution Store via PowerShell command:
stsadm -o addsolution
Solution Manifest xml file directs SharePoint 2010 where to place files on
file system; adds safecontrol element in web.config file.

Farm vs Sandbox Solutions scoped at farm level generally run in the IIS
worker process (w3wp.exe) and require an admin to deploy. Sandbox solutions
run in SPUCWorkerProcess.exe, require site collection admin to deploy, and
code has access to API at Site Collection level and lower (SPFarm,
SPWebApplication not available).
There's enhanced multi-tenancy features
in SharePoint 2010. An admin can
lock down system resources available to your solution, and when exceeded,
your solution is retracted (and, optionally, redeployed and activated on
schedule at midnight).

Feature - unit of
functionality; can have dependencies on other features; and feature
dependencies can be daisy-chained. can be activated and reusable. Events
in features' life:
installed, activated, uninstalling, deactivating, upgrading event
receivers can be coded for these events. Note that the "-ing" receivers
hand event (to your code) before the event, while the "-ed" receivers hand
event after the event. For example, when SharePoint is deactivating a
feature, it might remove many lists from the site, so your code can check
permissions and cancel the deactivation.

Feature Upgrading new in SharePoint 2010 Adding additional features to a
Content Type. This could be painful in SP 2007. With this feature upgrading
in SP 2010, it's easy to bring older features up to a state of consistency
with newest solution. There's a good example in the SDK. See also
Upgrading Features.

There's a feature manifest file. This directs SharePoint to serialize the
file and store in SQLServer db.

Declarative vs Imperative programming. declarative is XML schema and XML,
where SharePoint instantiates objects as they are declared in the XML.
Imperative is using the SharePoint APIs, e.g., SPField, SPContentType,
SPList, SPListItem. There's a lot of discussion around which is 'better'
and it's analogous to 'which is a better route to take to downtown St.
Louis?' - there are many ways to solve the problems in SharePoint.

SharePoint tools now come standard with Visual Studio 2010; no need to
install SharePoint related extensions after installing Visual Studio 2010.

A walkthrough in Visual Studio 2010 of creating field, editing its XML file;
content type; list definition (beware scoping as it relates to the add list
instance for this list definition checkbox, which is checked by default);
add new list instance.
If you create a visual web part, know that it can't be deployed as sandbox
solution; only compiled web part can be deployed as sandbox solution.

The Feature Designer is a nice new tool in Visual Studio 2010 allowing you
to graphically edit the XML. There's also, within Feature Designer, the
ability to hand-edit the XML, while it simultaneously validates it.

One can add custom icons to one's featuers, so they're more readily
recognizable in browser in the SharePoint features gallery. Use the 'Add
Mapped Folder' feature in Visual Studio 2010. See pg 14 of A SharePoint
Developer Introduction Hands-On Lab

As an example of adding code for the aforementioned Feature Deactivating
event:
using ( xxxxx ) { // always use using so as to dispose of objects; mem
mgmt
web.lists("vegetables").Recycle(); // will place into SP Recycle bin
}

In a Visual Studio 2010 project properties, right click the project itself,
bring up 'properties.' context menu, and in the project's properties is a
new "SharePoint" tab, where one can Edit Configurations and give
predeployment command, post deployment command, etc. Since sometimes we
want to deploy but not activate features (since features often must be
activated in certain order), this tooling is available in Visual Studio
2010.
One can also direct SharePoint to retract the solution when we're done
debugging it. With SharePoint 2007, to debug, we'd have to attach to IIS
process itself (leading to timeouts, etc.), but with SharePoint 2010 feature
receivers attach to timer job processes which makes debugging much nicer.

Tidbits / Misc:

"14 hive" terminology in SharePoint 2010. See SharePoint 14 hive directory
structure

SharePoint 2010 is using .NET 3.5. Since .NET 4.0 was concurrently under
development, the SharePoint team used .NET 3.5. One can set one's solution
in VS 2010 to target .NET 4.0, but SharePoint will not use .NET 4.0 new
features. We can make use of Silverlight 4.0.

There's an 'Import Reusable Workflow' feature in Visual
Studio 2010 which enables importing SharePoint Designer workspace into
Visual Studio 2010. Becky advises against this.

Slide deck is available at
http://blog.beckybertram.com/Lists/Posts/Post.aspx?ID=99