Dot Net Mafia

Sharing an Index between SharePoint Farms

CoreyRoth — Thu, 04 Dec 2008 16:44:45 GMT

I've seen a few posts in the forums lately on this, so I thought I would post how I have implemented it in the past. The issue is you have multiple SharePoint farms, but you want one index server to handle both of them. This is actually pretty easy to setup, if you don't mind your farms sharing the same Shared Services Provider (SSP). The process below describes how to share the services of one farm's SSP to other farms.

The first thing you need to do is decide which farm will host your index server and the configure it as normal. We'll refer to this as the parent farm. On the parent farm, go to Central Administration -> Application Management -> Managed Shared Services between Farms. Click on the option "This farm will provide shared services to other farms". You will then be prompted for which SSP to use. Most likely you only have one. If you have more than one, click the one that has your search index on it. You will then need to specify a user account. This account should have permissions on the child farm already. Typically, I would use the account that is being used for the application pool in central administration. Click ok and then you should see a screen giving you information on how to configure a child farm. Specifically it will give you the name of the parent farm's database server and configuration database.

Now you will want to go to your child farm. Go to the same page to manage shared services between farms, but this time click on "This farm will consume shared services from another farm". Enter the database server and name in the fields provided. I recommend using Windows authentication but keep in mind that account will need permission to access that configuration database. This shouldn't be an issue if both farms are using the same accounts for central administration though. The last option to specify is for Local Excel Services (which can not be shared across farms). For that you will have to specify an SSP that is local to that child farm.

It may not be entirely obvious what to do on the next screen at first. The goal is to associate any web applications you have created on the child farm to your new parent SSP. So the first thing you need to do is select the SSP of your parent from the list. It will have the word parent next to it in parenthesis. You then need to check the box next to any web application you have created and click ok. Your services from the parent SSP have now been shared to the child. This means any use of the Business Data Catalog, Enterprise Search, User Profile Application, or Session State will now be configured on the parent farm. If you want to add additional child farms, just repeat these steps on each farm.

At this point you can execute a search query on a web application on either farm and get the same results. However, you still need to configure a content source to crawl the child farm. You will need to go the Content Sources page of your Search Administration on the parent SSP. To index the child farm, you can do this in one of two ways. First, you can simply modify the existing Local Office SharePoint Server Sites content source and add the URL of your web application of the child farm into the list of start URLs. You can also create a new content source and specify the URL of the child farm there. I tend to approve the latter approach since I can put the crawls on different schedules that way. Either way you go, perform a full crawl when you are done. Once the crawl is complete, you will now be able to search for results on both farms from either farm.

Slides and Code Samples from my talk at the OKC Developer Group

CoreyRoth — Tue, 02 Dec 2008 16:31:00 GMT

Yesterday, I had the privilege to speak at the Oklahoma City Developer Group about SharePoint Development for ASP.NET Developers. This talk was aimed at showing developers familiar with ASP.NET how they can get started with SharePoint. In my talk I mentioned a number of posts from my blog, so I wanted to link them here.

In my talk I know I referenced my blog a lot, but when starting out with SharePoint development, there really is too much to cover in just a short one hour talk. Hopefully, these posts will be a good starting point for anyone that wants to get started with SharePoint. My slides and code samples from the talk are attached. Feel free to leave a comment or shoot me an E-mail if you have any questions. I want to thank the OKC Developer Group once again for having me.

Joining the Herd - Isolator for SharePoint

CoreyRoth — Tue, 25 Nov 2008 22:00:25 GMT

I thought I would join the herd and help spread the word about Isolator for SharePoint. It's pretty exciting that there is actually a chance of doing TDD with SharePoint. I look forward to trying it out.

Typemock are offering their new product for unit testing SharePoint called Isolator For SharePoint, for a special introduction price. it is the only tool that allows you to unit test SharePoint without a SharePoint server. To learn moreclick here.

The first 50 bloggers who blog this text in their blog and tell us about it, will get a Full Isolator license, Free. for rules and info click here.

Ingenious idea of how to spread the word guys. I like it.

How to: Get the Item Id from a document URL

CoreyRoth — Mon, 24 Nov 2008 21:16:29 GMT

Since I deal with Enterprise Search a lot, I often want to do things in SharePoint given nothing but a URL. Unfortunately, there isn't an API call (that I know that can take a URL can conveniently spit out an Item Id). You can probably use a CAML query, but you would have to know which site collection to start with. So how do we get the id? It takes a number of steps, but it is pretty simple. We first start by opening an SPSite object given the full URL to the item.

