Visual Studio SharePoint Development Blog

How to deploy a style sheet into content library using Visual Studio 2010 Beta 2

SharePointToolsBlog — Mon, 23 Nov 2009 21:31:00 GMT

If you do not want to inherit the look and feel of the out of the box SharePoint application and content pages, you can change it using Cascading Style Sheets (CSS). Style sheets can either be deployed to the Layouts folder or Styles library using Visual Studio 2010. Files deployed to the Layouts folder reside on the machine’s file system and the files deployed to the Styles Library reside in the content database. You can find more information on the pros and cons of deploying files to the Layouts vs. Styles Library in the following MSDN article, Implementing a Brand in a SharePoint Server 2007 Publishing Site. You can also deploy a style sheet to the Layouts folder using a mapped folder, which is not shown here.

In order to deploy a style sheet to the content database you will need to follow these steps:

1. Create an VS 2010 Empty SharePoint project

2. Add a new “Module” Item named “Styles” to the project

3. Delete the sample.txt

4. Right click on the “Styles” folder and add a .css file(found under web node in the Add New Item dialog) and name it “newstyle.css”, while adding the style tags that you would like to define.

5. In the elements.xml file, specify the Url of the Module as “Styles Library” and set the file Type as “GhostableInLibrary”

<Module Name="Styles" Url="style Library">
<File Path="Styles\newstyle.css" Url="newstyle.css" Type="GhostableInLibrary"/>
</Module>
6. Right click on the project and choose deploy.

7. The stylesheet should now be deployed to the style library which you can view by going to http://<MachineName>/Style%20Library/Forms/AllItems.aspx

You can reference the file like any other css file using the path http://<MachineName>/Style%20Library/newstyle.css.

Pallavi Vajranabhaiah

Channel9 Interviews and Demos

SharePointToolsBlog — Mon, 23 Nov 2009 18:01:00 GMT

The Visual Studio Team has been releasing a series of Channel 9 interviews and demos on the new SharePoint tools in Visual Studio 2010. Please check them out and give us your feedback!

Overview of SharePoint Development in Visual Studio 2010

Importing SharePoint Solution Packages (WSP) into Visual Studio 2010

SharePoint Feature and Package Designers in Visual Studio 2010

Using the SharePoint Business Data Connectivity Designer in Visual Studio 2010

SharePoint Server 2010 Beta is available

SharePointToolsBlog — Wed, 18 Nov 2009 18:35:00 GMT

Public beta release of SharePoint Server 2010 was announced today at PDC. This is great news for SharePoint developers because you can start using Visual Studio 2010 Beta2 to develop against SharePoint Server 2010. You can download SharePoint Server 2010 here.

Getting Started with the SharePoint Packaging Designers

SharePointToolsBlog — Mon, 02 Nov 2009 22:37:41 GMT

Visual Studio 2010 SharePoint Tooling supports packaging of WSP files with visual designers, tool-windows and MSBuild. Here we start by introducing the designers.

The feature and package designers expose deployment concepts which are familiar to SharePoint developers. These include features, packages and SharePoint items as well as their attributes and contents. Some of them include feature scope, feature dependencies, packaged assemblies, safe-controls, class resources, and more. Additionally, the designers abstract away the more difficult concepts and provide pre-deployment validation rules to avoid common issues when deploying your solutions. The designers allow advanced users partial or full control of the feature and solution manifest files to merge or add data and view the final product. Whatever your skill level you’ll find the new designers an exciting addition to your SharePoint development arsenal.

The best way to get started with packaging is to create a SharePoint project. SharePoint projects come standard with a Features and Package folder in your project. There are 0..n features in a SharePoint project and always 1 package. Here is a sample List Definition project as viewed in the solution explorer.

Opening the Feature1 designer shows that the List Definition and List Instance SP project items are included by default in the feature. The SharePoint items which are included in the feature are visible in the list on the right. Other available SharePoint items in the solution will be shown in the list on the left if they match the feature’s scope. Remember that you must have a compatible feature scope for SharePoint items to be packaged in this feature. Configuring the feature properties can be done via the property grid and some of these properties are visible on the designer UI.

