Tommy Segoro

Managing Risks in Sharepoint 1 - Aligning the Environments

tommysegoro — Mon, 29 Jun 2009 01:43:00 GMT

INTRODUCTION

I just want to share with you my experience in managing Sharepoint environments (both server and custom code). Before, I came from a development background and purely think as a developer. As a developer, I used to think that as long as my code is bug-free and memory-leak-free then I'm safe.

Now, I've got some experience in managing the servers, I can share with you the things that we have to be aware of more than just having a bug-free and memory-leak-free code. This article will (as usual) come in series so if you're interested, please stay tuned and read the series. I also would also like to see comments and sharings from you so that we can all learn from each other.

MANAGING RISKS 1: KEEP YOUR ENVIRONMENTS ALIGNED

The Sharepoint environment I'm currently working on has the following server topology:

- 1 DB
- 2 WFE
- 1 Central Admin
- 1 Indexing Server

The same topology was also created for Test (yes, it's EXTREMELY important to have a Test environment for Sharepoint just like general .NET development). The goal is whenever we deploy things (code, solutions, features, etc) to Test, we would expect the same results in Production (ie. if it fails in Test then it will fail in Prod and vice-versa).

The idea is great but the problem is, this client's Test and Production weren't installed by the same person. One person setup the Prod and another person setup Test. Hence, we now have different settings and configurations in both Test and Prod.

This will create a huge risk, because if we deploy things in Test, we can never guarantee that the same would succeed in Production even if they successfully pass testings in Test.

Therefore, the very-very first step I would do is to ensure that both Test and Production are aligned. These are (and not limited to):
- The server topology
- The user accounts used to run MOSS/Sharepoint services (Search, SSP, etc etc)
- The configurations (SSP config, Central Admin config, email settings, etc)
- The solutions installed
- The features activated
- The code and DLL deployed (even third party DLLs such as stsadm extensions, etc)
- Web.config settings
- IIS settings
- SQL server settings
- AD settings for each user account used in Test and Prod
- The resource settings for both Prod and Test (RAM, Hard Disks, Processor Utilization, etc)

By ensuring that the settings above are the same for both Test and Prod, we can now expect that the deployment results will be exactly the same. If your deployment breaks in Test then it will most likely break in Production.

TAKE IT FURTHER

I would actually like to take this further. Even the developers' machine - although it's impossible to create the topology within each developer's machine - is at least installed using Test/Prod user accounts and configured using exactly the same configuration. This has worked really-really well for me. I can now be very confident that whatever fails on my machine will also fail in Test and Prod and vice versa (whatever succeeds on my machine will also succeed in Test and Prod).

DOCUMENTATION

This is the bit that I HATE! :) As a developer, there is nothing worse than writing a documentation. Anyway, it's EXTREMELY important to document the setup process for both Test and Prod. Take screenshots as you go through each step and document them. You can use MS Word to Copy Paste things easily or even OneNote with its screen clipping feature. It's really-really handy. Just like taking your wedding photographs for memory, that's how valuable documentation is for us.

From my experience, I will forget within one day what steps I took to setup MOSS. So guys...get your documentation tight.

STILL THERE IS ONE RISK LEFT

The CONTENT DATABASE is the major risk. You would never be able to always align content database. You will be surprised how quickly the content in your machine and in Test are outdated. People will upload more and more documents in Prod and even worse, some of the users are stupid enough to create content types and meta-data directly in Prod!

I'll discuss about this more later.

Hope this helps and please stay tuned for next series,
Tommy

MOSS Manual Navigation Links Are Static - DANGEROUS

tommysegoro — Mon, 29 Jun 2009 01:16:00 GMT

INTRODUCTION

We just completed a MOSS server rebuild project which we managed to align both Production and Test environments with exactly the same topology and configurations. We installed using the exactly the same user accounts, configurations and even the list of features and solutions. After we configured the farm, we then took Production's latest database backup and restore it in Test. Everything worked perfectly except one thing:

The manual links in navigation menu items are not updated.

You know that in MOSS you can go to Site Actions -> Site Settings -> Modify Navigation, right? And we can create external/manual links, correct? The problem is, some of the users have created links that point to a document/page within MOSS but using static URL instead of relative. The problem is, these manual/static links are NOT updated after database restore to a different environment.

For example:
http://intranet/Pages/Home.aspx is meant to be updated to http://test-intranet/Pages/Home.aspx.

This will create a huge risk because we've actually had problem before when user thought they're still in Test but they're actually in Production. And guess what...he deleted a site that he thought was in Test.

SOLUTION

Anyway, to cut the long story short, I've managed to come up with a very simple SQL statement (which some of you must have known anyway) that can allow us to modify static links into relative links:

update navnodes set url = REPLACE ( url , 'http://intranet' , '' ) where url like '%http://intranet%'

The above statement will update ALL static links in navnodes table (which is the table used by MOSS navigation control) and remove any static reference to any page/document within MOSS.

WHAT LINKS ARE UPDATED BY DB RESTORE?

- Links within content query web-part or page content field

- Automatic links that are created by MOSS in navigation items as a result of creating a page/sub-site

WHAT LINKS ARE NOT UPDATED?

- Manual/static links in MOSS Navigation Items although they may point to a page/document within Sharepoint itself

Hope this helps,
Tommy

CompleteSharepoint.NET v2.0 - Content Management System Built on Top of WSS 3.0 - Documentation

tommysegoro — Sat, 23 May 2009 09:50:00 GMT

INTRODUCTION

Hi everyone,

I've just recently released CompleteSharepoint.NET v2.0, please see http://www.completesharepoint.net for more details. I've also written a blog article about it http://www.sharepointblogs.com/tommysegoro/archive/2009/05/18/completesharepoint-net-v2-0-content-management-system-cms-built-on-top-of-wss-3-0.aspx.

I've got some queries from some people that have tried to install it and they have problems with it. I've tried to install it on Microsoft's WSS VPC and it actually worked totally fine! So I'm sure there may have been some missing steps.

Anyway, I've just released a Developers Guide (available from both CodePlex http://www.codeplex.com/completesharepoint or from http://www.completesharepoint.net itself) that will provide installation and customization/development instructions.

My friend Jeremy has written an article about it at http://wss.made4the.net/archive/2009/05/18/reviewing-open-source-sharepoint-products-first-look-at-completesharepoint-net-v2-0.aspx and seems that he himself had trouble with. He said that the application didn't run on a clean environment while I've installed it on three different environments (including Microsoft WSS VPC) and they all worked fine. So I need you all to help me by installing CS.NET on your machine and let me know what the outcome is.

Anyway, with the Developers Guide, I hope that it will help you with the installation of CompleteSharepoint.NET.

Please contribute to my blog or sending me emails regarding issues/problems/comments of CompleteSharepoint.NET. I promise that I will keep improving this application and I'm sure - based on comments made by some of my colleagues around the world who have used it - that this application has a lot of potentials and will help a lot of people.

So please keep supporting me guys, I would love to hear a lot of comments and suggestions.

Cheers,
Tommy

CompleteSharepoint.NET v2.0 - Content Management System CMS Built on top of WSS 3.0

tommysegoro — Mon, 18 May 2009 01:53:00 GMT

INTRODUCTION

Hi everyone, I thought I would love to share with you my latest development. I've ever written CompleteSharepoint 1.0 that was released months ago. It's basically a CMS built on top of WSS. It's meant to be an alternative to MOSS. You will not want to spend $50K on a simple information website with MOSS, will you? Well, I won't.

Anyway, I've released version 1.0 which has a lot of defects of course. I've now re-written the code to be a lot better and I've just released v2.0 last night. Please go to http://www.completesharepoint.net for more information.

Some of the features are:
- Page editing toolbar
- Versioning
- Page edit mode
- Custom content type
- Custom page layouts and master pages
- etc

Below are some screenshots:

Create Publishing Page

Publishing Page - Display Mode

Publishing Page - Edit Mode

Page Editing Toolbar - Edit Mode

Sharepoint IIS Error - You are not authorized to view this page

tommysegoro — Thu, 14 May 2009 07:55:00 GMT

INTRODUCTION

I can access my Sharepoint site from remote machine's browser but not from the Sharepoint machine that hosts that site. I keep getting authentication box whenever I tried to access the Sharepoint site and its sub-sites/sub-folders/pages.

The fix is actually to disable security check on loopback in registry.

http://support.microsoft.com/kb/896861

Hope this helps,

Tommy