using (SPSite siteCollection = new SPSite(url))
{
    using (SPWeb site = siteCollection.OpenWeb())

This assumes that the code is executing somewhere where opening an SPSite object for that URL is valid. After that we open a SPWeb object which gives us an object representing the site that contains the document. Next it is a matter of splitting the URL to get a file and folder URL.

// site url
string siteUrl = site.Url;
 
// get the position of the last slash so that the string can be split
int lastSlashPosition = url.LastIndexOf('/');
 
// folder url
string folderUrl = url.Substring(0, lastSlashPosition);
 
// fileUrl
string fileUrl = url.Substring(lastSlashPosition + 1);

We do this by using LastIndexOf('/) (which of course assumes that the URL contains slashes). At this point it is easy to get a reference to the file object representing the document.

// get file object
SPFile file = folder.Files[fileUrl];

This gives us a reference to the file which means we can get a reference to the item and then its Id. Conversely if you are interested in the SPFolder object, you can just use.

// get folder object
SPFolder folder = site.GetFolder(folderUrl);

We will now get the SPListItem object which will give us its Id.

// get the list item
SPListItem item = file.Item;
 
// get the list item id
int itemId = item.ID;
 
// get the uniqueId for the list item
Guid uniqueId = item.UniqueId;

Above, I have code to return the internal list item id as well as the unique id. There are a few steps involved, but it seems to work pretty well. You will of course want to add proper error handling and check for nulls along the way, but this should be a good start. This is the same way I get the information I need for the Document Link Handler for Enterprise Search.

Speaking at Oklahoma City Developer's Group on December 1st

CoreyRoth — Thu, 20 Nov 2008 15:02:44 GMT

I am excited to announce that I am speaking at the Oklahoma City Developer's Group on December 1st. I am giving a new talk geared at helping ASP.NET developers take the leap into SharePoint development. This talk will closely tie into my recent Introduction to SharePoint Development (web part, user control) series of posts. This talk will show developers what they need to get started and how to tackle deployment. We'll also cover the basics of working with the SharePoint API. The OKC group has a lunch meeting and an evening meeting. I look forward to seeing everyone there.

Remote Debugging an InfoPath Form in Forms Services

CoreyRoth — Tue, 18 Nov 2008 22:16:16 GMT

Let's face it, not every InfoPath form you write is going to work right on the first time. If you are dealing with a Full Trust InfoPath from deployed in Forms Services at some point you may need to debug it. In my server in question today, it did not have InfoPath nor Visual Studio installed. However, it did have the Visual Studio Remote Debugging Monitor installed, so I decided to give it a shot.

Remote Debugging an InfoPath form is not much different that remote debugging anything else in SharePoint. You run the Visual Studio Remote Debugging Monitor on the remote server and use Visual Studio to attach to the w3wp process on the remote server. There are a couple of catches though. First, if you are running VSTA from InfoPath the first thing you will notice is that there is no Attach to Process menu item in the Debug menu. I am sure there is a way to get around it, but I just decided to close VSTA, open up Visual Studio 2005 (you have to use VS2005 since it is a .NET 2.0 project - although you may be able to upgrade it), and opened the .csproj file for the InfoPath project.

Opening the project with Visual Studio 2005 gives us the Attach to Process menu item. InfoPath code behinds don't generate PDB files by default. So, you will need to go into the project properties, Build tab, and select Debug. You then need to click on Advanced and set the Debug Info to Full. Build the project and you will have your PDB file. Now you need to copy the DLL and the PDB file to the SharePoint server. I have been copying these files into the feature folder of the workflow (i.e.: TEMPLATE\FEATURES\MyWorkflow). I have no idea if this is the correct way to deploy Fully Trusted forms, but I have yet to find any documentation on how to do it and I know this works.

Once you have done that you are ready to attach to the w3wp process. Don't forget you can use iisapp.vbs to determine the correct w3wp process to attach to. Set a breakpoint in your InfoPath code behind and then execute your InfoPath form or workflow. If all goes well, your breakpoint will be hit. If it doesn't get hit, make sure you attached to the right w3wp and make sure that the DLL and PDB on your local computer match what is on the server.

One thing to note is when you start deploying subsequent updates, the DLL for your form will become locked and you won't be able to deploy a new one. Be aware of that if deploying via solution package as it won't give you an error and it will just fail to copy things. Once you are done debugging, you will need to terminate the current w3wp process to release the lock and update your DLL. Also if you are just updating the code and not the form, it is ok to just copy the DLL and PDB out and not reinstall the feature and reattach the workflow. That should save you some time.

Introduction to SharePoint Development: Deploy a User Control in SharePoint

CoreyRoth — Tue, 18 Nov 2008 20:07:58 GMT

A common question I get with new SharePoint developers is "How do I deploy my user control in SharePoint?". Many times they know of the SmartPart or even how to make their own, but its the matter of deploying things that may not be clear. Before starting this, you need to read how to build and deploy a web part. Many of the concepts in that article are used here and explained in more detail.

To build a user control, you start in very much the same way as you do with regular ASP.NET. My recommendation is to start by creating a web application project. You can also use a regular class library, but its easier if you use a web application project since it has the file types you need as well as references. If you already have a class library, you can easily convert it to a web application project using a hack.

Once you have a web application project, create your user control as normal. Build the project and then its time to deploy. We'll first talk about where the files go on the server and then we'll look at how we can get the files there with a solution package. Let's assume, I have a control called MyControl.ascx. This file has to be deployed to the SharePoint server along with its binary. If you are using a SmartPart, the ascx file to go is in a folder called UserControls located in the root of your web sites folder (by default c:\inetpub\wwwroot\wss\VirtualDirectories\80). However with true SharePoint development you have to break the my controls go in X folder on my site way of thinking. In SharePoint, everything is designed to be modular no matter how many web applications your server hosts.

I recommend creating your own web part to host your user control that will work with any folder. SharePoint itself puts all user controls in the CONTROLTEMPLATES folder in the 12 hive (C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12). You can place your controls here as well, but I recommend creating a subfolder here to keep your controls separate. In this case, I will create a folder called MyControls and copy MyControl.ascx into it. At this point you are probably wondering what is the path to my control if its in the 12 hive? On any SharePoint web application, there is a virtual directory called _controltemplates. This happens to map to the folder we need. Therefore, the path you would reference in your web part (or any web page) would be ~/_controltemplates/MyControls/MyControl.ascx.

Now, it is just a matter of deploying the binary. In traditional ASP.NET, you could just copy the DLL of your web application project to the bin folder of the web application. However, with SharePoint we can't do that without specifying Code Access Security which is a pretty big undertaking when you are starting out. For any file that is in the bin folder, SharePoint requires a security policy be set specifying exactly what permissions your DLL has. I recommend deploying to the bin folder, but if you are just starting out, you don't want to go there yet. To get around this for now, there are two options: 1) Change the TrustLevel in the web.config to Full or 2) Deploy the DLL to the Global Assembly Cache. I strongly recommend against #1, so for the sake of starting out, just copy your DLL to the GAC. You will need to strongly name your assembly. Any time you copy the DLL to the GAC, you will need to either recycle the application pool that your web application is using or reset IIS. I know that can be a pain, but once you implement CAS, you don't have to do that any more.