In turn, the package designer can be opened to show that the feature is included in the package. Package related properties are exposed on the designer and in the property grid. At this point your solution is ready for packaging. Right click the project node and select Package to generate a WSP in the output directory. Packaging includes validation of the SharePoint package for potential problems, generating the feature.xml and manifest.xml files and packaging all the files for your SharePoint items.

Here is a look at the contents of the WSP once it is packaged for deployment.

Further information on Packaging and Deploying SharePoint Solutions can be found on MSDN here. Stay tuned for further updates from the team on SharePoint Tools and packaging in VS 2010. If there are specific topics you’d like us to address please feel free to post them to the comments.

Erik Cutts

Support for SharePoint 2007 in Visual Studio 2010

SharePointToolsBlog — Fri, 30 Oct 2009 18:41:00 GMT

On SharePoint conference Steve Ballmer announced that SharePoint 2010 Beta2 is going to be released in November.

In one of the previous posts I mentioned all project and project item templates that are supported if you are developing against SharePoint 2010. To develop and use new project templates you will need a 64-bit client or server OS and 64-bit installation of SharePoint 2010.

Experience for developing for previous release of SharePoint (Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3) with Visual Studio 2010 has not changed compared to Visual Studio 2008.

See the below table for comparison between Visual Studio 2008 and Visual Studio 2010.

Visual Studio 2008	Visual Studio 2010
SharePoint 2007	SharePoint 2007	SharePoint 2010
Sequential workflow and State Machine workflow	Sequential workflow and State Machine workflow (same project templates as in Visual Studio 2008)	All new features, project and project item templates (see previous post)
32-bit server OS and 32-bit MOSS only	32-bit server OS and 32-bit MOSS and WSS*	64-bit server or 64-bit client OS and 64-bit SharePoint 2010*
*64-bit OS and SharePoint are not supported	64-bit OS and SharePoint are not* supported	*Only 64-bit OS and SharePoint are supported

Check this link for hardware and software requirements for SharePoint Server 2010.

Peter Jausovec

Windows 7 and SharePoint 2010

SharePointToolsBlog — Thu, 22 Oct 2009 19:33:33 GMT

Windows 7 was released today and it was announced on SharePoint blog that Office and SharePoint Server 2010 will be available for broad Beta in November.

There is a good news for SharePoint developers – you can install SharePoint 2010 on both Windows 7 and Vista client machines. This means that you no longer need a server OS to develop for SharePoint (SharePoint 2010 client install is not supported for production only for development).

You can already get your Windows 7 copy online at Microsoft Store.

Peter Jausovec

Short Overview of SharePoint Features in Visual Studio 2010

SharePointToolsBlog — Wed, 21 Oct 2009 17:29:52 GMT

As you probably know, Visual Studio 2010 was announced earlier this week and it contains a lot of cool features and project templates for SharePoint developers. Below is a short overview for some of the SharePoint development related features and project templates.

Configurable deployment

With all new SharePoint project templates you can leverage new configurable deployment feature which lets you configure the way you want to deploy or retract your project. Besides using provided, out of the box deployment steps (Run Pre-Deployment Command, Run Post-Deployment Command, Recycle IIS Application Pool, Retract Solution, Add Solution, and Activate Features) you can use SharePoint extensibility to create your own, custom deployment steps and deployment configurations.

Sandboxed and farm solutions

Some SharePoint projects can be deployed either as sandboxed or farm solutions. Sandboxed solutions run in a secure and monitored process that has limited resource access and with farm solutions user must have SharePoint administrator privileges to run or deploy the solution. You can read more about SharePoint sandboxed solution here.

Extending SharePoint Tools

Even though Visual Studio 2010 contains a set of project templates you can also extend them. You can create extensions for projects, project items, define your own project item types and create deployment extensions. You can read more about extending SharePoint tools on MSDN.

Feature and Package Designer

Feature and package designers give you the ability to customize features in your solution and with packaging designer you can customize which features are getting deployed and how. More about feature and package designer is here.

SharePoint Explorer

SharePoint Explorer is a new tool window that gives you a view into your SharePoint server. You can get a hierarchical view of lists, sites and workflows on your SharePoint server.