How Sharepoint Geek Proposes for Marriage

tommysegoro — Mon, 02 Mar 2009 05:31:00 GMT

INTRODUCTION

Just thought of sharing this with you as I was blessed with a beautiful girl of whom I just proposed yesterday. Anyway, please visit our website at http://www.tommyfrancesca.com and it's fully created using CompleteSharepoint.NET (http://www.completesharepoint.net) - a content management system built on top of WSS 3.0. Cheers everyone.

CompleteSharepoint.NET in Action - CMS Built on top of WSS 3.0 - www.bmuu.com.au

tommysegoro — Sun, 08 Feb 2009 23:55:00 GMT

INTRODUCTION

Several months ago I wrote a simple Content Management System (CMS) built on top of WSS 3.0 called CompleteSharepoint.NET (http://www.completesharepoint.net). I've just got a client who is currently using it in action.

http://www.bmuu.com.au

For more information about CompleteSharepoint.NET please go to http://www.completesharepoint.net or http://www.codeplex.com/completesharepoint. Please note that this is still in BETA and will have ongoing code upgrade.

Cheers,
Tommy

MOSS 2007 Search Crawling Error - Access Denied

tommysegoro — Tue, 03 Feb 2009 03:47:00 GMT

INTRODUCTION

Last week I had this problem where search service couldn't index my Sharepoint site. It said that access is denied and asked me to make sure that I'm using the correct content access account. The exact error message was as below:

Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)

I have done the following:
- Add the default content access account as a Farm Administrator
- Add the default content access account as a Site Collection Administrator
- Add the default content access account as SYSADMIN on ALL Sharepoint-related tables in SQL Server (including Sharepoint_Config)
- Add the default content access account as a local Administrator

I've done everything and given full access to the default content access account to everything but yet I still couldn't get rid of the problem.

SOLUTION

The solution is somehow something not too related to Sharepoint. Please check out http://support.microsoft.com/kb/896861.

That's it!

I've got the following infrastructure configuration
- Proxy is set in Internet Explorer for Internet access although accessing the Intranet should bypass proxy.
- To access local resource (ie. Sharepoint instance on my local machine) I can't edit the HOSTS file freely simply because we have proxy setup. Therefore, I have to use mydomain.local suffix (eg. http://intranet-devlocal.mydomain.local).
- When I configure the content source to use http://intranet-devlocal.mydomain.local, it says that it can't find the Sharepoint site.
- So I had to then create an alternate access mapping with the name http://intranet-devlocal. It could then find the Sharepoint site but I then had that access denied error.

Hope that this helps everyone who experiences the same problem.

Tommy

Sharepoint Farm - Document Library Returns Incorrect Document Version on One WFE but OK on Another WFE

tommysegoro — Mon, 19 Jan 2009 00:08:00 GMT

INTRODUCTION

I'm currently working at a client site who has the following Sharepoint Intranet farm configuration:
- 2 Web Front End (WFE) servers
- 1 Central Admin server
- 1 Indexing server
- 1 Database

There is a load balancer that should balance the load between the 2 WFE however it doesn't work properly. Somehow, the load balancer always points to the first WFE. Therefore, if you access http://intranet it always points to the first WFE.