Just like with a web part, you have to add your user control as a safe control. Just specify the assembly name and allowed namespaces.

</SafeControls>

At this point you are ready to try your new user control out. To add it to a page like a web part, I recommend you follow the steps in this post to make your own SmartPart. If you don't know how to deploy a web part, follow my post on how to deploy a web part. Once you have your smart part added, specify the path I mentioned above (~/_controltemplates/MyControls/MyControl.ascx). You can also add user controls to your master pages, just like you would in ASP.NET. Just create the reference and add it to the .master.

This may sound like a lot at this point but it's really not bad. If there is enough interest in the article, I will try and get some code together in one package so people can use it as a starting point. That is how you manually deploy a user control, we'll move onto how we do it with a solution package.

Deploying via Solution Package

For deployment, we will pretty much follow what we did in the deployment of the web part. For more details on building solution packages, please see that post. In this case a feature is not necessary unless you want to automate the deployment of the user controls onto an existing page. The cab.ddf file only contains lines to copy the binary and .ascx file.

; ** MyControls.wsp  **
.OPTION EXPLICIT     ; Generate errors 
.Set CabinetNameTemplate=MyControls.wsp     
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP;** All files are compressed in cabinet files
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=Package

Solution\manifest.xml manifest.xml

;binaries
bin\MyControls.dll MyControls.dll

;feature files

;template files
MyControl.ascx CONTROLTEMPLATES\MyControls\MyControl.ascx

The Manfiest.xml file will contain entries to copy your ascx file out as well as copy your binary to the GAC. It will also add the Safe Control entry that you need. Here is what the file would look like. The TemplateFile element is used to specify every .ascx file that you want copied to the server. More details on what you can do with the manifest file are here.

<Solution SolutionId="{FA34A0BE-FEAA-4750-9E82-B313F62C5CF9}"  xmlns="http://schemas.microsoft.com/sharepoint/" ResetWebServer="true">
  <TemplateFiles>
    <TemplateFile Location="CONTROLTEMPLATES\MyControls\MyControl.ascx" />

  </TemplateFiles>
  <Assemblies>
    <Assembly DeploymentTarget="GlobalAssemblyCache" Location="MyControls.dll">
      <SafeControls>
        <SafeControl Assembly="MyControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=03afd371f1d50a3a" Namespace="MyControls" TypeName="*" Safe="True" />
      </SafeControls>
    </Assembly>
  </Assemblies>

</Solution>

At this point, you build and deploy the .wsp file as described in my web part post. Again, I strongly recommend reading that post if you are not familiar with any of the deployment steps yet. The nice thing about having your user control in a solution package is that it is now completely portable. It can be deployed to your other SharePoint servers very easily. Once you have mastered the process, I recommend you start deploying your binaries to the bin folder with Code Access Security. Once you have the solution package built, adding CAS is pretty easy and it saves you from having to kill your app pool every time you do a deployment.

An Open Letter to Microsoft on Enterprise Search

CoreyRoth — Tue, 11 Nov 2008 19:32:57 GMT

The Enterprise Search component of MOSS 2007 and Search Server are great products and they can do a lot of great things out of the box, however I repeatedly see the same requests from clients. I also see people having the same issues in the forums all the time. I would like to summarize a list of things, we as a community, would like to see addressed in the future. With the acquisition of Fast, a lot of these could become non-issues, but in the meantime this is what people are experiencing now. Please add your comments or let me know anything you think I missed.

Wildcard Searching - Yes, Enterprise Search supports it but not out of the box. WildcardSearchWebPart helps, but it's just a hack and this functionality should be built in. It doesn't help with People Search though.
Unseal classes in Microsoft.Office.Server.Search.Web - We are given limited functionality in displaying search results out of the box, help us out by not making these classes sealed so that we can add our own functionality. You did this with the Federated Search classes and it was a step in the right direction.
Provide links to document libraries, sites, and editing of results containing documents. The Document Link Handler helps with this.
Provide zip and download support - LiveLink has a lot of these types of options and users want them.
Allow custom sorting using managed properties in the CoreResultsWebPart.
Include faceted search out of the box.
Add keyword specific features to Full Text SQL Queries - It turns out people want wildcard searching and a variety of other features that word only when performing a keyword search. Things like Best Bets, RSS, Keyword Highlighting, and Search Summary do not work when using Full Text SQL.
Display more accurate result counts - I know this is the nature of a way a search engine works. In the case where I am using the BDC to index a table full of widgets, the end user always knows exactly how many widgets there are and he or she starts to ask questions.
Fix the page where you map crawled properties - It is not resizable and you can't see what you are picking when the crawled property has a long name. It would also be nice if you could select more than one at a time.
Stop using WSS Search in MOSS - You can work around this, but there should be no reason why a call is made to OSSSearchResults.aspx on a MOSS server. The WSS search page offers next to 0 customization options.
Provide a way to see which IFilters you have installed.
Provide and stsadm command to import/export Content Sources, Managed Properties, Crawled Properties, and Scopes. Thank you SSSPPC for helping with that right now.

Ok, I know I am asking a lot, but just take a look at the forums, these are real issues people deal with every day. I still enjoy working with the product every day and am so thankful that the community has given so much to make it better. I am very excited what the next version of search will have in store for us. However, these are things that should be addressed in one way or another lest companies start going out and buying Google Search Appliances. If you have anything you would like to add, please leave a comment. Thanks.

A Note on Content Type Inheritance

CoreyRoth — Tue, 04 Nov 2008 17:15:47 GMT