SharePoint Project and Project Item Templates

The following SharePoint specific project templates and project item templates are available in Visual Studio 2010:

Project Templates

Empty SharePoint project
Visual Web Part project
Sequential and State Machine Workflow
Business Data Connectivity Model
Event Receiver
List Definition
Content Type
Module Project
Site Definition

Project Item Templates

Empty Element
Web Part
User Control
Application Page
Association Form
Initiation Form
Business Data Connectivity Resource Item
List Instance
List Definition From Content Type
Global Resources File

Besides above mentioned project templates, there are two import project templates for importing .WSP file contents and importing reusable workflows:

Import Reusable Workflow
Import SharePoint Solution Package

How to download, install and get started

If you are a MSDN subscriber, you can download Visual Studio 2010 from here. Download will be available to everyone on October 21st.

If you want to know how to download and install Visual Studio 2010 watch Channel9 video.

To get you started, head over to MSDN and read some of the walkthroughs on SharePoint Development in Visual Studio 2010.

Peter Jausovec

Learning SharePoint development

SharePointToolsBlog — Fri, 30 Jan 2009 03:51:00 GMT

I found an interesting Wiki on SharePoint development. Wiki contains info for admins, about the web UI, on SharePoint Designer and Visual Studio. Check it out at SharePoint Dev Wiki.

SharePoint development in Visual Studio 10

SharePointToolsBlog — Mon, 24 Nov 2008 22:31:31 GMT

Are you interested in SharePoint development and you're wondering what tools for supporting SharePoint development are coming in Visual Studio 10? Head over to Channel9 to view the video and get a sneak-peak.

How we test – a high level overview

SharePointToolsBlog — Fri, 10 Oct 2008 02:13:21 GMT

Hello, my name is Erik Cutts and I'm a tester (SDET) on the Business Applications team in Visual Studio. As a tester working on developer tools for several years I have had the unique opportunity to build tools for the best (and most demanding) customers in the world: Developers! As such I'd like to give you some insight into our day-to-day test activities which refine the quality of the tools you use in Visual Studio. In return, maybe you can share some thoughts on testing Office and SharePoint applications or just testing in general. Be aware that these practices do vary across Microsoft and this is based solely on personal experience.

Testers are involved throughout the development cycle, from initial product design through shipping and servicing. Initially, we work with our team on product planning and design to ensure that customer scenarios are being met and that we are shipping the right set of features. We also ensure that the product is testable and scoped correctly so that we have enough time to refine the features within the resource constraints we have set.

Once initial product design is defined test is responsible for authoring an overall test specification. The "Test Design Specification" document is a high-level overview of how we will test the product. This test strategy describes the scope of testing, test schedule, test configurations, external dependencies, risks and mitigations, division of labor and test tools and technologies. This document is live and is updated throughout the development cycle to stay up to date (features and schedules change as do customer requirements). The document is reviewed by our peers and management until we're on the same page.

Now the real fun begins, developers are writing code, features are being checked in. How do we make sure the product is of good quality? Test begins by authoring detailed test-case enumerations which include all the areas we need to hit. These include user scenarios, performance, accessibility, globalization, API testing, security and the list goes on. These tests are reviewed and updated. Once features start to come together we do some exploratory testing. This manual testing involves attacking specific feature areas and logging code-defects (bugs), suggestions, and spec-issues. These issues are resolved by our team and we verify that their resolutions are acceptable. As an aside, our division uses Team Foundation Server to store and track our issues. It's a complete solution for our bug tracking needs which provides excellent configurability, reporting and best of all it is integrated with all the other Visual Studio Team System features.

As our features mature we are ready to start test-case automation. Many of you are familiar with the benefits of test automation. In short, it allows us to execute test scenarios more often and across multiple configurations than a tester can execute manually. Most importantly it alerts us if product functionality which was working has regressed to a non-optimal state. Automation written by dev is different in that they write unit tests which exercise discrete components of the product. Testers excel at writing automation on a scenario level to ensure that the product works as a user would exercise it. Tests are broken down into priorities to determine how often they are executed. Test automation comes in many forms. API testing is used to test internal object models or libraries exposed to the user. UI testing is based on executing the product from the UI using accessibility interfaces to click buttons, enter text, use menus and exercise all other input methods. There are many other types of automated testing such as performance tests, stress tests, fault-tests, and other areas. It's worth mentioning that we are authoring and executing some tests using the Visual Studio test-projects with success.