The Intranet works OK everyday until one point few months ago it started to return the incorrect version of the document. For example, you upload a document and check-in as version 0.1. When you navigate to the document via the URL directly (eg. http://intranet/DocumentLibrary/MyDoc.doc) it returns you version 0.1 which is correct. Then you upload a new version of the document, override the old version and check-in to become version 0.2. Now, when you navigate directly to the URL of the document, somehow Sharepoint returns it with version 0.1. What's strange is, this only happens on the first WFE. If you force-point http://intranet to the second WFE via editing HOSTS file, you get the correct version of the document!

We have looked at this problem for quiet some time now and we finally resolve it after few weeks of investigation. We know that there must be something different (configuration, etc) on first WFE compared to the second one because the second WFE always returns the correct version of the document. Therefore, this is what we've done:
- Checking and comparing IIS settings
- Checking and comparing web.config settings
- Checking Sharepoint cache settings
- Checking load balancer cache settings
- Checking the actual document data in SP database! Yep, we actually went into Sharepoint DB and looked for that particular document in AllDocs table and the data that is stored in the DB is actually correct (ie. the newer version is stored correctly)

SOLUTION

So, what's the problem then? The DB clearly stores the latest version of the document so there is no reason for Sharepoint to return the incorrect version of the document. After further investigation we actually found out that the problem was actually with the BLOB CACHE settings! In web.config someone has turned on BLOBCACHE and somehow the cached documents in first WFE aren't synced with second WFE's. When we clear the BLOB CACHE folder of first WFE, it starts to return the CORRECT version of the document! So from this moment on, we will ensure that the blob cache folder content is synched between first WFE and second WFE.

If anyone has ever had the same problem, this may help.

Cheers,
Tommy

Site Template Definition Error: The Template You Have Chosen is Invalid or Cannot Be Found

tommysegoro — Fri, 16 Jan 2009 00:36:00 GMT

INTRODUCTION

I got this error message when I tried to create a site using my custom site definition:

The template you have chosen is invalid or cannot be found.

SOLUTION

The problem is, on my custom WebTemp file I use an ID which has been used by other custom site definitions I developed previously. See below.

</Template>

I'm wandering if there is a tool out there that can check whether a particular ID has been used or not. It will be very-very handy if you have to develop so many custom site definitions.

Cheers,
Tommy

Sharepoint Incoming Mail Bug or Is It Just Me?

tommysegoro — Fri, 09 Jan 2009 05:11:00 GMT

INTRODUCTION

I'm currently working with a 5-server farm Sharepoint installation:
- 1 Central Admin
- 1 Search Indexer
- 2 Web Front End
- 1 Database

For several months the document libraries which have "incoming e-mail settings" specified never receive email any more. The SMTP service is installed on the Central Admin server.

THE PROBLEM

When I troubleshooted the issue, I noticed that the emails were sent to the drop box successfully but somehow the Sharepoint Timer never grabs and delivers them. I've looked at several things including:
- Checking if WSS_ADMIN_WPG and WSS_WPG have write access to the Drop folder
- Checking if WSS_ADMIN_WPG and WSS_WPG have administrator access to the SMTP server
- Checking if email relay is opened for anonymous
- Checking timer service jobs in Central Admin for unfinished tasks

When checking the timer service jobs I noticed no errors. Every task was finished successfully.

I then looked in the log files and there are no errors specifying the email service. So what is then the problem?

After I looked more closely, the Sharepoint Incoming Mail service was actually run on the two web front-end servers and not the Central Admin server. The email address of the library is set to the Central Admin domain (eg. LIST@CentralAdminServer.com) and the emails are correctly dropped into the Drop folder of the central admin server but the Sharepoint Incoming Mail service actually looks for the Drop folder in the two web front-end servers! Since those emails are not copied automatically from the Drop folder of Central Admin server to the WFE servers, they never get delivered at all!

SOLUTION

The solution of this problem that I could think of was to create a simple File Watcher application that automatically copies all new files from the Drop folder of Central Admin server to the two web-front-end servers and now incoming email is working.

Hope this post helps everyone who has the same problem.

Cheers,
Tommy

Why Sharepoint Development Projects Failed Part 2

tommysegoro — Fri, 09 Jan 2009 01:59:00 GMT

INTRODUCTION

This is the second part of the series. For first part please go to http://www.sharepointblogs.com/tommysegoro/archive/2008/11/21/why-sharepoint-development-projects-failed-part-1.aspx.

WHY FAILED 2: DESIGN PATTERNS, TOO HIGHLY COMPLICATED ARCHITECTURAL PERSONNEL

The second reason why Sharepoint development failed is because of the conservative-design-patterns-centric-who-always-thinks-that-design-pattern-and-thousand-layered-development-is-the-best-way-to-go type of senior developer. To be honest, I also came from a custom development background and yes, with custom development you are actually expected to understand and apply design patterns to your application. However, with Sharepoint, it's kinda different. Put it this way, the way Sharepoint project is structured is already different altogether. I can say that I'm actually not a Sharepoint developer but a Sharepoint customizer instead because that's what I do: customizing Sharepoint.

A lot of developers that I met before tried to apply these design patterns (MVC, MVP, etc) to a Sharepoint application and it ends up making it too complicated for everyone. Sharepoint is even utilising content database to store ASPX, master pages and user controls. Yes, of course with the solution template (http://www.codeplex.com/vs2008sp, WSPBuilder, STSDEV, etc) you can develop everything in Visual Studio. However, the project structure is so different. Although you can still apply MVC, MVP, etc but if we're looking closely on our project management timeline, there is no way that we'll meet our deadline using design-pattern approach. Don't get me wrong, design pattern is one of my passions in development.

Customizing Sharepoint should be straight forward. Even if you work with its framework, it is already quiet complicated altogether (hence Sharepoint knowledge shortage). To be honest, I personally don't find Sharepoint is as hard as custom application. In fact I spend a lot less time customizing Sharepoint. If I have to build my CompleteSharepoint.NET (http://www.completesharepoint.net) application (which is a simpler version of MOSS-like CMS built on top of WSS 3.0) using custom .NET application, it will take me twice-three times longer. A lot of the stuff is already built in (lists, document libaries, versioning, etc) and we just need to work with them. The SDK is also already built in, you don't have to build your own data access layer, etc.

In a nutshell, we just need to know where everything are and where to deploy our files into and that's pretty much it!

CONCLUSION

Therefore, my lesson for myself when developing Sharepoint is, "it's already complicated, don't make it more complicated". Seriously, MVC and MVP just won't work with Sharepoint. I don't need to apply any design patterns (and loosely-coupled type of code) to maintain and share my code with my team easily.

Well, at least that's my point of view.

Why Sharepoint Development Projects Failed Part 1

tommysegoro — Fri, 21 Nov 2008 00:06:00 GMT

INTRODUCTION

In this opportunity I would like to share with you on why Sharepoint development projects failed. This will be based purely on my knowledge and experience therefore I would love to hear your comments and sharings, too.

TARGET AUDIENCE

The target audience of this series are developers, BDMs and project managers.

WHY FAILED 1: INADEQUATE KNOWLEDGE ON SHAREPOINT

The first reason why Sharepoint projects failed is because of inadequate knowledge on Sharepoint. When I say "failed" it means that the project either doesn't meet client requirements at all or it does meet client requirements but then it's gone over budget and over the given deadlines and time frames.

A lot of project managers, BDMs and sales people are offering Sharepoint to clients simply because they buy into the hype. Just because Microsoft says that Sharepoint can do this and that (be it document management, internet or intranet applications) it doesn't mean that you have to use it as a solution. A lot of people just haven't realised how complicated Sharepoint is - or I should restructure the words better - a lot of people don't realise what it takes to customise Sharepoint yet they have started to offer it to clients. At the end of the day the project either goes over budget or meeting a brick wall (ie. can't find an easy way out to find a solution for particular client requirements) or it doesn't meet the client expectations at all.

I've tried to build my own custom solution on top of Windows Sharepoint Services 3.0 called CompleteSharepoint.NET and it's a simple web content management system as a replacement of MOSS. Since I developed it, I get to understand Sharepoint more and more and now I know what it takes to customise Sharepoint. Yes, it's a development platform more than just a product, yes you can build custom applications on top of it but you also need to know what it takes to make it happen.

When Sharepoint project failed people then blame it for its complexity. I never know such thing is complicated if you have a solid understanding on what it does and I feel sorry for Sharepoint (and Microsoft) because they get blamed so many times yet it's not their fault. Every product has its own advantages and disadvantages, strengths and weaknesses. Sharepoint is also the same, you will only benefit from it if you can maximise the strengths and cope with the weaknesses.

My personal recommendation is (before you even select Sharepoint as a solution offering), get to know the product first. Make sure you've consulted with a Sharepoint expert and make sure that what you want can be achieved with Sharepoint. For example, a BDM may have a lot of experience in document management system. He of course knows what DMS system should have (ie. the features). He should then consult to a Sharepoint expert whether these features either come out-of-the-box with Sharepoint or can be developed on top of easily.

When you have a quiet solid understanding of how Sharepoint works and what the features are, you can then be more comfortable offering it to clients. I always like this phrase, "It's better not to start anything rather than starting something and not finishing it well". A good leader is someone who finish what he has started and he finishes it well.

CONCLUSION

A good salesman will know his product. I can't tell you how good Carbonara Pasta is if I never try it myself. I can't tell clients how good Sharepoint is if I don't even have an adequate knowledge of what it does and what it can do.

CompleteSharepoint.NET - Open Source Content Management System on top of WSS 3.0

tommysegoro — Wed, 29 Oct 2008 13:32:00 GMT

INTRODUCTION

Hi everyone, I've just written a content management system on top of WSS 3.0. I'm utilising my solution template and I've provided the source code for free. Please go to http://www.completesharepoint.net. I tried to mimic MOSS 2007 functionalities but in their simpler version. It has page editing toolbar, custom page layout, custom publishing content type, etc. Please have a look on the screenshots below:

Please note that this is still in beta mode. You can download the source code but you will find so many things that can be improved. Thanks everyone I hope to hear some feedback.

Page Editing Toolbar

Editing a Page

Creating a Publishing Page

Custom Site Actions Menu

Sharepoint Solution Syntax Part 2

tommysegoro — Fri, 10 Oct 2008 06:18:00 GMT

INTRODUCTION

Continuing from my previous post http://www.sharepointblogs.com/tommysegoro/archive/2008/09/14/sharepoint-solution-syntax.aspx I will discuss further on the syntax required for creating other elements of Sharepoint. In my previous posting, I've mentioned to you about how to create site definition, master pages, page layouts, content types and fields using feature. In this posting, I will mention about creating web parts, event receivers and feature receivers.

WEB PARTS

To create web parts you will need the following structure:

Inside HelloWorldWebPart.webpart you have:

<webParts>
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
<metaData>
<type name="WSPBuilder.WebParts.HelloWorldWebPart, WSPBuilder, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6109cdf7233db6c5" />
<importErrorMessage>Cannot import this Web Part.</importErrorMessage>
</metaData>
<data>
<properties>

<property name="ChromeType" type="chrometype">Default</property>
<property name="Title" type="string">Hello World Web Part</property>
<property name="Description" type="string">Use to create classic Hello World excitement</property>
<property name="CatalogIconImageUrl" type="string">/_layouts/images/IMAGE.GIF</property>
</properties>
</data>
</webPart>
</webParts>

Inside Elements.XML:

Inside Feature.xml:

FEATURE RECEIVERS

For feature receivers you will need the following syntax:

Inside Feature.xml:

<Feature Id="6873B8E8-848D-461d-9494-9422E354AE6B"
Title="Test Site Feature Receiver"
Description="This is the feature that sets the CompleteSharepoint.NET publishing lists without approval."
Version="1.0.0.0"
Scope="Web"
Hidden="False"
DefaultResourceFile="core"
ReceiverAssembly="SPTemplateLand, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a829755eafa973db"
ReceiverClass="SPTemplateLand.FeatureReceivers.MyFeatureReceiver"
xmlns="http://schemas.microsoft.com/sharepoint/">
</Feature>

You will then need to create your feature receiver class.

EVENT RECEIVERS

With event receiver, you need to have the following syntax:

The first feature is the feature that deploys your custom list. You can get the syntax from CustomList feature that Microsoft has deployed inside the FEATURE folder of your 12 hive.

Inside Feature.XML:

<?xml version="1.0" encoding="utf-8"?>
<Feature Id="EAD2A016-DB17-4f7b-94CE-A3EC6CF5D815"
Title="My Custom List Feature"
Description=""
Version="1.0.0.0"
Scope="Web"
DefaultResourceFile="core"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="CustomList.xml" />
</ElementManifests>
</Feature>

Inside CustomList.XML (note the Type property):

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<ListTemplate
Name="CustomList"
Type="10050"
BaseType="0"
OnQuickLaunch="TRUE"
SecurityBits="11"
Sequence="410"
DisplayName="$Resources:core,custList;"
Description="$Resources:core,custList_Desc;"
Image="/_layouts/images/itgen.gif"/>
</Elements>

The second feature is then the feature that deploys the Event Receiver feature.

Inside Feature.XML:

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="9EF6A5A1-AF0A-494e-BB78-93BA3730E6EC"
Title="Custom List Event Receiver"
Description="An Event handler that supports the addition/modification/deletion of list items throughout various sites in the collection."
Version="1.0.0.0"
Hidden="FALSE"
Scope="Web"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="Elements.xml"/>
</ElementManifests>
</Feature>

Inside Elements.xml (note the ListTemplateId and the Type property of the event):

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Receivers ListTemplateId="10050">
<Receiver>
<Name>SPTemplateLandEventReceivers</Name>
<Type>ItemDeleted</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>SPTemplateLand, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ea47656c35c3a98</Assembly>
<Class>SPTemplateLand.EventReceivers.CustomListEventReceiver</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
<Receiver>
<Name>SPTemplateLandEventReceivers</Name>
<Type>ItemUpdated</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>SPTemplateLand, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ea47656c35c3a98</Assembly>
<Class>SPTemplateLand.EventReceivers.CustomListEventReceiver</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
<Receiver>
<Name>SPTemplateLandEventReceivers</Name>
<Type>ItemAdded</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>SPTemplateLand, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ea47656c35c3a98</Assembly>
<Class>SPTemplateLand.EventReceivers.CustomListEventReceiver</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
</Receivers>
</Elements>

You will then need to build your custom event receiver class that inherits from SPItemEventReceiver.

CONCLUSION

So there you go. Hope this helps. To be continued.

Sharepoint Team Development with Visual Studio 2005 2008 Part 4

tommysegoro — Fri, 10 Oct 2008 01:52:00 GMT

INTRODUCTION

Hello hello...I've said in my last post http://www.sharepointblogs.com/tommysegoro/archive/2008/09/25/sharepoint-team-development-with-visual-studio-part-3.aspx that that post was going to be the last post in this series. But I actually lied!

In this post I will focus more on the tools. I've played around with another 2 tools: SPTemplateLand and WSPBuilder and in this post I will list the advantages and disadvantages of using both tools (once again these are only based from my experience). So please agree/disagree with me. Thanks.

TOOLS AND MORE TOOLS

I just tried 2 new tools for generating features and solutions for me: SPTemplateLand (http://www.codeplex.com/sptemplateland) and WSPBuilder (http://www.codeplex.com/wspbuilder). Both are excellent tools to generate the solution file automatically.

I will start with SPTemplateLand first.

SPTEMPLATELAND (http://www.codeplex.com/sptemplateland)

Advantages:
- Generation of the WSP file automatically.
- Simple yet fulfilling the purpose.
- Not relying on any executables for it to run.
- Easy to modify for any projects.
- Deploy files to the correct location.

Disadvantages:
- No Visual Studio built-in commands.
- You have to have at least one feature definition in your project otherwise the manifest.xml will not render correctly and you won't be able to add your solution to Sharepoint using the STSADM command.
- If you want to deploy your DLL to GAC, you have to copy it manually inside the DLL folder.
- No batch scripts by default so you have to remember the STSADM syntax for installing, deploying and upgrading the solution.
- Key.snk is not part of the solution so you have to create and sign your assembly manually.
- No reference to Microsoft.Sharepoint and System.Web automatically. You have to add them manually.

In general, I like this solution template as it's very simple and yet fulfilling its purpose to generate and deploy WSP automatically. Things that I mention in the Disadvantages section are not really major. They of course will be improved in future versions hopefully.

WSPBUILDER (http://www.codeplex.com/wspbuilder)

Advantages:
- Built-in Visual Studio project template. It's very nice to have a project which namespace and assembly names have been automatically-generated based on the project name.
- Yet still quiet simple to use.
- Deploy files correctly to the correct location.
- Key for signing your assembly is now part of your project.

Disadvantages:
- Relying on the executable.
- No Visual Studio built-in commands.
- Config file may be confusing. There are so many options that you can enable/disable and the documentation is rather not clear.
- Doesn't have any batch scripts so you have to remember the STSADM commands for installing, deploying and upgrading your solution. You may also need to add your WSPBuilder.exe to the PATH environment variables so you can run it from anywhere within your folder.
- No reference to Microsoft.Sharepoint and System.Web automatically. You have to add them manually.

CONCLUSION

So there are just some of my findings with those tools. I've got nothing to against any of these tools. If they've been working for you then please keep using them. I kept saying this over and over again, it doesn't matter what tools you use as long as they can help you deploying your solutions and features automatically.

I've also created my own please go to http://www.codeplex.com/vs2008sp which is kinda similar with the tools I've mentioned above except it has built-in Visual Studio build commands.

Custom Document Library using List Definition Schema.XML Version Not Appearing on Office Documents

tommysegoro — Mon, 06 Oct 2008 09:04:00 GMT

Do you know that the "URL" property of the Schema.XML on your custom list definition can make the version selection in your Office applications disappearing when you're trying to check-in your document?

OOTB it should be:

But an incorrect URL property in the SCHEMA.XML will cause it to look like below:

The version selection somehow disappears!

So what's the problem? The problem is this:

<List Name="My Custom Documents" Title="My Custom Documents" Description="" Direction="0" BaseType="1" Url="Lists/MyCustomDocuments" .........

You can NOT have the word "Lists" in the URL.

Same with your list instance in your Elements.XML (if you deploy your custom list using feature):

Remove the word "Lists" from the URL so it becomes:

Fiuh...I spent hours trying to fix this.

Hope this helps.

Tommy Segoro

Sharepoint Team Development with Visual Studio 2005 2008 Part 3

tommysegoro — Thu, 25 Sep 2008 02:31:00 GMT

This is the third and last part of Sharepoint Development using Visual Studio series. For previous part:
http://www.sharepointblogs.com/tommysegoro/archive/2008/09/04/sharepoint-team-development-with-visual-studio-part-2.aspx

Note: Just change the part-x bit to go to the other series of this posting.

INTRODUCTION

I've shared to you about the different Sharepoint project types, the development methodology approach and the tools. In this particular posting I will share to you on how to plan your Sharepoint development. I've talked a bit about this in my previous posting about how you should plan your content types and fields first. Sure, requirements change but at least you reduce your "headache" if you can get as much content types and fields done as possible. In this particular posting I will share to you on how I normally approach the site creation, the implementation of features, etc.

THE TOOLS

Once again I will repeat this over and over again: You HAVE TO utilise solution and features deployment for team development. Please find on my previous post regarding the tools I've used. Anyway, I will use my own solution template for creating solutions and features on my examples/projects. Please download from http://www.codeplex.com/vs2008sp.

SITE CREATION

Personally I will go down the custom site definition path. I will not modify OOTB site definition (eg. modifying STS's ONET.XML directly) because when you start modifying OOTB files, they may get overridden by service packs or patches that Microsoft releases. With custom site definition, too you can select what features to be activated upon creating a new site, what files to appear, etc which makes sense for me.

My fellow Sharepoint developer mentioned to me before that he prefers to use PowerShell to activate the features because he can see whether feature activation succeeds or not rather than you create your site first then getting an error message. If any of you uses PowerShell to create your site/activate your features, can you please share your experience? Anyway, I personally will go down the custom site definition path because it's easier for me to categorise which site will use what features, which site use what pages, what lists to instanstiate, etc. See example below of my custom ONET.XML:

<Feature ID="69CCBDEB-6B71-4fb6-9A2E-93EBB8D792D8" />

<Feature ID="67A06416-3D36-44c9-8980-F10FA0181B27" />

<Feature ID="6873B8E8-848D-461d-9494-9422E354AE6B" />

<Feature ID="5522E091-66EA-40e8-9C62-D08861A96225" />

<Feature ID="2F74B5BA-BDA9-435d-84DC-DF3CA1E741A2" />

<Feature ID="00BFEA71-4EA5-48D4-A4AD-7EA5C011ABE5" />

<Feature ID="F41CC668-37E5-4743-B4A8-74D1DB3FD8A4" />
 

<Feature ID="678C0C06-1053-455b-8767-867B6B37EA75" />
</WebFeatures>
</Configuration>

Therefore, when I need to create a particular site that will require particular features to be activated, I can easily go to Site Actions -> Create Site and create a site that uses my custom site definition and it will then have the correct activated features.

For creating custom site definition I always start from the OOTB ones. To create WSS-related site definitions, start from STS. For Collaboration Portal starts from SPS and for MOSS Publishing starts from BLANKINTERNET.

THE PROJECT

I personally will divide the project into 3 sub-projects:
- Features
- UI
- DLL

The Features project will contain feature-related stuff (except features that deploy UI such as master pages, CSS, page layouts and javascripts). So in this project you will have features that contain feature receivers, features that deploy web parts, features that deploy content types and columns, etc.

The UI project will contain UI-related stuff such as feature that deploys master pages and page layouts, feature that deploys images, CSS and javascripts.

The DLL project contains all code-behind related stuff (feature receivers, event receivers, custom fields, user controls, web-part code, etc). Why I divide the code into a separate project? It's because when you're deploying the DLL it won't affect the other elements (eg. Features and UI). The other elements will still run as normal yet you can deploy as many changes to your code as possible.

UI ELEMENTS

I will deploy CSS and images that are related to the UI directly on file system using feature. I will not upload images that are related to UI to Sharepoint image library. The reason is, when it comes to updating them, it's very-very easy and quick to re-deploy a new set of CSS, javascripts or images to a file system rather than uploading those files to Sharepoint.

For master pages and page layouts, I will also move away from using Sharepoint Designer and I will NOT un-ghost them. Updating them will be very easy and they can be source controlled using TFS/VSS if you're not using Sharepoint Designer to update them. When you want to update them, you can just re-deploy your UI project and it will upgrade all of your master pages and page layouts in the file system.

CUSTOM PAGES FOR DISPLAYING NON-SHAREPOINT INFORMATION

Let's say you need to display information from your MS CRM but in the context of Sharepoint (and inheriting the Sharepoint permission for viewing that page, etc), I will personally go down the custom page layout (or application page path). This way you can then code your page to use Sharepoint permission. In your Sharepoint custom page you can then have user controls that will display information from MS CRM.

Example: http://myintranet/Pages/ViewCustomer.aspx or http://myintranet/_layouts/ViewAdmin.aspx.

TESTING

Various testings can also be executed on a Sharepoint application (same as usual custom applications). With unit testing however, you will need to have Sharepoint installed on your machine because stuff like retrieving list item from a list, etc will require you to connect to a Sharepoint list. When I divide my projects into those 3 categories, I can easily test the DLL project without even deploying my UI and my Features (although I will need to have the actual list to be created on my Sharepoint site if I need to retrieve items from it).

DEVELOPMENT PROCESS

The development process can be the same per general custom application development. With those 3 sub-projects I have, I can check-in check-out files/features/user controls/master pages, etc and my fellow developers can then get latest and run Install/Upgrade and he will suddenly have the latest files on his Sharepoint site. That's the beauty of solution and feature deployment. It allows you to do team development.

BUILD and UAT PROCESS

The build and UAT process can also be the same as per general custom application development. I can use TFS (or other tool) to build my 3 sub-projects, deploy the features/solutions to the Test server then I can run Install/Upgrade script. The Sharepoint site on the Test server will then have the latest features and files installed.

CONCLUSION

So this will be the end of the team development series hope that you enjoy reading them and please share your experience. The team development process may take more time than just modifying things directly through the Sharepoint GUI but it's worth it. It will make your code maintenance a lot easier, it also allows you to perform code review (making sure that everyone is on the same page in terms of writing feature, code and solutions) and updating/upgrading your files will be a lot easier.

To download sample code please go to http://www.smallbusinesshosting.com.au/SampleProject.zip.

Cheers.

Sharepoint Timer Service Crashes Fix

tommysegoro — Thu, 25 Sep 2008 01:04:00 GMT

INTRODUCTION

I'm currently working at a client where they haven't got SP1 installed and the environment hasn't been setup correctly. Somehow this service crashes all the time.

THE WORK AROUND

The work around to this problem is for me to create a batch script which I then call through Windows Scheduled Task. I schedule the WST to run this script every 10 minutes.

The content of the script is very-very little:

net start "Windows Sharepoint Services Timer"

That's it! At least the timer service has been running stable because every time it crashes, it's automatically started by the script.

Hope this helps,
Tommy

MOSS BDC, Search and Web Service: Modifying Search Results Web-Part

tommysegoro — Fri, 19 Sep 2008 08:30:00 GMT

INTRODUCTION

This post is related to my other post regarding securing search results for currently-logged-in user in Sharepoint when querying BDC Web Service entity:
http://www.sharepointblogs.com/tommysegoro/archive/2008/09/17/moss-bdc-search-and-web-service-securing-the-search-results-for-particular-user.aspx

I'm now interested in how I can modify the search results web-part to display the actual entity name. OOTB it will give you EntityType.aspx. So if your entity type is called FileEntity the search results web-part will render FileEntity.aspx everywhere! I want to render Filename1.aspx, Filename2.aspx, etc.

OOTB:

THE SOLUTION

1. Add a meta-data property mapping in SSP. Let's give it a name: TommyFilename and add mapping to the BDC crawled property.

2. Edit the Search Core Results Web-Part -> Results Query Options -> Selected Columns. Add your custom managed-property in here.

3. Edit the Search Core Results Web-Part XSL under Data View Properties. Go to around line 111:

OOTB:
<span class="srch-Title">
   <a href="{$url}" id="{concat('CSR_',$id)}" title="{$url}">
    <xsl:choose>
     <xsl:when test="hithighlightedproperties/HHTitle[. != '']">
         <xsl:call-template name="HitHighlighting">
          <xsl:with-param name="hh" select="hithighlightedproperties/HHTitle" />
         </xsl:call-template>
     </xsl:when>
     <xsl:otherwise><xsl:value-of select="title"/></xsl:otherwise>
    </xsl:choose>
   </a>
    <br/>
   </span>

Modify that to:
<span class="srch-Title">
   <a href="{$url}" id="{concat('CSR_',$id)}" title="{$url}">
    <xsl:choose>
     <xsl:when test="tommyfilename[. != '']">
         <xsl:value-of select="tommyfilename"/>
     </xsl:when>
     <xsl:otherwise><xsl:value-of select="title"/></xsl:otherwise>
    </xsl:choose>
   </a>
    <br/>
   </span>

NOTE: The property name HAS TO BE LOWER CASE! Remember we named it TommyFilename before, didn't we? It won't work if you use TommyFilename but it will work if you use tommyfilename.

That's it! You can then see below:

APPENDIX

To check what XML it returns, edit that XSL Data-View Properties again and replace the content with:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<xsl:copy-of select="*"/>
</xsl:template>
</xsl:stylesheet>

Save the web-part then view HTML Source of the page then you can see something like below:

<All_Results>
<Result>
    <id>1</id>
    <tommyfilename>charlie_and_the_chocolate_factory_06.jpg</tommyfilename>
    <workid>5</workid>
    <rank>819</rank>
    <title>FileEntity.aspx</title>
    <author></author>
    <size>0</size>
...................

The custom property is actually recognized using ALL lower case naming convention. That is why TommyFilename will not work.

Hope this helps,
Tommy

MOSS BDC, Search and Web Service: Securing the Search Results for Particular User

tommysegoro — Wed, 17 Sep 2008 09:33:00 GMT

INTRODUCTION

MOSS BDC is an excellent offering from Microsoft. It allows you to pull data from external sources and bring the meta-data into MOSS which can then be indexed in Search. I have no problem in setting up User Profiles, OOTB MOSS Search, NTFS Search, etc but I'm very-very interested in setting up BDC with Web Service. MOSS has already had capability to securing search results on file system and Exchange public folder search but what about web service? What about if I want to search my custom CRM using PHP and I want to filter the security based on the user who performs the search? How do we do that?

In this post I will share with you what I've done. The example I posted is searching file system using web service but you can modify the code easily to accomodate your needs.

KNOWLEDGE LEVEL

This article is quiet advanced. You have to understand how BDC works (the use of Entity, Finder, etc).

THE STEPS

1. Define your Entity. Entity is an object which BDC can understand. BDC can't understand your PHP CRM but it can understand BDC Entity if you wrap your PHP CRM into an Entity. For example:

[Serializable]
public class FileEntity
{
public FileEntity(){} public FileEntity(string name, string filename, DateTime dateCreated, DateTime dateLastUpdated)
{
this.name = name;
this.filename = filename;
this.dateCreated = dateCreated;
this.dateLastUpdated = dateLastUpdated;
}

private string name;
private string filename;
private DateTime dateCreated;
private DateTime dateLastUpdated;

public string Name
{
get { return this.name; }
set { this.name = value; }
}

public string Filename
{
get { return this.filename; }
set { this.filename = value; }
}

public DateTime DateCreated
{
get { return this.dateCreated; }
set { this.dateCreated = value; }
}public DateTime DateLastUpdated
{
get { return this.dateLastUpdated; }
set { this.dateLastUpdated = value; }
}

}

Step 2. Use Microsoft's BDC Editor to create your BDC Definition .XML file.
I will not explain how to use the tool in this blog. Please read the documentation. I've supplied with an XML file resulting from that tool so you can modify yourself.

Step 3a. Define the methods for each finder in your web service.
Step 3b. Define your Finder.
Finder is the method that is used by Search to retrieve search results for your entity. There are some finders that are used:
- Finder: To retrieve ALL entities. Used by search results.
- SpecificFinder: To retrieve a particular entity. Used when you click on a search result and that link will bring you a specific Entity details.
- IdEnumerator: Enumerate the ID of each Entity. Each entity must be identified by an ID and this method will collect the IDs.
- AccessChecker: This is the method that is called by the search results whether an Entity can be accessed or not by a particular user. If user doesn't have access to a particular entity, that entity won't be displayed in the search results.

It will be clearer if you download the source code. Open the XML and the web service project then you will know how to assign web service method to a finder.

And this is how the AccessChecker is configured as web method:

[WebMethod]
public System.Int64 CheckAccess(string name, string username)
{
IMPLEMENT YOUR SECURITY CHECK HERE!

if (username.ToLower().Contains("sharepoint"))
return 0; --> RETURN 0 MEANS THE USER DOESN'T HAVE ACCESS

return 1; --> RETURN 1 MEANS THE USER HAS ACCESS

}

The username input variable will be populated by the current logged in user in Sharepoint.

In BDC XML please have a look below:

- <Method Name="CheckAccess"> -->> The Web service method name as above

- <FilterDescriptors>

<FilterDescriptor Name="fd" Type="UserContext" /> --->> Return current logged in user in Sharepoint

</FilterDescriptors>

- <Parameters>

- <Parameter Direction="In" Name="name">

</Parameter>

- <Parameter Name="username" Direction="In">

<TypeDescriptor Name="username" TypeName="System.String" AssociatedFilter="fd" /> -->> Pass logged in user to username variable of the method

</Parameter>

- <Parameter Name="out" Direction="Return">

</Parameter>

</Parameters>

- <MethodInstances>

</MethodInstances>

</Method>

</Methods>

Step 4. Create a crawl rule with the following settings:

- Path: bdc2//*
- Include all items in path, Crawl complex URLs

Step 5. Register security trimmer.

stsadm -o registersecuritytrimmer -ssp "MOSS SSP" -id 0 -typename "Microsoft.Office.Server.ApplicationRegistry.Search.QueryProcessorSecurityTrimmer, Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" -rulepath "bdc2://*"

Step 6. Configure MOSS Search and add BDC as your content source.

Any questions please let me know.

KNOWN ISSUE

The AccessChecker method will not be called if you perform search only from one content source (eg. only the web service). You need to run at least 2 content sources.

DOWNLOADS

Download the Microsoft BDC Editor here: http://www.microsoft.com/downloads/details.aspx?FamilyId=6D94E307-67D9-41AC-B2D6-0074D6286FA9&displaylang=en. Please note that you need to upgrade the SQLEXPRESS to SP2 before you install the tool to avoid Windows to keep asking you to update the SQL Express. You can't do this after you install the SQL Express. The update somehow failed all the time (happened to me using Windows Vista). Anyway, to do this:
- Download the BDC Editor then there is a folder where SQLEXPR.EXE is located.
- Download SQL EXpress with SP2 from http://www.microsoft.com/downloads/details.aspx?FamilyID=31711d5d-725c-4afa-9d65-e4465cdff1e7&DisplayLang=en
- Replace SQLEXPR.EXE in BDC installation folder with the one you just downloaded (has to be renamed to SQLEXPR.EXE).
- Install the tool. It will then use the updated SQLEXPR.EXE.

Download the web service and BDC project here: http://www.smallbusinesshosting.com.au/WebServiceTest.zip

The Test.XML is the BDC entity that you can upload to BDC. Please change to suit your needs.

SCREENSHOTS

Logged in as normal user, he cannot see the Entity in search results:

Logged in as Admin I can see the Entity

Sharepoint Solution Generator 2008 Problem

tommysegoro — Tue, 16 Sep 2008 02:20:00 GMT

So that I don't forget, the Sharepoint Solution Generator 2008 is a great tool to produce list definition Schema.xml. However, there is a bug!

I've just generated a list definition using it and then when I activate my feature and the Schema.xml of my custom document library is overridden with what SSG 2008 provided. But, I suddenly get this error for an existing document library(when I tried to upload/create new document):

The URL Library Name/File Name is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web.

This cannot be undone! My existing library breaks, no one can create/upload new document to that list.

So what's the bug? The bug is this:
When you generate a list definition using Sharepoint Solution Generator 2008, it adds ColName="nvarcharX" to your field definition in the Schema.xml. So my approach to SSG 2008 will be, once you've created your list definition, go to the <Fields> element then look for ColName="typeX" (eg. ColName="nvarchar11", ColName="varchar8", etc) and remove them ALL from every field in the Schema.xml.

For example:

Remove ColName="nvarchar11" from that line.

Otherwise, you'll get this error in your Sharepoint LOG:

09/16/2008 09:39:41.37 w3wp.exe (0x0950) 0x13BC Windows SharePoint Services Database 6f8g Unexpected Unexpected query execution failure, error code 8143. Additional error information from SQL Server is included below. "Parameter '@nvarchar11' was supplied multiple times."...........ERROR CONTINUES ON THIS LINE

Some of the bloggers suggest to fix the Schema.XML and then re-activate the feature using -force attribute. But this didn't work for me :( It's still returning with error. Therefore, I then had to get my Sharepoint content database backup and restore it then re-activate the feature using the correct Schema.XML at that point. Once you've activated your feature, the Schema.XML remains for every existing list on your site. That's why it then can't be undone.

Fiuh...lucky I haven't deployed my custom list definition to production..otherwise ALL document library that was created using this Schema.XML WILL BREAK!! ARGGHHH!!!

Hope this helps. If you find the same problem please share. Thanks,
Tommy Segoro

Sharepoint Solution Syntax Part 1

tommysegoro — Sun, 14 Sep 2008 14:07:00 GMT

INTRODUCTION

In my previous posts:
- Visual Studio 2008 Sharepoint Solution Template http://www.sharepointblogs.com/tommysegoro/archive/2008/09/12/visual-studio-2008-sharepoint-solution-template.aspx and
- Team Development using Visual Studio 2008 http://www.sharepointblogs.com/tommysegoro/archive/2008/09/08/sharepoint-team-development-with-visual-studio-part-2.aspx

I mentioned that the best practice for approaching Sharepoint development is to use feature and solution deployment. Several tools can be used such as STSDEV, Gerald De Run's solution template, my custom solution template, SP Template Land, etc. I keep emphasizing this point, it doesn't matter what tools you use as long as it can help you automating the creation of DDF, manifest.xml and CAB/WSP file and deploy them to Sharepoint.

I personally - a lot of the times - forget the "syntax" (the required files and folders) to create Sharepoint "modules" (eg. site definition, master pages, etc) using the solution template. It's just so hard to remember the various files and folders required by the solution template in order for your WSP/CAB can be deployed successfully into Sharepoint. In this post I will discuss about the "syntax" of creating Sharepoint "modules" using the solution template.

I will be using my solution template (can be found at http://www.codeplex.com/vs2008sp) but the syntax will be the same between tools anyway. Please look only at files/folders inside 12 folder.

SITE DEFINITION

To create site definition you will need the following structure:

WebTemp_StsClient.xml contains:
<?xml version="1.0" encoding="utf-8"?>


<Templates xmlns:ows="Microsoft SharePoint">
<Template Name="STSCLIENT" ID="80000">
<Configuration ID="0" Title="Test Client Publishing Site" RootWebOnly="TRUE" Hidden="FALSE" ImageUrl="/_layouts/images/stsprev.png" Description="A site for teams to quickly organize, author, and share information. It provides a document library, and lists for managing announcements, calendar items, tasks, and discussions." DisplayCategory="CompleteSharepoint.NET" > </Configuration>
<Configuration ID="1" Title="Test Client Publishing Sub-Site" SubWebOnly="TRUE" Hidden="FALSE" ImageUrl="/_layouts/images/blankprev.png" Description="A blank site for you to customize based on your requirements." DisplayCategory="CompleteSharepoint.NET" AllowGlobalFeatureAssociations="False" > </Configuration>
</Template>
</Templates>

STSCLIENT.XML contains:
<WebTempFile Location='1033\XML\WebTemp_CompleteSharepoint.xml'/>

and STSCLIENT is the actual site template folder. I personally will copy from OOTB site template such as INTERNETBLANK (for WCM), SPS (for collaboration portal) or STS (for WSS template) then modify to suit client needs.

MASTER PAGES and PAGE LAYOUTS

To create master pages and page layouts (for MOSS) use the following structure:

For WSS you don't have to have the Page Layouts folder and the definition within elements.xml.

Inside elements.xml:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

<Module Name="OSGPageLayouts" Url="_catalogs/masterpage/Client" Path="PageLayouts" RootWebOnly="TRUE">
<File Url="Homepage.aspx" Type="GhostableInLibrary">
<Property Name="Title" Value="Homepage Page Layout" />
<Property Name="ContentType" Value="Homepage Content Type" />
<Property Name="PublishingPreviewImage" Value="~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/WelcomeSplash.png, ~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/WelcomeSplash.png" />
<Property Name="PublishingAssociatedContentType" Value=";#Homepage Content Type;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900242457EFB8B24247815D688C526CD44D00EE006EDB325647a78556E4D79B73DE35;#"/>
</File>
<File Url="Content.aspx" Type="GhostableInLibrary">
<Property Name="Title" Value="Content Page Layout" />
<Property Name="ContentType" Value="Default Content Type" />
<Property Name="PublishingPreviewImage" Value="~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/WelcomeSplash.png, ~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/WelcomeSplash.png" />
<Property Name="PublishingAssociatedContentType" Value=";#Default Content Type;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900242457EFB8B24247815D688C526CD44D00EE006EDB325647a78556E4D79B73DE35;#"/>
</File>
</Module>

<Module Name="OSGMasterPages" Url="_catalogs/masterpage/Client" Path="MasterPages" RootWebOnly="TRUE">
<File Url="Client.master" Type="GhostableInLibrary">
<Property Name="ContentType" Value="Master Page" />
<Property Name="PublishingPreviewImage" Value="~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/BlueBand.png, ~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/BlueBand.png" />
<Property Name="MasterPageDescription" Value="This is minimal XHTML compliant master page." />
</File>
</Module>
</Elements>

Inside Feature.xml:


<Feature Id="5522E091-66EA-40e8-9C62-D08861A96225" Title="Client Layouts" Description="" Version="1.0.0.0" Scope="Web" Hidden="False" Creator="Client" DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="elements.xml"/>
</ElementManifests>
</Feature>

CONTENT TYPES and FIELDS

To create content types and fields you need the following structure:

The ContentTypeBinding project will bind your content types to Pages list (for MOSS). For WSS you can also bind content types to your custom list if you wish but you have to set your custom list to "Allow management of content types" in list settings.

Inside ContentTypeBinding.xml:


<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<ContentTypeBinding
ContentTypeId="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900242457EFB8B24247815D688C526CD44D0012A91988173542fe998D57BF4EE8E93B"
ListUrl="Pages"
/>
</Elements>

Inside Feature.xml:


<Feature Id="1250896B-6DD5-4080-81C3-3425ECEE2125" Title="Test Client Content Type Binding" Description="Adds Custom Content Types to the Pages Library" Version="1.0.0.0" Scope="Web" Hidden="FALSE" Creator="TestSharepointSolutionTemplate.ContentTypes" xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="ContentTypeBinding.xml"/>
</ElementManifests>
</Feature>

Inside Content Types feature you have ContentTypes.xml, Fields.xml and Feature.xml.

Inside ContentTypes.xml:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<ContentType ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900242457EFB8B24247815D688C526CD44D0012A91988173542fe998D57BF4EE8E93B"
Name="Test Client Default Content Type"
Group="Test Client Content Types"
Description="Default content type."
Version="0">
<FieldRefs>
<FieldRef ID="{3C71331B-83B9-471b-81EC-2BE0C169861C}" Name="CustomContent" DisplayName="Custom Content" Required="FALSE"/>
</FieldRefs>
</ContentType>
</Elements>

Inside Fields.xml:


<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Field ID="{3C71331B-83B9-471b-81EC-2BE0C169861C}"
Name="CustomContent"
DisplayName="Custom Content"
StaticName="CustomContent"
Group="Test Client Columns"
Type="HTML"
Sealed="FALSE"
SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"
Description="Default custom content."
AllowDeletion="True" />
</Elements>

Inside Feature.xml:


<Feature Id="95276CFE-2DDA-4322-958C-DF1B77731067" Title="Test Client Content Types" Description="" Version="1.0.0.0" Scope="Site" Hidden="True" DefaultResourceFile="core" Creator="TestSharepointSolutionTemplate.ContentTypes" xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="Fields.xml"/>
<ElementManifest Location="ContentTypes.xml"/>
</ElementManifests>
</Feature>

To be continued...

Visual Studio 2008 Sharepoint Solution Template

tommysegoro — Fri, 12 Sep 2008 04:56:00 GMT

INTRODUCTION

In relation to my Team Development posts,
http://www.sharepointblogs.com/tommysegoro/archive/2008/09/08/sharepoint-team-development-with-visual-studio-part-2.aspx

I will now provide the Visual Studio 2008 Sharepoint Solution Template that I'm using. Please refer to the post above regarding the tools I've used before: STSDEV and Gerald De Run's solution template.

My solution template is a combination of both. It's utilizing Gerald De Run's VBS scripts to create manifest, DDF and CAB but also utilizing STSDEV's Visual Studio custom build commands for running Install, Upgrade and Uninstall.

Once again, every tool has its own advantages and disadvantages so please use it if you like it. This solution template has been my comfort zone thus far.

TO DOWNLOAD GO TO: http://www.codeplex.com/vs2008sp

or alternatively,

http://www.smallbusinesshosting.com.au/SharepointSolutionTemplate.zip.

=================================================

Don't forget to change these required parameters:
- Feature ID of every feature you create
- GUID for every content type and field
- Solution ID inside CreateManifest.vbs
- Upgrade.cmd, Install.cmd, Uninstall.cmd

Every modification to the Microsoft.Sharepoint.targets (ie. the build target) will require you to close your solution and open again to refresh the changes. Therefore if you make any changes to the targets file, don't forget to close and re-open your solution.

=================================================

HOW TO USE

1. Unzip the file and you will see 3 folders: EmptyProject, FullSet, SolutionGenerator.

2. EmptyProject and FullSet are the solution template and the SolutionGenerator is an executable project that will then copy the selected template (eg. EmptyProject or FullSet) to your designated folder.

3. Open SolutionGenerator and open the Visual Studio solution. Edit App.Config to suit your needs:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ClientName" value="TestSharepointSolutionTemplate"/>
<add key="ProjectDestination" value="D:Documents\Visual Studio 2008\Projects\MyClient\Dev\Source"/>
<add key="ProjectTemplateSource" value="G:\Documents\Visual Studio 2008\Projects\SharepointSolutionTemplate\EmptyProject"/>
</appSettings>
</configuration>

The solution template is using TestClient everywhere (in the project and solution filename, etc) and ClientName key above will replace TestClient with whatever you specify. ProjectDestination key is the destination folder for your client project and the ProjectTemplateSource is the solution template folder. You can only use EmptyProject or FullSet at the moment because they're what I've provided to you in the ZIP file. If you want to create your own, you can create a new solution template based on the EmptyProject. Just copy and paste the EmptyProject folder, rename it to something else and modify the Visual Studio solution project within it. Rename the .csproj and .suo file. You can then add this project to your empty solution if you wish. Very easy!

The FullSet is also based on EmptyProject but I've modified it and added some extra folders, features, etc.

THE EMPTY PROJECT

This is the base of the solution template. If you open the project, you will see below:

12 -> Is where you put all your features, etc into. This will mimic the 12 hive.

Scripts -> There are 3 files and as the name of each file implies, they will perform Install, Uninstall and Upgrade solution respectively. These scripts will also be run by the custom build commands (look at the smaller image).

CreateCabDDF.vbs -> The VBS script that creates the DDF file. If you don't like the way it spits out the DDF file, you can modify the code straight away in this file. It's a VB code which everyone should be able to modify easily.

CreateManifest.vbs -> The VBS script that creates the manifests.xml file. If you don't like the way it spits out the manifest.xml file, you can modify the code straight away in this file. It's a VB code which everyone should be able to modify easily.

Microsoft.Sharepoint.targets -> This file contains the custom build configuration (same concept as STSDEV). If you look at the file there are actually 4 custom build commands: CreateSolution, InstallSolution, UpgradeSolution, UninstallSolution.

CreateSolution will run CreateCABDDF.vbs, CreateManifest.vbs and some other code that will create the DDF, Manifest.XML and the CAB file for you.
InstallSolution will run CreateSolution but also run Install.cmd.
UpgradeSolution will run CreateSolution but also run Upgrade.cmd.
UninstallSolution will run CreateSolution but also run Uninstall.cmd.

The build commands in Microsoft.Sharepoint.targets is pretty straight forward (same as if you're building post-build event). So I won't discuss that any further.

FULL SET PROJECT

In this solution you will see 3 Visual Studio projects by default:

The Features, UI and Web projects:
- Features project is where you put all your custom features in except features that deploy master pages and page layouts.
- UI project consists of files that are normally related to UI such as site definition, site template, master pages, page layouts, images and CSS.
- Web project is supposed to contain all DLL and code-behind related files. For example, if you have a feature receiver, you may declare your feature in the Feature project but the code behind may be added to the Web project. It's just a way of organising your code. The reason is, Features and UI projects will be deployed globally in Sharepoint and normally, only feature that contains DLL that will be deployed in GAC or to a particular Sharepoint application. Sharepoint will return an error message if you try to deploy DLL globally that is supposed to live in IIS BIN directory. It will say "This feature contains web-related resources" or some sort.

CONCLUSION

So that's pretty much it! Once again, it's not important what tool you use as long as it helps you building the solution/CAB/WSP file and deploy them to Sharepoint automatically. Once again, this is the only way to approach team development. Please refer to my posts.

Sharepoint Team Development with Visual Studio 2005 2008 Part 2

tommysegoro — Mon, 08 Sep 2008 00:28:00 GMT

This is the second part of Sharepoint Development using Visual Studio series. For previous part:
http://www.sharepointblogs.com/tommysegoro/archive/2008/09/04/sharepoint-team-development-with-visual-studio-part-1.aspx

INTRODUCTION

I've shared to you about the type of projects and the development methodology approach on my previous post. I really-really thank everyone who has contributed and spending their time writing comment on my previous post. Thank you for your sharing!

This second part I will talk about planning the development. Once again this is all based on my previous experience only so any comments/sharing from you will be much much appreciated! I always believe that there is sky above sky and I always believe that there is no one who can do everything...some people are good at one thing and another people good at other things. So please write comments, please share, please disagree or agree with me. Thank you very much.

THE REQUIREMENTS GATHERING

This is what I found as the biggest part of the development process: the planning. In my experience the planning will decide how your development process is going to be. It can be easy or it can be nightmare. The first planning we have to do before start developing on Sharepoint is to GET THE CONTENT TYPES AND FIELDS RIGHT. I always do this as my first step. The reason is, as someone pointed in my post regarding updating content types and fields, Microsoft only supports limited method of updating fields. Please read it here.

I've ever developed a MOSS website for a government body that has more than 20 content types and more than 100 custom fields! And yes...we didn't get them right in the first place and the manager pushed us (the poor developers) to make the system available in UAT so that client can START INPUTTING CONTENT!. This is WRONG WRONG WRONG....at the end of the day, we wasted so much time updating the fields because we didn't get them right in the first time. We ended up changing some fields from Text to HTML because they need more than 255 characters of content in that particular field, etc. It was pretty bad....

In a modern development methodology, Agile development allows you to not have the full set of requirements in the first place. Change requests are allowed and can be handled very well with this methodology. However, with content types and fields, for me personally (at least from my experience), they have to be done right in the first place. Additional fields are OK because when you de-activate/re-activate feature, they will be added successfully. But changing field types, etc will be very hard for existing fields.

The other part of Sharepoint (custom controls, master pages, site definitions, event receiver, feature receiver, workflows, etc) can be updated quiet easily using feature/solution deployment. So with these, you can apply Agile methodology (ie. You don't have to get the design right in the first time for you to be able to write custom controls, do you?).

THE PROCESS

1. You should define your content types and fields first
2. You should NEVER get users/clients to put live content before the fields and content types are done correctly. This should be done after the content types and fields are finalised. This will just screw your project plan because as I've mentioned earlier, modifying existing content types and fields are just so hard and we don't want to re-flush the site (ie. delete/re-create site collection) and re-activates the new fields and content types and lose the live content thas has been put in the test site, do we?
3. Other Sharepoint elements (master pages, page layouts, DLLs, etc) can be developed ad-hoc. You don't need to get them right on the first time. They can always be upgraded with solution/features easily.

THE TOOLS

As I mention earlier in my first post, we HAVE TO USE feature and solutions deployment and thanks to everyone who contributed about the workflow deployment. Yes, it's the best practice to deploy everything (including workflows) using feature and solution deployment. Therefore, we will need a tool that enables us to do this especially for doing it from Visual Studio.

The tools that I mention in this blog are once again based on my experience only! Of course you must have other methodologies for creating features and solutions automatically. The tools I will be using are (including their advantages and disadvantages which are also only my opinions, you can disagree/agree with me):

STSDEV

Advantages
- Built-in Visual Studio build commands. You can run install, deploy, upgrade, delete, etc from Visual Studio directly. Just build your project and it will do the job for you. You don't need to open command prompts and remembering the lines!
- Auto-creation of manifest.xml and DDF files and auto-creation of CAB/WSP file which is great.
- If you remove files/folders from RootFiles, they will be reflected straight away in manifest.xml, DDF and WSP.

Disadvantages
- You have to use the project type selector for creating a particular project. I tried to use the Blank Solution without DLL (C#) project before for creating features and guess what...somehow the files within the feature (except feature.xml and elements.xml) are not deployed! They're in the CAB and WSP but they're just not deployed to the FEATURE directory. Maybe I didn't do it right but anyway...one thing that I'm hoping STSDEV can be improved is it should be generic for ALL type of Sharepoint projects (regardless it's web part, feature, etc). The project selector will only create a set of files/folders inside RootFiles for a particular project so user will not forget. For example, if I select the Web-Part project, the project selector should create folders and files required to deploy a web-part. It should not fail if the web-part project is used to create features.
- Inclusion of DLLs are manual. If you add a reference to another project that will add a referenced DLL, you have to specify it in SolutionConfig.xml manually.
- It creates one Visual Studio solution per project. Additional configuration will be required for you to be able to aggregate STSDEV projects into one solution.
- You cannot control the creation of the DDF file. At the moment I found a problem where you can't set the .Set MaxDiskFile property of the DDF which will allow the CAB file to be bigger than 1424KB. Therefore, if you have so many files in your CAB file and it exceeds 1424KB, they will be truncated. The work around for this is to let STSDEV build the DDF, you set the MaxDiskFile property manually then you build the CAB manually and not using STSDEV.

GERALD DE RUN (Microsoft consultant)'s SOLUTION TEMPLATE

I've met him before in my previous workplace and he introduced to us his solution template. Please read his blog here. His solution template is utilising POST BUILD event to create manifest.xml, DDF and WSP.

Advantages
- The template is generic for everything (web part, features, etc) and the files will be deployed successfully in FEATURE folder.
- Has built-in Install.cmd, Upgrade.cmd and Uninstall.cmd.
- Can aggregate many projects into one solution.
- A switch in post-build event will allow you to add all referenced DLLs to the deployment project (hence in WSP) automatically.

Disadvantages
- No Visual Studio built-in commands. So you have to open command prompt and run the script
- Since it's using 2 projects, one is the deployment project and one is development project, the way it works is, it will copy the files from development project to the deployment project using post-build events then in the deployment project, there is another set of post-build events and scripts that will then create manifest.xml, DDF and WSP. With this configuration, the files are not automatically deleted from the deployment project. If you remove files/folders from the development project, the removal from deployment project is manual. So you have to create a custom tool (which I have done) that will allow you to delete files/folders from deployment project hence removing them from the WSP.

I personally go down Gerald De Run's path and modify his solution template to be Tommy Segoro's solution template that has some fixes to some of its limitations. There is no reason at all for me for not using STSDEV. Why I use Gerald's solution template, because I knew about it before STSDEV (hence comfort zone).

My point is, it's not important about what tools you're using as long as creation of manifest.xml, DDF and WSPs are automated. If you've used STSDEV please continue using it. It's an excellent product! If you're still interested with my modified-Gerald-De-Run's solution template, please go to http://www.sharepointblogs.com/tommysegoro/archive/2008/09/12/visual-studio-2008-sharepoint-solution-template.aspx.

CONCLUSION

So there you go....remember, get the content types and fields right first before you get into trouble.