I ran into this issue a while back so I thought I would post on it. I had a scenario where we wanted to create a simple content type to use as a base content type for all future content types at a comapany (i.e.: Company Base Document). At the time we did not know what site columns we wanted included, so we didn't include any FieldRefs to site columns. We just inherited from this type into another more project specific document type. It seemed like a good idea at the time, but it of course caused a number of problems.

It appears that if you do not specify any FieldRef elements in your content type definition that any other fields further up in the inheritance tree will also not get inherited. This caused things like the Title field (inherited from item) to not be included in our content type. The lesson to be learned here is a) plan better and have your fields defined first and b) make sure that you always specify at least one FieldRef in your content type definition. I am sure there is a technical reason for this, but I thought I would throw it out there in case someone else runs into the issue in the future.

Also if you haven't checked out my latest addon for Enterprise Search, go check it out. I am pretty excited about it and the users I have shown it to so far have found a lot of value in it.

Introducing Document Link Handler for MOSS 2007 Enterprise Search

CoreyRoth — Fri, 31 Oct 2008 18:30:17 GMT

Since, I have started working with Enterprise Search, I have received many requests looking for ways to improve what we can do with documents. The search results screen in MOSS, as flexible as it is, has always been lacking in features compared to search results of other ECM systems. Common feature requests I have seen from clients include: editing the document, viewing properties, linking to the folder or document library, linking to the site the document is in, zip and download, view version history, and more. Today I am pleased to announce a simple solution which can handle many (but not all) of these common requests.

So how do we accomplish this? I decided to build a simple ASP.NET Handler (.ashx) file to parse the URL from a document on the search results page and redirect a user to the page that he or she wanted. Links to the handler can easily be added by modifying the XSL of the CoreResultsWebPart.

The code of the handler is pretty simple. I take the URL passed via query string, split it to get the filename and the path and then I open an SPWeb object that references that site. Once I have access to an SPFolder and SPFile object for the document, I can determine URLs for the document library and folder. Take a look at the code if you are interested. It might need some optimization, but it is a good starting point.

Installation is simple. Install the included .wsp file contained in the package folder. The syntax is listed in the readme.txt file if you need it. This will copy the DocumentLink.ashx file into your layouts folder. To add the links to your search results, go to the results page of your search center and edit your CoreResultsWebPart. In the Data View Properties, click on the XSL Editor button. Replace the XSL in the window with the contents of the included SampleCoreResults.xslt file. If you have already made customizations to this file or you only want certain links, you may copy just the lines you need from the readme.txt file.

After you have changed the XSLT, apply the changes and execute a search query. If you receive an error, then your XSL is probably malformed. Open the XSL with Visual Studio if necessary to help find the error. If all goes well, you should have search results that look like the one below. Note, that these links will only show up for search results that are documents (IsDocument:1). This works together in conjunction with my post earlier this week on adding an edit document link to search results.

The binaries and source code are available at CodePlex. If you have any issues, please log them there on the Issue Tracker. If you have any idea of other kinds of links we can provide off of a document library, please leave a comment. This can also be used with the Wildcard Search web part. Hopefully this will help many others out there deliver even richer search solutions to their customers. Thanks.

Document Link Handler for MOSS 2007 Enterprise Search

Real World Dojo part 5: Custom Components

JamesAshley — Tue, 28 Oct 2008 21:47:00 GMT

Dojo has its own built-in system for creating your own server-side controls. It's (arguably) better to use that than, say, creating a .NET user control....(read more)

Adding an Edit Document Link to Enterprise Search Results

CoreyRoth — Mon, 27 Oct 2008 22:18:05 GMT

I have seen a lot of requests to get more functionality on search results for documents lately. People want to be able to edit documents, go to the folder the document is in, go to the site, view properties, etc. I have solutions for all of those which I will be sharing in the next few days. However, I wanted to share this one first, because it is easy to implement and does not require any custom code. The goal is to get a link that will allow you to edit the document (instead of opening it in read only mode) directly from your search results.

As you will see the solution is actually quite simple. Start by editing your results.aspx page and then edit the CoreResultsWebPart. I have chosen to put my Edit Document link on the line following the title of the document. In the Data View Properties of the web part, click XSL Editor. Scroll down and look for the span with a class of srch-Title and insert the following block of code after the closing span and before the srch-Description.

<a href="{$url}" onclick="return DispEx(this,event,'TRUE','FALSE','FALSE','SharePoint.OpenDocuments.3','0

','SharePoint.OpenDocuments','','','','1','0','0','0x7fffffffffffffff')">Edit Document</a>

</div>

Save the XSL and click Apply. You should now see an Edit Document link in your search results similar to the one below.

Clicking on the Edit Document link will present the user with the Read Only / Edit menu just like they get when they are opening the document from a document library.

How did I figure this magic out? It really was pretty simple, I just looked at a document library page and figured out what script method was being called. If you spent money on a high dollar product just to get this feature, I am sorry. Also remember that the Edit Document functionality only works in Internet Explorer. Try it out and see if it works for you. For other document functions such as Go to Folder, View Properties, and View Version History, take a look at my Document Link Handler for Enterprise Search.

Real World Dojo part Four: User Feedback

JamesAshley — Thu, 23 Oct 2008 22:13:00 GMT

You have to let the user know what's going on. That's one of the main points, isn't it?...(read more)

Real World Dojo part Three: AJAX

JamesAshley — Thu, 23 Oct 2008 21:19:00 GMT

I've avoided this as long as possible. It's time to bite the bullet and do some AJAX....(read more)

Intro to SharePoint Development: How to Build and Deploy a Web Part

CoreyRoth — Wed, 22 Oct 2008 12:50:00 GMT