As the product matures it is the testers' responsibility to report the overall quality of the product across the team. This is a difficult task. How do you measure quality? Number of bugs, performance results, code-coverage, and automation pass-rates are some of the measures. However, they don't tell you how it feels to use the product. For this task we really put ourselves in the customers' shoes. It's the overall feeling of how complete the product is, how it responds, how difficult or easy it is to complete a task that is most important to us. This Overall Goodness Factor (OGF) is incredibly helpful in understanding how close we are to release.

Throughout the product cycle we are working with the customer to get feedback and requirements for the product. Community Technology Preview (CTP) and Beta releases are great opportunities to gather this data. There are early adoption customers and partners which participate in the Technology Adoption Program (TAP). These customers promise to provide detailed feedback while we sign-up to support them with representatives from the product groups of the components they are using. We also use blogs (such as this one) and forums to get in touch as well as customer visits and conference attendance.

As the product cycle comes to an end the tester has a great responsibility. We double check the exit criteria and put our name on the dotted line for Release to Market (RTM) readiness. Once that's done the DVDs are burned and the ship party is scheduled. Each employee receives a shiny plaque on a ship-it award to remind us of our accomplishment.

I hope you've learned something about testing in our group. We're interested in learning more about how you do testing. How do you schedule testing? Do you have a specific test role in your business? Are you authoring automation for your tests or is this mostly a manual process? What examples do you have of testing for SharePoint and Office applications? How can we make it easier for you to test your products? If you are interested in hearing more about any of the above our team will be happy to continue blogging in more detail on these subjects. We look forward to discussing them with you.

Creating a simple sequential workflow

SharePointToolsBlog — Thu, 09 Oct 2008 00:45:00 GMT

Purpose of this post is to show you how to get started developing SharePoint MOSS 12 workflows with Visual Studio 2008 by creating a simple sequential workflow. Let's say we want to create a workflow that creates a task each time user creates new announcement in Announcement list.

First step is to launch Visual Studio 2008 and navigate to File → New → Project (or press Control + Shift + N) to open the New Project dialog. One note on launching Visual Studio 2008 – you have to launch it with administrator privileges in order to create SharePoint Workflow projects. SharePoint workflow project templates are located under Office 2007 node.

