Good Afternoon friends,In the session today, We’ll be talking about the new tools in Visual Studio 2010 for SharePoint 2010. My Name is Madhur Ahuja and I am an Associate Consultant with Microsoft Services.These tools are known as Visual Studio 2010 SharePoint tools.
The key and objective for this session. We want to show you, how much easier SharePoint Development is with the new enhanced tools in Visual Studio 2010.We will be spending most of our time in demos. We’ll see a demo of Sharepoint Explorer so that we can quickly look and explore at different site collections which are in the local farm as we are doing development.We’ll also see a demo of new project templates and project item templates which are new in Visual Studio 2010 Sharepoint tools. We’ll also create a sample project and seeThe new feature designer, package explorer and build configurations.And in the end, We’ll see the reusable workflows in action, The reusable workflows can be very easily exported from sharepoint designer and imported backinto Visual Studio.
Back in SP 2007, most developers will agree that sharepoint development was very limited. Most of the developers would start with class library project and start adding batch files, XML files for features to be able to perform in SP 2007 development.From Microsoft, We had Visual studio extensions for WSS as well as two separate templates for building workflows in VS 2008. However, there was no consensus among developer community regarding which tools to use. There were some codeplex tools such as WSPBuilder, STSDev for sharepoint development. Thus, there was no universal approach to sharepoint development.Apart form that, the developer had to deal with many manual tasks such as :Developer had to manually edit CAML files which is a very tedious task to do.Developers had to build a batch file to build out a solution package which is nothing but a cab file with .wsp extension.Developers also had to be very aware and careful about the sharepoint root files directory structure as the developer creates artifacts like * application pages * style sheets * site definition filesA developer has to be very careful about knowing the which files goes where.
Before we go ahead, let me call out the requirements for the environment running Sharepoint 2010.64 bit operating system is required for develop environment. You can run SharePoint 2010 on either Windows 7, Windows Vista, 2008 or 2008 R2 operating system.To do development with Visual Studio 2010, SharePoint 2010 must be installed locally.
Now with the new SharePoint 2010 tools ,many things have changed. First I’ll point out that the New Visual Studio 2010 tools are dedicated to SharePoint 2010. These cannot be used with Sharepoint 2007 development.But when we are working with Sharepoint 2010, it gives us end to end development experience.Developers need not reach out to any third party utilities.I’ll point out the brief overview of new Sharepoint 2010 tools, WFirst there is a sharepoint explorer so that I can look at different site collections which are on my local farm in Sharepoint 2010.Then there are different project and item templates in Visual 2010.There is also a migration path , if you have been creating code with VSeWSS. There is a import template , which will take the VseWSS project and import it into new Visual 2010 format. It will change all your code and restructure your project into the Visual Studio 2010 Sharepoint template.There is also a import re-useable workflow project in Visual Studio 2010 which lets you import the sharepoint designer re-usable workflows into Visual Studio for further customizations which are not possible through Sharepoint Designer.The best thing about the new tools is that it was designed with extensibility in mind.Some of the benefits we going to get is when we create a new project with new sharepoint tools ,we don’t have to worry about how the solution package gets built and generated. It all happens behind the scenes.Also, we don’t really have to worry about the structure of root files directory. So , the files can be put anywhere in the project structure irrespective of where they are going to be physically deployed. And this is all because of the new design and the architecture of these toolset.
We are going to look at is SharePoint Explorer, which is a simple add-in utility that we get with Visual Studio. I am going to startup Visual Studio and will give you a quick demonstration on how Sharepoint explorer works.
In this demo, I have a site on my local farm. This is a new look and feel of the out of the box publishing template of Sharepoint 2010. Ihave deployed a single server installation on my local computer. The same server holds the WFE and also the database server. The main point is farm has to be local for sharepoint explorer to work.Inside the server explorer, we have something called sharepoint connections as title, this is sharepoint explorer. There is a ability for me to add, using this I can add any site collection which exists on my local farm. As I expand the plus sign, I notice that it shows my top level site and also its associated content types, features, list templates. I can even drill down to different types of list templates that are available for creating lists. Lets also take a look at the list which are in site.The one interesting point here is that nodes inside in sharepoint explorer are read only. That means I cannot right click a node and delete a list/ library from inside of an sharepoint explorer.However , the sharepoint explorer is extensible. Than means, You can create custom node and decide if you want to expose the delete functionality as a part of that custom node using sharepoint object model. That means, I can have my custom node here which will show the lists inside my site along with the delete functionality.Using View in Browser.
As we began working with new SharePoint 2010 Tools, they install automatically with Visual Studio 2010.To make use of these SharePoint 2010 tools ,there are several project templates available in Visual 2010 such as WebPart, Visual WebPart and workflow.Every time we create a project, sharepoint tracks a Url to the test site on your local farm. You can see a dialogue on your screen and that is the dialogue where visual studio asks you for the Url for the test site. This test site Url is very important.When you debug, since you have pointed to the site collection, visual studio can calculate the web application and the worker process. Thus unlike, Sharepoint 2007 development you do not have to figure out the worker process to attach to, that happens automatically behind the scenes.Using this Site Url, visual studio can activates the feature automatically in the target site collection, when the solution is deployed.Also, when you create a new project it asks you weather you want to create a standard solution or a sandboxed solution. Every time when we create a project, our project will have some standard properties .. Our project will have active deployment configuration and that are the series of commands that are executed when you right click the project and choose deploy. We’ll see more of that in the demo. Include Assembly in Package: Normally when we create a project, we include some code which gets packaged as a part of solution package. However , there are times when you only want to deploy declarative features inside the farm. So it’s not always the case that we want to include the assembly in the solution package. We can set this property to false so that the DLL doesn’t get bundled into the package. We have a property that says weather it’s a sandboxed solution or not. If sandboxed solution is true, Visual studio doesn’t deploys it to farm solution store but instead its deployed to the user solution gallery inside the site collection. Also , when you toggle the sandboxed solution property to true or false, it changes intellisense, because when we create sandboxed solution we don’t have the full ability to program against full object model. So setting the sandboxed solution property to true, instructs Visual studio to take away classes that you can’t use when you execute.
Now, when you create a new Visual Studio 2010 SharePoint project, we have a properties node and a references node. These two nodes are common to the other visual projects. However, with SharePoint 2010 projects, there are two nodes that are new.Every new project based on sharepoint projects will have a features node. The feature node contains the list of features that are contained within that sharepoint solution package. It can contain multiple features or even no feature at all. But there will be always feature node.Second, there will be a Package node. Unlike the feature node, there will be always one package per sharepoint project. And inside of the package node, they have the files which hold the configuration information on how to build the solution package.In addition to these nodes, we also have something called sharepoint project items. These are the building blocks with which we build sharepoint solutions. For ex, If I add a new project item and add a new WebPart, that’s s an example of sharepoint project item or SPI. If I add a sequential workflow template , that’s another SPI. Other examples of SPI’s are list definition, site definition or content type etc.
Now, feature node allows the developer to look up the feature and also edit the Name , description and Scope visually rather than editing an XML file. A developer can also see, which particular SPI’s are inside this particular feature.In addition to feature designer, If you look at the bottom right, there is also a standard visual studio property sheet. The property sheet provides much more access to properties of feature itself than the designer. Again, We are going to see more of this in the demo.
If you have been doing sharepoint 2007 development, you will probably know that there are certain places inside of sharepoint RootFiles directory also called as 12 hive. If the developers wants to put something inside layouts directory or the Images directory, - Visual Studio allows you to create something called Mapped folders. Which in particularly allows the developer to put files which will be put inside solution package and will be deployed automatically to the well known locations inside of root files directory like layouts and Images.
When I do the demo, we are also going to look at the project packaging. Quite often, you don’t have to look at the package, because everything is built automatically for you. But there are some scenarios where you might have to open up the designer and have a look inside.
Now, the last thing I want to show I can go to my project and right click, there is both a deploy and retract menu. What happens when you execute those commands within visual studio ?It depends on the deployment configuration which we have configured in VS 2010. We get two deployment configurations OOB when we install VS 2010.We have default and we have no activation. If you notice the box in the screenshot, these are deployment steps. Visual studio comes out of the box with these deployment steps. These are deployment steps which you can configure and have control over what happens when you deploy and when you retract.
Also , we have F5 Debugging Experience which makes the sharepoint development very very easy to use. As you will see in the demo,I will able to just hit F5 and debug my artifact because Visual Studio has the Site Url , it is able to resolve the web application and find the correct worker process to bind to W3WP.exe
Ok, Lets go straight to the demo now :Here I have Visual Studio 2010. Before we create a project, I will ensure that we have a test site. For the purpose of demo, I have already created a test site on my local machine and I am going to use the same.I am going to go to SharePoint 2010 node, Make sure that target platform is .NET 3.5There are several project templates here and I am going to choose Empty Sharepoint project and name it as Contoso WebPArtsOnce I create it, Visual Studio asks us to specify a site collection Url and also to choose between Sandboxed Solution or Farm solution. I am going ahead with Farm solution.When the new project opens, note that there is a properties node and References node just as it would be with any Visual studio project. But also note that, we have features node and package node which are specific to sharepoint project only.Features node is empty when you create a empty project. Lets go ahead and create a new feature. I will rename it to Main.Give out a Title and Description. Also note that you can select, the scope, the default is Web. And I am going to change it to Site.Note that if we come down at the bottom, there is a manifest section, there is an edit mode where in we can put the any elements inside this manifest. And when the final feature.xml is generated, they will be merged with any elements which I put inside.Also note that, I can see the property sheet for the feature. For this feature, lets say I want to add an image. For ex, If I navigate to my Site collection features, We see a custom icon instead of the default icon.So the way I am going to do this, I am going to add an custom graphic file inside the RootFiles directory of sharepoint and assign it as a Feature icon.I click on Add, and I notice that there is a predetermined Sharepoint mapped Images folder. Also , I can use this dialogue to pick a director to deploy any file to RootFiles directory. But because I want to add the Image, I will choose the predefined Images Mapped folder.Note that As I add a mapped folder, sharepoint automatically adds a subdirectory with the name as a project name. This is a best practice as against putting the files directory into the images folder since there might be a chance of name conflict. So you can see that sharepoint tools are enforcing the best practices.Lets go add, and choose existing image and notice that I have a feature icon out there.Now that I have an image, I will edit the ImageUrl property. Note that Imageurl property is relative to the Features Directory.Now , before I hit the Deploy command, lets go to the project properties and look at the Deployment Configuration. There are two deployment configurations be default:DefaultNo ActivationNote that these two are read only. You can add your own deployment configuration and add steps to it. But these two are read only.Lets take a look at the Default configuration.What I going to do is Activate myself, So I am going to switch from Default Configuration to No Activation.So lets run the deploy command now with the Output window open. What happens is sharepoint takes my files, build them into solution package. Then they install it into the farm and deploy it.Now If I go back go the site collection feature screen, I can see my feature with Custom Image attached to it.Nothing is going to happen If I activate right now. So lets go back and add some code to it.Lets say I want to run a code so that when my feature gets activated, it changes the Title of top level site. So lets go and add a event receiver. The Visual studio will add a class inherited from SPFeatureReciever.Note the two changes here:First there is a new event called FeatureUpgradingAnd the second is , back in 2007, when we over inheriting from class, we always had to override all the methods. But now, Sharepoint team has added the default implementations of these methods in the base class and thus you can only implement the methods you want to.These default implementations don’t do anythingLets deploy the solution. When I choose deploy, its going to retract the older version and deploy the newer version of the wsp.Demonstrate the title changing.Now as a final demonstration, let say when we activate the feature, we want to attach to the debugger.So lets set the breakpoint and hit the F5 key …Ok, So lets summarize what we have done in this demo:We have:Built new project and examine the project structureAble to add a feature and add some code to it.Able to add a mapped folder pointing to Images and put an Image into the file system.And finally, we were able to see the deployment configuration and also see the F5 Debugging experience in action.
Workflows can only be associated with lists, not content types
Tools in Visual Studio 2010 for SharePoint 2010 Madhur Ahuja Associate Consultant, Microsoft Services Email: email@example.com
Session Objectives and Takeaways Objective Show the Visual Studio 2010 tools for building SharePoint customizations Key Takeaways Visual Studio 2010 offers a set of tools that simplify SharePoint solution development
Development with SharePoint 2007 Visual Studio Experience is limited Visual Studio Extensions for WSS Visual Studio Tools for Office with VS2008 SharePoint developers reliant on community tools. Developers have to deal with manual tasks Manually editing CAML files Understanding RootFiles directory of WSS Manual edits to manifest.xml file. Building .wsp file for solution package.
Visual Studio SharePoint Support Requires x64 operating system Windows 7 Windows Vista SP1 Windows Server 2008 Windows Server 2008 R2 SharePoint 2010 must be installed locally SharePoint Foundation or SharePoint Server Visual Studio 2010
Visual Studio 2010 SharePoint Tools SharePoint 2010 developer story SharePoint Explorer for site exploration SharePoint 2010 project and item templates Visual designers for core scenarios Migration path for Visual Studio 2008 for WSS 3.0 Extensible by 3rd party developers Reducing Complexity – XML Schemas, CAML, various config files Improved F5 Experience Improved Packaging & Deployment Experience Benefits Abstracts away details of RootFiles directory Abstracts away details of building .wsp file Eliminates need for external utilities
SharePoint Explorer Add-in for Server Explorer Window Easy way to examine site artifacts Quick way to launch browser into site SharePoint Explorer extensibility Developers can write add-ins to populate nodes and provide contextual menu commands
SharePoint 2010 Project Template SharePoint Projects have standard properties Project File Project Folder Active Deployment Configuration Include Assembly in Package Assembly Deployment Target Sandboxed Solution Site Url Startup Item
SharePoint 2010 Project Structure Standard Project Nodes Properties References Features (New) Package (New) SharePoint Project Items
Feature node and Feature Designer Feature node contains one or more features Feature designer provides design mode Customize feature properties in designer and / or property grid Feature designer allows adding/removing SPIs
Mapped Folders Mapped Folders used to deploy to RootFiles Layouts folders maps to /_layouts Images folder maps to /_layouts/Images You can map other folders inside RootFiles directory. Layouts folder key to creating application pages Best practice to create solution – specific folder inside Layouts
Project Packaging Project packaging Modify package properties with designer or XML text Designer allows you to add/remove feature and SPIs
SPT Deployment Options Two Deployment Configuration by Default Default No Activation
The F5 Debugging Experience What does F5 do ? Builds new version of .wsp file Deactivates/Uninstalls features Retracts/deletes old .wsp file Adds/deploys new .wsp file Activates Features in target site (via Site Url) Attaches debugger to W3WP.EXE worker process (via Site Url)
Questions/References Visual Studio : http://blogs.msdn.com/visualstudio Training Course on MSDN: http://channel9.msdn.com/learn/courses/SharePoint2010Developer/VisualStudio2010ToolsForSharePoint2010/ My Blog: http://blogs.msdn.com/mahuja Email: firstname.lastname@example.org LinkedIn: http://in.linkedin.com/in/madhurahuja