I've recently helped out a number of developers new to SharePoint and I found that I have been often asked the same types of questions. Most of those involve getting started and deployment, so today, I am beginning my series on getting started with SharePoint. Most new developers find starting out pretty overwhelming, but once you get used to it, it does all make sense. Hopefully this post will help the community and keep new SharePoint developers from getting scared off. There have been a lot of posts on this topic I admit. Since there are so many ways to do things, I wanted to write this post as a reference to new developers so they can see how I usually do things. What I find is that most developers have no trouble getting a web part built, but when it comes time to deploy it, they are lost. There are multiple ways to do this and not all of them are necessarily the right way.

Environment

Let's start by talking about your development environment. In an ideal situation, you probably have your own virtual machine with Windows Server 2008 (or 2003), MOSS 2007, and Visual Studio 2008 installed. However, maybe you don't have your own dedicated machine and you are going to be developing on a Windows XP machine, but deploying to a remote SharePoint server. This is fine, but you are going to have to do some things a little differently. First, you won't be able to install the Visual Studio Extensions for SharePoint. You can live without this though because most people I have ran into say they don't use them. Secondly, when it comes to deployment (which we'll talk about down below), you are going to have to copy your source files (either manually or via solution package) to the server. You are also going to have to remote debug but fret not my post on it makes it easy.

If you are developing on a desktop, another thing you will need to do is copy the SharePoint assemblies to your computer. We can easily get these from a deployed SharePoint server. However, this is a great time to take an aside and talk about some of the SharePoint directory structure.

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12

All SharePoint developers have that file path permanently burned into their memory. It is often referred to as the 12 hive. A lot of things happen within this folder. Subfolders here contain the SharePoint binaries, Master Pages, Application Pages, User Controls, Configuration Files, and Features. Although SharePoint will let you customize any file in here, in general you don't want to make changes to any of these builtin files as it puts you in an unsupported scenario. If you want to customize a master page or a style, it is typically best that you make a copy of what you want to customize and go from there. Here is a quick list of some of the key folders and what they are used for.

Folder	Description
CONFIG	Contains partial trust configuration files
ISAPI	Binaries and SharePoint Web Services
LOGS	Error Logs (look here first when you get a strange error)
TEMPLATE\CONTROLTEMPLATES	User Controls
TEMPLATE\FEATURES	SharePoint Features (turns functionality on and off)
TEMPLATE\IMAGES	MainImages Folder
TEMPLATE\LAYOUTS	Pages and Styles
TEMPLATE\SiteTemplates	Definitions avaiable for deploying new sites
TEMPLATE\THEMES	Used to create custom themes in SharePoint
TEMPLATE\XML	Contains XSDs for any XML used with SharePoint

Enough on that tangent, back to the assemblies that we need to copy. Go to the above path and then go into the ISAPI folder. Copy all of the DLLs from this folder onto your desktop machine in the corresponding folder name. If you don't have that folder, create it. You may also copy them to the Global Assembly Cache as well. Once you are this point, you are ready to being building a web part.

Coding the Web Part

Start by creating a new class library project in Visual Studio. There are packages and tools out there to automate some of these steps, but its best that you learn how to do it first by hand, so you know how to troubleshoot it should something go wrong. Next, you will want to add (at a minimum) a reference to Microsoft.SharePoint.dll. You can either grab it out of the GAC (will be listed under Windows SharePoint Services) or use the copy that you put in your ISAPI folder. After you add it, make sure Copy Local is set to false on your reference. You will also want to add System.Web since more than likely your web part will use an ASP.NET control in it. You are now ready to create your web part. To do this, create a new class and add a using statement for Microsoft.SharePoint. In the past, you would derive your class from Microsoft.SharePoint.WebPart (and you still can), but now the more accepted way of doing things is to derive from the new System.Web.UI.WebParts.WebPart class. The latter comes from ASP.NET 2.0 and can actually be deployed outside of SharePoint. Here is what our class is going to look like.

public class TestWebPart : System.Web.UI.WebControls.WebParts.WebPart
{
    protected override void CreateChildControls()
    {
        base.CreateChildControls();
        Controls.Add(new Label(){Text = "My Test Web Part (Hello World)!"});
    }
}

The content of the class is simple. We use the overridden CreateChildControls method to add ASP.NET controls to the page to do the rendering. I simply call Control.Add and add a Label control with the text above. Compile it and this web part is good to go, but there is the small matter of deploying it. Compiling it yield you a DLL that has be deployed to SharePoint somehow. SharePoint also needs to know where the web part is and how to reference it. This is where the .webpart file comes in.

Describing the WebPart

The .webpart file is an XML file that tells SharePoint what to call your DLL and what assembly it is located in. The easiest way to get started creating this file is to copy another one in SharePoint. You can find plenty of examples by going to your web part gallery (Site Root -> Site Settings -> Web Parts). this file simply describes the class and assembly of your web part as well as some default properties (i.e.: it sets a title and description). You can also add your own properties by specifying a series of attributes on a property in your class.

<webParts>
  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
    <metaData>
      <type name="MyWebPart.TestWebPart, MyWebPart, Version=1.0.0.0, Culture=neutral" />
      <importErrorMessage>Cannot import this Web Part.</importErrorMessage>
    </metaData>
    <data>
      <properties>
        <property name="Title" type="string">My Web Part</property>
        <property name="Description" type="string">A test web part.</property>
      </properties>
    </data>
  </webPart>

Note: There is also a .dwp file, which comes from version 2, that can describe your webpart as well. It still works but it is consider deprecated.

Ghetto Deploying

So far, we have built a web part and created a .webpart file so now it is time to deploy it. We'll start by doing it the wrong way. The first thing to know is that you can't just copy your DLL into the bin folder of your web application unless you change to full trust (not recommended) or specify Code Access Security. Specifying CAS when first starting out will make even the most seasoned developers run for the hills. So we are going to start by deploying to the GAC. In almost all situations, I recommend against this, but for the sake of getting you started, it is ok. You can then follow the Code Access Security post later on how to set up everything properly.

Start by copying your compiled DLL into the Global Assembly Cache of your SharePoint server. Keep in mind anytime you update this DLL, you will need to either reset IIS or recycle the application pool (otherwise the old version stays in memory). The next thing you need to do is upload the .webpart file to the web part gallery of your site collection (again Site Root -> Site Settings -> Web Parts). At this point, SharePoint will be able to recognize your web part and it can be added to a page. If you click on the name of the web part in the gallery (in this case MyWebPart.webpart), it will display a preview of what it will look like on a page. If everything is working correctly, you will see your web part, otherwise you will get an error. At this point, you will have the following error.

A web part on this web part page cannot be displayed or imported because it is not registered on this site as safe.

This is because there is one more step to do. Every web part or user control in SharePoint must be registered as safe to execute in the web.config. To do this, find the SafeControls element near the top and add the following line (changing it with your fully qualified assembly path).

<SafeControls>
  <SafeControl Assembly="MyWebPart, Version=1.0.0.0, Culture=neutral" Namespace="MyWebPart" TypeName="*" Safe="True" />
</SafeControls>

Now when you go back to the web part gallery, it should give you a preview of your web part. If it doesn't check your assembly paths and make sure the file is deployed. If you still have issues, check out this post on troubleshooting a web part. Assuming you were able to get the web part to preview, you can also go add it to a page by going to any page, clicking Edit Page and then Add Web Part. Scroll through the list until you find your web part and select it. You should then see your web part on the page.

Features

So we talked about deploying a web part the wrong way. Ok, it's not necessarily wrong, but it really adds a lot of extra work This can be automated quite a bit by using features and solution packages. Creating a feature, allows you to turn on and off customizations to SharePoint at the click of a button. They can be used to deploy web parts, site definitions, workflows, document libraries, and plenty of other things. In this case, we are building a feature to automate the deployment of our .webpart file. You can also specify a class (Feature Receiver) that is executed when the feature is installed, activated, deactivated, or uninstalled. A feature typically consists of two XML files. The first file Feature.xml (must be named that), describes the feature and where its feature receiver is (if any).

<Feature 
    xmlns="http://schemas.microsoft.com/sharepoint/" 
    Id="{BDD425C3-CA50-4aee-9170-73954044D764}" 
    Scope="Site" 
    Hidden="False" 
    Title="My Web Part" 
    Description="My Test Web Part"
    >
  <ElementManifests>
    <ElementManifest Location="Elements.xml" />
  </ElementManifests>
</Feature>

The Id element contains a GUID. Every feature needs a different one. The Scope attribute specifies where to deploy the feature. Possible values are Site, Web, WebApplication, and Farm. I would go into the difference in scopes, because this post is already getting long enough. You will most likely use Site or Web for most things you do (note on terms in API). The ElementManifest element makes calls to additional XML files. Typically the other file is called Elements.xml (although it can be called anything).

The Elements.xml file can be used to deploy files, create document libraries, and many other functions. I won't go into the whole detail of this file (it's in the SDK), but basically we are specifying that the MyWebPart.webpart file should be copied into the web part gallery. I will tell you what a few things are though. In this case the Module element says that we are going to deploy something into a list that is located at _catalogs/wp (this is the URL of the web part gallery). How did I figure this out? I looked at another example. The File element deploys our MyWebPart.webpart file into the web part gallery. I wont go into why you set the Type to GhostableInLibrary right now. Just know this is the value you will pretty much always use.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="WebPartPopulation" List="113" Url="_catalogs/wp" RootWebOnly="TRUE">
    <File Url="MyWebPart.webpart" Type="GhostableInLibrary" />
  </Module>