As soon as you click OK the New Office SharePoint Workflow wizard is displayed. On the first page of workflow wizard you can choose the name of your workflow and the local URL (you can use http://localhost) to which you want to deploy your workflow. For this example accept the defaults on first page and click the Next button.

First wizard page

On the next wizard page you can choose a library or list to associate your workflow with. The other two combo boxes are for selecting workflow history list and task list – by default there's only one history list and one task list on your SharePoint site (if you have added additional task lists, you will see them here).

Second wizard page

Selecting the "Automatically associate workflow" checkbox will associate the workflow with the selected list. If you unselect the check box you have to take care of workflow association manually.

Since we said we want our workflow to be associated with Announcements list, go ahead and select Announcements list from the first combo box and click Next. Last wizard page appears and it looks like the figure below.

Third (last) wizard page

There are three more settings on the last wizard page you can select. Below is the description of settings:

Manually by users: when checked, users can manually start the workflow.
When an item is created: when checked, the workflow is started when a list/library item is created (or uploaded).
When an item is changed: if checked, the workflow is started each time item in the list is changed.

We won't worry about these settings in our sample so click Finish to close the wizard. Once you click Finish the wizard is closed and our workflow project is created. I won't go into the details on files that are created in the project at this time. Let's focus on creating a task when a new announcement is added to the Announcements list.

Workflow designer should already be open and it contains one default activity: onWorkflowActivated1. This is executed, well, when workflow is activated. Go ahead and follow the below steps to add another activity to the designer:

Open the toolbox (View → Toolbox or Control + Alt + X) if it's not opened.
Locate CreateTask activity (it should be in the SharePoint Workflow tab) and drag & drop it onto designer, below the onWorkflowActivated1 activity. Sequential workflow designer should look like the one in figure below.

Notice the red exclamation mark on the createTask1 activity which is telling us that we have to set some additional properties. To do this, right click on createTask1 and from context menu and select Properties (or click on the activity and press F4 to open Properties window). When properties window is opened you can notice small exclamation mark next to the CorrelationToken property. Correlation token is basically an identifier – you can read more about CorrelationToken here (http://msdn.microsoft.com/en-us/library/ms475438.aspx). Type 'taskToken' in the CorrelationToken property. Notice the exclamation mark is still there. Expand the property (notice the + sign before the property name) and for OwnerActivityName select Workflow1.

In order to create a task we have to specify the TaskId and TaskProperties properties:

Locate TaskId property in the property grid.
Click on the ellipsis (...) next to the property.
Binding dialog is displayed.
Click 'Bind to a new member ' tab.
In 'New member name' text box type: 'taskId'.
Select Create Field.
Click OK.

Above steps will create a field in our code which represents task ID. You can repeat the same steps for TaskProperties – name the field taskProperties. Now that we have our ID and properties only thing left is to set the values for our task:

Double click createTask1 activity.
Once the code window is displayed type in the following code:

private void createTask1_MethodInvoking(object sender, EventArgs e)

{

taskId = Guid.NewGuid();

taskProperties.AssignedTo = "someone@example.com";

taskProperties.Description = "Description of my task created with workflow.";

taskProperties.DueDate = DateTime.Today.AddDays(5);

taskProperties.Title = "My super task from super cool workflow.";

}

The above code assigns new GUID to task ID and assigns some values to the task. You probably noticed that you don't have to actually call a method to save or create the task – the createTask activity takes care of this. All you need to do is to set properties for the task e.g. description, title, due date, assigned to. There are several additional properties you can set – just type taskProperties and after you type the dot ('.'), intellisense shows up and you can browse through other properties.

Now we're ready to debug! Insert a breakpoint in the createTask1_MethodInvoking and the breakpoint will be hit. When you press F5 your workflow is deployed and the browser should open up at Announcements list. To test the workflow, add a new Announcement to the list. Once you add the new announcement there should be a new column added to the list. The name of that column should be equal the name of our workflow (SimpleWorkflow) and it contains the status of the workflow (you should see Completed in that column).

If you click on the status (e.g. Completed) you are redirected to the workflow status page and you will see the task that was created as a part of our workflow. It should look similar to the one in the figure below.

Peter Jausovec

Getting Visual Studio 2008 SharePoint 2007 Sequential / State Machine Workflow projects working with Windows SharePoint Services 3.0

SharePointToolsBlog — Wed, 20 Aug 2008 00:18:05 GMT

I wanted to create a SharePoint workflow using VS 2008 on WSS 3.0. The documentation is set that only Microsoft Office SharePoint Server 2007 can be used but I figured I would lay out the modifications needed to allow a project to function on WSS 3.0. The four steps are:

1.) Since WSS 3.0 doesn't have a docs site and the wizard is particular about specific "sites" we need to change http://machinename/docs to http://machinename.

If not you will get the message:

"SharePoint site location entered is not valid. The SharePoint site at http://<machineName>/Docs could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application."

Go ahead and finish wizard with what you need. Once the project has been created

2.) Remove the reference to Microsoft.Office.Workflow.Tasks

Now depending if you are coding in VB or C# you should

3a.) C# open workflow1.cs code editor and remove "using Microsoft.Office.Workflow.Utility;"

3b.) VB remove import of Microsoft.Office.Workflow.utility.

4.) Now we have to remove some xml from the feature.xml file specifically

- ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

- ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver"

Now you should be able to debug the project .

Roger Best

What is the difference between sequential and state machine workflows?

SharePointToolsBlog — Fri, 25 Jul 2008 02:37:00 GMT

Since this is our second post to this blog, I thought we should start with something very simple. I am aware that most of you probably know the answer to the question in the title, but this post could help those who don’t know the answer or are not totally sure about it.

