VS.Net SharePoint Developer Explorer - code released

People faces some problems with SharePoint Designer 2007 and want to use other way to edit content using Visual Studio.
Vincent Rothwell created a useful Visual Studio add-in to give developers the ability to edit SharePoint content from within Visual Studio. Test this tool and tell us your comments.
You will find it with source code in the url below:
http://www.codeplex.com/spdevexplorer

WCM at MOSS 2007

Below is a step-by-step guide for how we ran the project:

Step 1 – Define your basic site map and designs
As in many web projects, the basic site map and designs informed the development teams of the basic functional requirements. The site map provided us a list of all of the different types of pages on the website, and the designs told us what features we were going to need to use. These both changed as the project progressed, but provided us with a useful baseline to start with.

Step 2 – Define your Content Columns and Content Types
Content Types are a great feature of SharePoint and provide the underlying structure to the whole site. Time spent at the start of the project to properly define the content types you require on your page layouts and your lists is always well spent. You don’t have to be exhaustive in your definition, but the more you do at the start, the less you have to rework later.

Step 3 – Define your Custom Lists
Lists are the backbone of the site; rather than free-text content blocks, we invested in a number of Site Collection level lists to ensure consistency and content reuse. An example of this is the Venue list, which is used by the site Events pages to provide information about the location of a site event. Since many of the Site events will use the same venues, we wanted to improve the user experience for content authors when adding a new event to the system. By creating a custom list, and adding a field to the Page Layout, we allowed content authors to select from a drop down list of available venues. When the page is then viewed by the end user, information from the selected venue was pulled through from the custom list and formatted appropriately.

Step 4 – Create the basic Site Hierarchy
If site is fairly small, so we created this via the user interface under Site Actions. In larger scale sites, where a full site hierarchy has been worked out in advance by an Information Architect, we would recommend using the stsadm -o createsite command, or writing a simple application to automate the initial structure creation via the API.

Step 5 – Add your images and CSS files
So, once you have your basic site hierarchy, your custom content types and your lists, it is time to start building the site to make it look like your design. This is the point where we fire up Office SharePoint Designer (SPD) for the first time. Using SPD, we were able to add our custom CSS files very easily. As with the Content Types, we wanted to ensure that we knew which files were “out of the box”, and which were added during the project,

Step 6 – Build your Master Pages
We had a number of pages which demanded quite different layouts, and since they were in different locations in the site, we chose to use multiple Master Pages. Having done the groundwork with the flat XHMTL we were able to quickly create new Master Pages. Since we also wanted to make use of existing page layouts in our site, we made sure that we maintained the same naming convention for our controls.

Step 7 – Build your Page Layouts
This is where we really saw the benefits of pre-defining our Page Layout Content Types and having our XHTML mockups to hand. Building a flat page layout is remarkably quick to do when you have done the groundwork – mainly because of the integration that SPD’s toolbox has with SharePoint. Adding a content field into your page is a matter of picking it up from the toolbox, and dragging it into your page – whether in Design mode or in Code mode. This is a great timesaver on your project – if you have defined your content types well, and described them properly, your developers do not have to keep referring to documentation to know what field controls are for, and what format those controls should be.
At this point, we had a working site, which looked fairly close to the designs, and allowed our authors to start the process of entering content into lists and creating new pages based on our Page Layouts. This streamlined our testing processes, since it meant that we were able to catch missing fields or functionality early in the project.
Step 8 – Customize your Content Query webpart views
Content Query web parts were the one of the most commonly used webpart on the website. We used them all over the place to aggregate content from lists, and we found very quickly that we had to move away from the standard set of views given by the web part in order to meet the designs we had been supplied. We were able to create custom XSLT templates to cater for these views, by modifying the itemstyle.xsl file, which is found in /Style Library/XSL Style Sheets in your Site Collection’s root site.
A really great feature of this is that simply by adding a new XSLT template to the itemstyle.xsl file automatically adds it to the dropdown list in the Web Part Properties screen and is therefore instantly available to authors on the site. This is a great timesaver, but be warned that syntax errors in this file can cause all instances of Content Query webparts in your Site Collection to break.

Additional Work: Page Comments
One of the key requirements for Ministry Of Sound was to allow page level comments on certain types of web content page. To resolve this requirement we turned to the design pattern shown by the Comments functionality in the Blog site template.
In the blog comments example, there are two lists – a Posts list, containing the blog posts themselves, and the Comments list, containing the comments. The Comments list has a column of type “Lookup”, which is configured to use the Posts list as its source. When viewing a blog post, a ListView and ListForm webparts are used to provide a view of the comments and a form to allow users to post new comments. This form automatically populates the lookup column with the correct Post.
We used exactly the same mechanism to provide comments for pages in the HedKandi site, except we used the Pages list instead of the Posts list.