</Elements>

When the feature is activated, it will put the file in the web part gallery. However, it won't remove the item from the web part gallery on deactivation. It's pretty easy to do with code and I still plan to write a post on it. For now, if you want the .webpart file gone you will have to delete it manually. During the development cycle though, the only time it really is necessary to remove a .webpart file is if you have changed the namespace, class name, or public key token. Here is what an elements file typically looks like for deploying a web part.

So where do all these files go? Let's talk about where you put them in your Visual Studio project first. Typically, what you will do is create a folder structure in your project that matches the 12 hive. So in this case, we will create a TEMPLATE\FEATURES folder. We will then create a folder for our web part. I am just calling it MyWebPart for now. Here is what your solution will look like. This folder is where you will put Feature.xml, Elements.xml, and MyWebPart.webpart.

To deploy the feature, copy it to the TEMPLATE\FEATURES folder in your 12 hive. You then need to use stsadm command to install it. The stsadm executable is located in the bin folder of the 12 hive. You tend to use it a lot, so you might want to put it in your path environment variable. Once you have located it, issue the following command.

stsadm -o installfeature -name MyWebPart

This makes the feature available to be activated. To activate it, go to Site Collection Features (Site Root -> Site Settings -> Site Collection Features). Find the feature in the list and click the Activate button. This deploys the web part to the gallery and it can be added to pages as before. If you ever want to remove the feature, use the uninstallfeature operation. You will want to deactivate the feature first, otherwise you will have to use the -force parameter when using stsadm.

Deploying Via Solution Package

Features are nice, but we can take this one step further. A solution package (.wsp file) allows you to package your entire solution into one .wsp file for deployment. A .wsp file is simply a cab file with a manifest.xml file that tells SharePoint how to install the contents. It will even deploy and install your feature for you, allowing you to skip the installation steps above. Two files are required to build the .wsp file: cab.ddf and manifest.xml. These files typically go into a folder called Solution in your Visual Studio project. Cab.ddf tells the utility, makecab.exe, how to construct the .wsp file. Below is an example DDF file. You will need to set the CabinetNameTemplate to the filename you want for your wsp file. You then specify a source and destination for each file you want copied. In the example below, note that I am copying the DLL, Elements.xml, Feature.xml, and MyWebPart.webpart file.