What could a state machine (workflow) be? Here’s the definition from Wikipedia:

State machine is a model of behavior composed of a finite number of states, transitions between those states, and actions. (from http://wikipedia/wiki/State_machine).

Let's explain that definition in a practical, easier to understand and to remember way. When you wake up in the morning you are hungry (or you just want some coffee very badly). We could call this state a "Hungry" state. Then, after you had something to eat you transition from the "Hungry" state to another state called "Full". And that's the whole 'science' of state machines. If you think about it, every one of us is always in either one of those states :). You could also add some more states like "Half-full", "A little hungry", etc.

So, what can you use state machine workflows for? You can use them for basically every business process that consists of states. Take for example a simple Word document and its lifecycle. You upload the document to SharePoint document library and the 'state' of the document at that point could be "Submitted". After document is submitted you can assign it to a user to approve or reject it and you get two more states: "Approved"/"Rejected”.

Norm Estabrook mentions an even better example of state machine workflows in his podcast about VSTO SharePoint workflow. Here is except from the recording:

"On the other hand, the steps in your solution may be random in nature and never really have a clear ending. For example, the participants in an HR workflow might move an employment resume from state to state. The resume might be in a state of being considered, interviewing, or archiving for future. The resume might be re-activated or updated at any time. Because there is no linear path of steps for the resume, it would be excessively hard to produce conditional rules to capture all possible paths. In these situations, you would want to manage your workflow as a series of states and transitions. Use the state machine workflow template to get started there."

When should you use state machine workflows? This is kind of a hard question to answer. You could use state machine workflow when for example a document requires multiple reviewers (legal, marketing, etc.) that may sign off on the document in any order. More complex state machines may open up different workflow paths depending on intermediate state.

How about sequential workflow? Sequential workflows are definitely much easier to design and maintain than state machine workflows. The only difference between a state machine workflow and sequential workflow is that in sequential workflow the flow goes from first activity to the next until end of the workflow is reached. In between you can branch the workflow, for example use IfElse or While activity, etc.

What type of workflows are you using more frequently - state or sequential? Are there any rules on when to use specific type of workflows?

Peter Jausovec

Welcome to the Visual Studio SharePoint Tools Blog!

SharePointToolsBlog — Wed, 02 Jul 2008 00:54:00 GMT

Before we get into any technical details, I just wanted to give you the background on how we came up with the idea of having this team blog, what this blog is about, as well as who will be contributing to the blog.

Some of you may have read Peter Jausovec's VSTO blog. One day, while I was brainstorming with Peter on what we could do to get more involved in helping our customers. The goal was to be helpful to our customers but also something fun to do away from our day to day jobs - this doesn't mean our jobs are not fun. :)

We had so many different options, but after weighing on the pros and cons of each, we locked onto the idea of creating a team blog focused on SharePoint Workflows and some of the Office client features. With this team blog, each team member has the opportunity to share his or her insightful knowledge from years of experiences by building the product. We also hope through this blog, we will learn from our customers.

About us? Well, we are a group of Software Design Engineers in Test. The majority of contributors to this blog have been working on VSTO related product or features for quite a few years. From time to time, we will also invite our Program Managers and Developers to be guest contributors. (They may have a few good thoughts to share too!) We currently plan to make 2 to 3 posts on a monthly basis; topics will be mainly on the released products or features. If there is anything specific you want to see us blogging, we would love to hear your feedback.

The types of content you will probably see here include but not limited to:

How to – tips & tricks, articles on development, deploying Workflows
Code snippets or power tools
Links to interesting stuff
Personal experience while building or using the product.
From time to time, we might post videos that document how we work as testers, or PMs, or developers.

We plan to make this a fun team activity. There are many incredible creative people on the team. The odds of seeing completely unexpected posts here is pretty high. Check back often! You never know what you may discover! You can subscribe to email alerts or use your favorite blog reader to follow our posts. Please feel free to contact us or post comments too. We love hearing and seeing the creativity of customers as well!

Jing Lou & Brent Williams

On behalf of the Visual Studio Business Applications SharePoint Tools QA team