Creating MOSS 2007 Theme

1. On the SharePoint server go to the Themes folder e.g. c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\Themes
2. Make a copy one of the existing theme folders and its contents rename it e.g. MyTheme.
3. Rename the .INF file within the MyTheme folder to MyTheme.INF
4. Edit MyTheme.INF.
1. At the info section, Change the title, to MyTheme. Change codepage, e.g. 22200, replacing the code page will fix error “A theme with the name “MyTheme 1011″ and version already exists on the server.”
2. In the titles section, rename the names to your new name. This section is to present the name in the different language.
5. Provide an image to give a preview of your theme. This image should be placed in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\IMAGES. E.g. tmbMyTheme.gif
6. Modify the c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\Layouts\1033\SPTHEMES.xml to include a reference to the new MyTheme theme

MyTheme
MyTheme
MyTheme has a white background with blue control areas and orange highlights.
images/tmbMyTheme.gif
images/ tmbMyTheme.gif

7. Modify the CSS within MyTheme folder to personalize your theme.
8. Run iisreset from the command prompt
9. Apply the new theme to a “test site”.

How to fix Security Validation errors in Sharepoint asp.net page

Problem: I got "The security validation for this page is invalid" when submitting web form

For reasons of security, Microsoft Windows SharePoint Services by default does not allow you to make posts from a Web application to modify the contents of the database unless you include security validation on the page making the request. Two kinds of security validation can be used, depending on whether the code on the page applies globally to a virtual server or Windows SharePoint Services deployment, or to a single site or site collection within the deployment.

Security Validation Type 1:

Updating data for a site or site collection. Two steps to be performed.

Step 1:

Add a page directive and a FormDigest control to the page making the request. The following directive registers the Microsoft.SharePoint.WebControls namespace:

<%@ Register Tagprefix=”SharePoint” Namespace=”Microsoft.SharePoint.WebControls”
Assembly=”Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c” %>

Step 2:

Include a FormDigest control within the form as follows:

<form id=”Form1″ method=”post” runat=”server”>
<SharePoint:FormDigest runat=”server”/>
<asp:Button id=”Button1″ style=”Z-INDEX: 101; LEFT: 282px; POSITION: absolute;
TOP: 282px” runat=”server” Text=”Button”></asp:Button>
</form>

Inserting this control on an ASPX page generates a security validation, or message digest, to help prevent the type of attack wherein a user is tricked into posting data to the server without knowing it. The security validation is specific to a user, site, and time period and expires after a configurable amount of time. When the user requests a page, the server returns the page with security validation inserted. When the user then submits the form, the server verifies that the security validation has not changed. For more information about this control, see the FormDigest class.
Security Validation Type 2:

Updating global data

Web applications that use methods of the Microsoft.SharePoint.Administration namespace, such as for creating or deleting sites and for global administrative customizations, require a different security validation. Add the following code to the .vb r .cs file in an application:

SPGlobalAdmin globalAdmin = new SPGlobalAdmin();
Context.Items[SPGlobalAdmin.RequestFromAdminPort] = true;
Page.RegisterHiddenField(”__REQUESTDIGEST”, globalAdmin.AdminFormDigest);

This security validation uses the AdminFormDigest property of the SPGlobalAdmin class to insert a message digest on the page in the browser, registering the digest as a hidden field through the RegisterHiddenField method of the System.Web.UI.Page class. In addition, the RequestFromAdminPort field specifies that the context of the request is through the administrative port

Using ASP.Net user controls in your WSSV3/MOSS ASPX pages

To use ASP.Net user controls in your WSSV3/MOSS ASPX pages do the following steps:
1. Create a Directory called "_controls" in the root of your sharepoint web site on the file system E.g. C:\Inetpub\wwwroot\wss\VirtualDirectories\SharePointSite\_controls
2. Open IIS manager and in the root of your SharePoint site create a VirtualDirectory called "_controls" and point it to that newly created directory.
3. Put your user control in that newly created directory on the filesystem.
4. Open the web.config file and add the following:
<safecontrol allowremotedesigner="True" safe="True" includesubfolders="True" src="~/_controls/*" />
5. In your ASPX page add the following:
<%@ Register src="~/_controls/SomeControl.ascx" src="~/_controls/SomeControl.ascx" TagName="somecontrol" TagPrefix="uc2" >
And...
<uc2:somecontrol id="mycontrol1" runat="server" />