; ** MyWebPart.wsp **
.OPTION EXPLICIT    ; Generate errors 
.Set CabinetNameTemplate=MyWebPart.wsp
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP;** All files are compressed in cabinet files
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=Package
 
Solution\manifest.xml manifest.xml
 
; binary
bin\debug\MyWebPart.dll MyWebPart.dll
 
; feature files
TEMPLATE\FEATURES\MyWebPart\Elements.xml MyWebPart\Elements.xml
TEMPLATE\FEATURES\MyWebPart\Feature.xml MyWebPart\Feature.xml
 
; web part files
TEMPLATE\FEATURES\MyWebPart\MyWebPart.webpart FEATURES\MyWebPart\MyWebPart.webpart

I won't go into manifest.xml again because I have already covered it once in this post. It's this file that tells SharePoint how to deploy features, copy files, setup code access security, and add SafeControl entries to your web.config. Once you create your solution files, build your project and then go to the command line. The utility makecab.exe (should already be on your system) will actually create the wsp file. In the command prompt, go to the root folder of your project and execute the following command. It has to be executed from that folder because all of the paths are relative.

makecab.exe /f solution\cab.ddf

You can automate this step when you build, by creating a build action.

If you are working on a remote server, you will need to copy the .wsp file onto the server. Add and deploy the solution with the following commands.

stsadm -o addsolution -filename package\MyAssembly.wsp
stsadm -o deploysolution -name MyAssembly.wsp -immediate -allContentUrls -allowGacDeployment
stsadm -o execadmsvcjobs

At this point if all goes well, your solution will be installed and deployed. This eliminates all the steps of manually copying files into SharePoint. You can then activate your feature like before (remember it installs the feature for you) and add your web part to a page. If you make an update to your web part, deploying is easy, just use the upgradesolution stsadm command and it will update all the files in your solution. Should you decide, you don't need the solution any more, use the retractsolution command. After you issue either of those commands, you will need to follow it up with a execadmsvcjobs command as shown above.

This may sound like a lot, but it really isn't bad. It makes deployment really easy (especially to other servers). Once you have your solution deployed and you want to make an update, you can also just directly copy out the binary to your server. Not really a best practice, but it does speed things up quite a bit, since stsadm commands take a few seconds to run.

Once you get the hang of it and are familiar with the deployment process, you really need to consider deploying your solution to the bin folder by deploying your solution under partial trust. Remember right now, you are deploying to the GAC which is not ideal. My post on Code Access Security walks you through the whole process and provides more details on how solution packages are built.

User Controls

By now, you may be thinking, I went through all of that and I still have to render stuff to the screen using straight code? I hear you. It's not any fun at all and can be a controversy among some SharePoint developers. You do have a couple of alternatives, use the SmartPart or write your own. I typically go with the latter. This simple web part uses Page.LoadControl to load the .ascx file you specify.

This is quickly becoming the longest post I have ever written. I've attached the code I used in this post. You can use it to verify that you put your own web part together correctly or you can use it as a starting point. I hope this provides enough information for a new SharePoint developer to get started. I certainly wish I had this much info condensed in one place when I was starting out. You may also want to check out one of the many solution generating tools out there such as stsdev. Please leave a comment if this helps or if you have any questions. If I am missing anything or you think I need to add anything, also please let me know.

SharePint Tonight!

CoreyRoth — Thu, 16 Oct 2008 18:55:25 GMT

Just a reminder about tonight's SharePint meetup at Crawpappy's. Officially starts at 6, but we'll probably be there early. This will be a great opportunity to talk to other members of the SharePoint community here in Tulsa. I don't expect it to be as wild as Beer and Code, but it should still be a good time. We'll see you there!

My 500th Post! Left Outer Joins with LINQ

CoreyRoth — Wed, 15 Oct 2008 19:43:46 GMT

Today, this blog reaches an important milestone. This is my 500th post. It's just a number, but I thought I would use it as an opportunity to talk about the history of the blog and where it is heading. On December 1st, 2004, I wrote my first .NET Tip of the Day about a great new method on primitives called TryParse in the upcoming release of ASP.NET 2.0. This blog started out as a simple announcements list built on a SharePoint intranet site so that I could educate a team of developers on emerging technology (at the time it was .NET 2.0 and SQL Server 2005). When I left that company, I wanted to keep the concept going so I exported all of the content and created a home-grown blogging engine at dotnettipoftheday.com. Since then, I have been committed to giving back to the community by providing useful information that will help developers do their every day jobs. My blog has always focused on how to do something not to give my opinion on something that I may or may not know anything about. Admittedly, I haven't been able to keep up with the daily thing of posting (although I did a pretty good job back then), but I still make an effort to post a few things a week.

Sometime in 2007, the term DotNetMafia was coined by the godfather himself Kyle Kelin. Although the original idea for the mafia has evolved, it turned out to be a great way to get blogs from several of us onto one web site, dotnetmafia.com, which ran on DotNetNuke. The site worked ok for us for a while, but it was lacking. Later that year, I imported everything (well almost everything) into a new Community Server site where we are today. In case you haven't seen the rest of the DotNetMafia bloggers, be sure and check out Tony Kilhoffer, James Ashley, Cory Robinson, and Kevin Williams. They post on a variety of topics (including some outside of .NET).

In nearly 4 years, I have brought you 500 posts. 112 of those posts have been on SharePoint. Obviously you can see that I have shifted focus some. The main reason is I blog about the things I am working with on a daily basis. Right now, that has been SharePoint. Although I still find time to blog about LINQ and other things from time to time. Let's face it though, the SharePoint community needs all the help it can get. Sites like SharePointBlogs.com (which this feed is syndicated too), have made a huge difference in helping people find the right information. This is why I am committed to posting every nuance I find in the product, so that the next SharePoint developer coming along doesn't have to spend time trying to figure it out.

I am pleased with how the site has grown to date. In four years, we have gone from having a couple of internal users a month, to 200 - 300 unique visitors a day. 65% of that traffic each day comes from search. The rest are from RSS subscriptions, referrals, and my CodePlex project. For now, I plan to keep the content coming and encourage others to blog too. I am committed to helping the community even more and hope to continue to grow the site and organize meetups. I want to thank all of my friends, all two of my readers, Copy Source as HTML, and everyone that has left a comment. I really appreciate it.

Enough fluff for now though, let's get to some content. I am going to step away from SharePoint for today's post and try to hit a broader audience talking about LINQ.

Left Outer Joins with LINQ

The topic I am talking about today is doing left outer joins with LINQ. Doing a join in LINQ is pretty simple, however doing an outer join is a bit more tricky because the way you do it doesn't follow the way you would think of it using T-SQL. The documentation on LINQ covers how to do this, but it doesn't do a great job explaining what you are doing and why. For this example let's say we have two classes Product and Inventory. The Product class has the following properties Name, ProductId, and Price. The Inventory class has the properties ProductId and Count. We want to get a list of all products and know how many we have in inventory but unfortunately the Inventory table isn't complete and it doesn't have data on all products. We still want the product to return in a query though.

First, for the purpose of example, I populate two lists. This could just as easily come from an XML document or SQL. In this case we have three products and two items containing inventory, but info is missing for one particular product.

List<Product> productList = new List<Product>();
productList.Add(new Product() { Name = "Product 1", Price = 10.99f, ProductId = 2 });
productList.Add(new Product() { Name = "Product 2", Price = 1.99f, ProductId = 5 });
productList.Add(new Product() { Name = "Product 3", Price = 3.99f, ProductId = 9 });
 
List<Inventory> inventoryList = new List<Inventory>();
inventoryList.Add(new Inventory() { ProductId = 2, Count = 54 });
inventoryList.Add(new Inventory() { ProductId = 9, Count = 31 });

If this was a T-SQL query it would probably look something like this:

SELECT p.Name, i.Count FROM Products p LEFT OUTER JOIN Inventory i ON p.ProductId = i.ProductId

In LINQ it is going to look a bit different though.

var productInventory = from product in productList
                       join inventory in inventoryList
                       on product.ProductId equals inventory.ProductId into productInventoryGroup
                       from item in productInventoryGroup.DefaultIfEmpty(new Inventory() { ProductId = product.ProductId, Count = 0 })
                       select new
                       {
                           Name = product.Name,
                           ProductId = product.ProductId,
                           Count = item.Count
                       };

The first thing we do is get a reference to an instance of the class (product) out of the productList with the from clause. We then can join that to the inventoryList. Remember in LINQ, you always have to have a reference to the class itself and not the collection when performing join and where operations, so we also get a reference to an instance of the class (inventory). Once we have that we can use the on clause to relate the two lists using the ProductId field. When doing a join you must use the keyword equals to relate the two collections.

Here is where things really differ from what you may be used to. The first thing that is different is that the result of the join is stored in a new variable using the into clause (in this case productInventoryGroup). This is because in LINQ you use the DefaultIfEmpty() method to specify default values to return when there are no matching values on the right side of the join. You can specify no parameter on this method to use the default when it is empty (usually null or 0 for an int), or you can pass a value for it to use. In this case I created a new instance of Inventory and set Count to 0. You then use another from clause to reference an item from that join. Once you get to this point, it is just a matter of creating a new anonymous type, with product.Name and item.Count as values. Remember, item in this case is of type Inventory and will contain the value from that list or the default if there is no match.

You can then iterate through the result of the join like usual.

foreach (var item in productInventory)
{
    Console.WriteLine(string.Format("{0}: {1}<br />", item.Name, item.Count));
}

Which would return the following results.

Product 1: 54
Product 2: 0
Product 3: 31

It really isn't that bad, but it's just different than what you might be used to coming from the T-SQL world. Hopefully, this explanation helps and will be of use to you.

Of course, don't forget that tomorrow night is the SharePint meetup at CrawPappy's at 6:00pm. Thanks again.

Real World Dojo part Two: File Upload

JamesAshley — Wed, 15 Oct 2008 06:05:00 GMT

The basics of using the new file uploader...(read more)

Real World Dojo part One: Form Validation

JamesAshley — Tue, 14 Oct 2008 22:18:00 GMT

Real World Dojo, part One (Basic Validation) The Scenario: I’ve kind of been nibbling around the edges of Dojo for a while, but I’m at a place in this project where I really need to buckle down and learn it. Since I’m having so much trouble finding real-life examples of the basics, I figured I’d share what I’m coming across. I have a very simple proof-of-concept form that shows the basics of the one that forced me to buckle down. It looks like this: <head> <title>Validation Test (raw...(read more)

Wildcard Search Version 1.0 Release 3

CoreyRoth — Tue, 14 Oct 2008 21:46:09 GMT

Release 3 of the Wildcard Search Web Part is now available. This minor update fixes a user reported issue where the scope property was not being used. If you are new to the blog, the Wildcard Search web part allows a user to do partial word queries with Enterprise Search (i.e.: searching for red, returns results matching redmond, redding, and red). Please continue to report bug on the CodePlex site. Thanks again for everyone's input.

Also, don't forget the SharePint meetup, this Thursday at Crawpappy's at 6pm.