Love My Droid

I just got a Droid and I am playing with the blogging app. I love the Google maps and screen quality. I was really looking forward to the slideout keyboard, but that is the one thing I am disappointed in. It is kind of hard to use, but still better then screen keyboards. Anyways, this is not my typical blog (I usually hate pointless blogs). I just wanted to test out the blog app.

Presenting at SharePoint Saturday DC

I am presenting at SharePoint Saturday DC on December 5th (http://www.sharepointsaturday.org/dc/default.aspx).

My presentation is on building custom, “accessible” SharePoint sites.

Most of the projects I work on in SharePoint are custom websites built on top of the SharePoint framework. I constantly hear ”can you make this site not look like SharePoint”. Most SharePoint developers, architects and designers know the tricks to do this now a days.

Also, the start of my career was in government services. However, the last 5 years have been on the commercial side. It was in the commercial world that I primarily worked with SharePoint. I am now back in the government world again and 508 accessibility is a common requirement. I learned about 508 accessibility when I started my career in government and now I am trying to mesh my SharePoint knowledge with my accessibility knowledge.

This presentation is my attempt to show tricks and tips to make a SharePoint site accessible. This presentation focuses on building “custom” SharePoint sites because I am showing proper custom master pages, page layouts, control adapters, web part zone customizations, etc… I am not concentrating on out-of-the-box SharePoint Intranets, but a lot of the techniques will work either way. The intent of this presentation is to not only show 508 accessibility tricks, but to also show web standard and css tricks that lead to a more accessible/cross-browser websites.

I look forward to this presentation now that this is one of my passion areas that most people don’t concentrate on in SharePoint. However, everyone should think accessibility when using SharePoint as a framework to build custom websites, regardless if you are in the government or not.

SharePoint Conference Notes on SharePoint 2010 – Day 3

I am continuing my notes from the SharePoint Conference. Today I attended the Capacity and Performance Management, Externalizing BLOB Storage, and Advanced Development for Silverlight 3 in SharePoint sessions. I also did some hands on labs.

Link to my blog postings for each day at the conference.

 

 Capacity and Performance Management

• Latency Improvements
  • Lighter and Faster pages
  • Early Rendering
  • WAN Optimizations
• File Save Latency – this is a new feature that is used with Office 2010 documents and SharePoint 2010. Basically, you don’t see a save file dialog when saving large files. Instead, the file is saved to the local machine cache and incrementally uploaded to the SharePoint list. It should make for a great user experience in these situations.
• Data Scale Improvements
  • 100 million items per search index (1 billion with FAST)
  • Tens of millions of documents/items in a single list
  • View/Query 5000 items at a time
• Some of the 2007 limits stay the same
  • Site Collections per web application – 150,000
  • Site Collections per content database – 50,000
  • Content database size – 100 GB
• Sharepoint Administrative Toolkit – new tools for capacity management. They didn’t give me too much details on this, so I am not sure if these are the exact names
  • Load Test Kit 2010
  • SPDiag 2010 – this is to do production monitoring
• Logging is done in the database
  • Health data
  • Usage data
  • Gathers data across boxes through data providers
  • Extensible framework – we can build custom providers and custom reports
  • You can see the data through SQL Views, reports, Excel pointing at the SQL data, etc…
• Different Server Architectures:
  • Single Server – for demos and dev boxes
  • Small Farm
    • around 500 users (~5 rps) and 50-100 GB of data
    • Usually 2 WFE/App Servers with a SQL cluster
    • App Servers can run on the WFE
  • Medium Farm
    • 10-50k users (~50rps) and 1-2 TB of data
    • Separating App Servers from WFE and scale out/load balancer both
  • Large Farm
    • 500k users (~500rps) and 10-20 TB of data
    • Lots of WFEs
    • Lots of App Servers
    • Lots of SQL Servers – probably 5TB per SQL box
    • Probably think about splitting your farms up if you have this situation
• In medium or large environments, consider setting up a SQL Cluster for the content databases and a separate cluster for the logging and web analytics db. This was highly recommended.
• Microsofts internal beta environment (this is probably larger than most organizations will need):
  • 3 General WFE
  •  1 WFE for dedicated search
  • 1 App Server for: Central Admin, User Profile Service, Metadata Management Service and Word Conversion Service
  • 2 App Servers for all the other services.
• Recommended Server specifications:
  • 64 bit
  • WFE – Dual processor, 8 GB RAM
  • SQL Server – Quad Core, 16GB RAM

 

 Externalizing BLOB Storage – stores BLOB data separate from the Content DB on the file system

• BLOBs typically account for 60-70% of total content in SharePoint
• The official name for externalizing BLOB storage is: Remote BLOB Storage (RBS)
• This is different from EBS (External BLOB storage), which was released in SharePoint 2007 SP1 and had issues: http://www.cleverworkarounds.com/2008/03/25/sharepoint-external-storage-api-crushing-my-dream/
• Advantages over EBS:
  • Managed Interface
  • BLOB store scope = Content DB (verse the farm for EDS)
  • SharePoint UI = PowerShell
  • Number of Providers = Many (verse 1 for EDS)
• Why use RBS?
  • Ability to group/store BLOBs separate from Metadata
  • Trade cost effective BLOB storage for expensive SQL storage
  • Storage management beyond SQL
• A number of storage vendors are working with RBS – EMC, OpenText, AvePoint, Commvault, NetApp
• RBS is a downloadable component in the SQL Server 2008 R2 Feature Pack
• You can turn on RBS by a simple enable command in PowerShell and then the file gets stored on the file system
• Install:
  • RBS Add in must be on SQL first
  • RBS and provider DLLs must be installed on all Web Front Ends
  • RBS must be enabled using PowerShell
• BLOBs from SQL can be moved to RBS with a PowerShell commandlet
  • Migrates one BLOB at a time
  • You can terminate and resume the process
  • It is a live migration – no downtime required

 

Here are the Hands on labs I did today and my thoughts:

• Business Intelligence - this lab dealt with Excel Services, Visio Services and PerformancePoint. I was really impressed with the new Visio Services. The Visio part of the lab started with an excel spreadsheet in a SharePoint document library. Then I opened Visio 2010. From there I could hook the data, from the excel spreadsheet, into Visio. Then I connected the data to my Visio objects. This example had a column in excel called status. If the status was 1, my server image in visio was green, if the status was 0, my server image in visio was red. After that I published the Visio diagram to SharePoint and it created a Visio Services diagram in my SharePoint site. So, I could view the Visio diagram in a web page. Then came the cool part – I edited my excel spreadsheet data (which was also in a SharePoint library) and it changed my Visio diagram automatically. This example was a quick way to show a server health dashboard controlled by excel data. But, I can think of lots of other possibilities for this new technology.

SharePoint Conference Notes on SharePoint 2010 – Day 2

I am continuing my notes from the SharePoint Conference. Today I attended the Service Applications, Developing SharePoint on Windows 7 and the Development Best Practices sessions. I also did some hands on labs.

Link to my blog postings for each day at the conference.

Service Applications - this is the replacement for Shared Service Providers (SSP). They’ve ported all the SSP functionality (BDC, User Profiles, Search, etc…) to this Service Application methodology and then added around 20 new services. If you think of SSP as running on a single box or web application, think of Service Applications as running as a Middle Tier Service Layer. They talked about how these are not confined to a box, they are truly services now. Here are some advantages I’ve heard with Service Applications:

• You can configure seperate databases and application pools per service
• The Web Application chooses which services it talks to
• Services run on an application server and this application server doesn’t even have to be on the same farm as your web application. As long as security is configured correctly, you can talk to services from an application server on another farm. This is great for Enterprise situations in which a company has multiple farms. Each farm can reuse all, or some of, the services from the main application server. A great example of this is User Profiles. If an application is running off of AD, you only need that User Profiles on one farm, even if a company has valid reasons for separating their farm structure do to other security and/or functionality constraints.
• Application servers are load balanced out of the box. SharePoint 2010 provides a software load balancer and you can use the load balancer on applications servers (note: you can change this to hardware load balancing if you want). This means these service applications have redundancy built in if you build your infrastructure with more than one application server.
• SharePoint Foundation (formerly WSS) can also run services – just not the ones dedicated for SharePoint 2010 (formerly MOSS)
• This is an extensible framework. You can build custom services for your farms. This is going to be huge for the third party market.
• The one downside to this is going to be governance (in my mind). We are going to have to control and plan where the services reside and how other farms can use them. It will change the whole structure of how we architect/plan SharePoint sites in large Enterprise situations.

Developing on Windows 7

• There are a couple models to do this:
  • Install SharePoint, in standalone mode, on the Windows 7 machine
    • There are pre-requisites for doing this, they can be found here: http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx
    • This will run the SharePoint services on your desktop
    • This uses SQL Express by default
  • Use bootable VHDs and run Windows 7 or Server on the VHD
    • These are not virtual machines (VPC is dead), but just the VHD
    • You can only run one at a time because you choose it from the boot menu
    • You can create these VHDs from Windows 7 or from a Hyper-V machine. The presenter noted that it is easier to build them on a Hyper-V and then add them to a Windows 7 boot (if you have Hyper-V available)
    • The performance impact is negligible as long as you use fixed size VHDs
  • Use Hyper-V (this is not developing on Windows 7, so they didn’t go into this)
• There are performance considerations for running SharePoint on your local machine. The presenter actually showed that it isn’t that bad – he showed that his machine was only utilizing a little over 4GB of memory. But, you don’t want SharePoint hogging your memory when you are not using it (i.e.: doing the regular laptop/desktop activities during the day). Here are some ways to help with the performance considerations:
  • Set useless services off (useless in terms of development). These are things like Usage Data Collection and Health Data Collection.
  • Set some services to “Auto Start (delayed)”. This delay’s the start of the service when the computer starts up.
  • Utilize PowerShell scripts to stop the SharePoint services (including all the SQL Express stuff). The presenter gave me the scripts to do this, so be on the lookout for a blog on that soon
• The presenter showed a lot of PowerShell scripts to help development
  • You can turn on/off the developer dashboard through PowerShell. This can help performance when you aren’t developing.
  • You can start/stop services and SQL Express in order to turn SharePoint off when not in use.
  • You can set up a Visual Studio project to run PowerShell scripts. This is really cool because you don’t have to go outside VS to run scripts. It seemed a little clunky to set up (you have to set some x64 stuff in a console application). But, it is possible.
• Here are the presenters recommended specs to run SharePoint on a dev machine 
  • x64 dual proc 2Ghz, 8Gb Ram, 80Gb HD.
  • If you are going to run lots of bootable VHDs, you might want to increase the hard drive space. The presenter mentioned the fixed size for a bootable VHD should be around 45GB or higher.

Development Best Practices -  This session described best practices that are applicable from SharePoint 2007 and how they translate to SharePoint 2010. I didn’t learn much in this presentation because it was either things that were best practices in  class=”hiddenSpellError” pre=”in “>SharePoint 2007 or things that have already been said. The general gist of this session was: develop on standalone developer machines or bootable VHDs, do unit testing and package your code in WSPs.

Here are the Hands on labs I did today and my thoughts:

• PowerShell - I was impressed with what we can do with PowerShell. There are over 500 commands and they provide a lot of functionality. The lab started with showing how you can get an SPSite object. Then it showed how you could update an SPSite object in PowerShell. So far, this is all stuff I could do in Central Administration. But, then it showed how you can loop through sites and pipe them together to do everything at once. For example: they showed how to change all the secondary site collection administrators, on all site collections in a web application. They also showed how to create a sub-site for all site collections in a web application. This will make scripting and deployment much easier in the future. The only issue I have so far is the amount of PowerShell scripts they have and the PowerShell language (I guess I have to learn that now).
• Advanced WebPart development - this was ok. The lab just showed how to create and deploy Visual WebParts (which is just creating user controls). The thing I noticed here was the ease of development/deployment and the speed of deployment. Even though it was recycling the application pools, the site came up fairly fast. They mentioned that they’ve been tweaking this process to make deployments more bareable for us developers.
• External Content Types - I did a lab that showed me how to hook database data into a SharePoint list. This was all done through designer (even though you can do it in Visual Studio) and took only a few steps to set up. After hooking the list to the database table I could update the data, from my SharePoint list, and see it updated in the database. Very Cool.

SharePoint Conference Notes on SharePoint 2010

I am currently at the 2009 SharePoint Conference where they are unveiling the details of SharePoint 2010. I’ve attended a lot of developer focused sessions today and wanted to list out some of the more intriguing functionality I’ve heard about.

Link to my blog postings for each day at the conference.

• SharePoint can be installed on a local developer machine !!!!!!!!!
  • When I first heard you can develop SharePoint on your local machine I thought you had to point the solution at a site running on a server. But, that is not true. You can actually install SharePoint on your local machine and point your development at that or a site running on a server.
  • Machine must be Windows 7 or Vista – as long as they are x64
  • This means no more virtual machines for me (what will I do with all my external drives that hold my old VPCs)
  • The install for this version is a little different from installing on a server
    • This is just for developers and is not supported for production
    • This can only be a standalone version
    • The pre-requisites are not automatically installed like the server installation does. You have to go through the SDK and manually install the pre-requisites
    • This functionality can be disabled through a group policy if a company doesn’t want people installing SharePoint on their local machines
• New names (of course, every new version of SharePoint means new names to remember). Here are the mappings to the 2007 names
  • MOSS = SharePoint 2010
  • WSS = SharePoint Foundation
  • 12 Hive = SharePoint root
• The development experience is vastly improved. I thought Microsoft was just going to revamp Visual Studio Extensions. But, it looks like they built it from the ground up with all the features we have been asking for. So, no more WSPBuilder for me.
  • Visual Studio will retract the solution, deactivate the features and install the solution. But, that is just the default way it does it. You have complete control over the deployment process for the WSP it builds by changing a couple properties at the project level.
  • The deployment functionality has built in “extra” functionality for the type of element being deployed. For example:  WebParts will actually get removed from the WebPart gallery when the solution is removed. And, this is a default behavior that you can modify if you want. This new feature is called Deployment Conflicts.
  • Visual Studio has a SharePoint Explorer view. You can see your whole SharePoint structure, for a site, in this new view. And, you can dig all the way down to specific items to see their properties.
  • Deployment can be done directly to your site for development purposes. Or, it can just be exported to a WSP.
  • The whole process is customizable. I didn’t see anything that forces you to do it the “Microsoft way”. For example: They create the Manifest for the solution. But, they give you a way to “append” to their manifest (this kind of does a merge) or they allow you to completely replace their manifest.
  • The new development experience in Visual Studio 2010 is probably the most exciting thing that I’ve seen so far (other than the fact that we can deploy on our local machines). So, actually, the whole development experience is the most exciting thing I’ve seen so far.
• Visual WebParts – these allow us to build user controls that get deployed as WebParts.
• Elements from Designer can be exported to a WSP and imported into Visual Studio. Yeah…I can finally endorse SharePoint Designer.
  • You can export a site in SharePoint Designer by choosing an option to save it as a template. This creates a WSP file.
  • You can import that WSP file into Visual Studio. When you do this, Visual Studio gives you a UI to let you choose the elements from the WSP to import. For example: you can choose to import just a list.
  • The import functionality of the WSP creates a new project in your Visual Studio solution with features and everything
• SharePoint Designer has site Workflows. These are Workflows that aren’t bound to a list. Why is this great… because we can finally export Workflows out of SharePoint Designer and into Visual Studio. Yes, we have deployable Workflows from SharePoint Designer – finally!
• You can create Workflow Wireframes in Visio and import/export them from SharePoint Designer. This gives a development path from inception to delivery for Workflows. Design it in Visio, hook it into SharePoint and tweak it in SharePoint Designer, code against it in Visual Studio.
• Developer Dashboard – this is a view, on the actual page, that is useful for Developers. Think of an output window from Visual Studio sitting on your WebPage (but with more information). 
  • Shows Database query times for everything going on in a page
  • Shows Call Stacks
  • Gives info about the page
  • Shows load times
  • This is turned off by default. You need to turn it on in stsadm or PowerShell
• Around 500 commands were created for PowerShell
• External Content Types – this allows us to hook up external data into a SharePoint list for read/write operations
  • We build Business Connectivity Services that have methods on them that allow us to work with external data. Kind of like a Data Layer.
  • We can bind the Business Connectivity Services to a list through the External Content type.
  • Now we can read and update data, from a SharePoint list, directly to anything (especially our database).
• Linq to SharePoint
  • This allows us to access SharePoint list data through Linq.
  • This creates a proxy, just like Linq to Sql, to work with the data.
• They’ve really improved lists and list performance
  • List can hold over a million items
  • Items in lists can be filtered by the metadata. Oh yeah, did I mention everything gets tagged now with Keywords. So, that is the metadata that you can filter your lists by easily.
  • You can configure list throttling to only show a certain amount of items at a time (because a webpage can’t show a million items at once).
  • Lists have cascading deletes and disabled deletes! Cascading deletes are great for Lookup lists. Finally, a little bit of integrity between our lists.
  • Lists also have Excel like validation. We can put validation on a lists through Excel like calculations.
• The Wiki functionality is used heavily on pages now. While you can still have WebPart pages, they should become more sparsely used now.
  • Pages have content fields on them which are Wiki based.
  • You can add WebParts in these content fields. For example: I could have one line of content, a WebPart and then a paragraph. They said they dynamically add the WebPart zone now in these content fields.
• Theres a bunch of Client OM functionality.
  • Context model to open a site client side – very useful for Silverlight and/or Ajax programming.
  • REST API – utilizing another one of my favorite Micrsoft products – ADO.Net Data Services. Yes, we can expose our SharePoint data over REST!
• Sandbox solutions – this is a new deployment methodology for WSPs
  • First, to understand this, you have to understand that there are two models of SharePoint
    • Self Hosted – this is what we are use to. Having our servers in-house
    • Online – this is the new hosting (cloud) model for SharePoint
  • Sandbox solutions allow us to upload WSPs, inside our site, to deploy them. While this can be useful in Self Hosted or Online, it is the only way to deploy WSPs in an Online model.
  • When you create your Visual Studio solution you can pick “farm” or “sandbox” for the type of solution. This can be changed later, but they said there can be complications trying to change this after the solution is created (but it sounds like those complications are rare).
  • Sandbox solutions have less functionality (but they said it has most of the functionality we are use to).
  • Sandbox solutions rely heavily on CAS. So, if you are writing code that goes against the CAS policies, you can’t use Sandbox solutions. This seems to be a security measure so that you can deploy code in the Online model. This also seems to be the main reason to not use Sandbox solutions unless you need to.
  • Sandbox solutions also have internal controls to keep from deploying bad code. One they showed is an error message when code takes too long to execute (i.e.: trying to determine infinite loops)
  • Sandbox solutions are deployed differently than regular solutions. They were a little vague on this. But, it sounds like you upload the WSP to a solution’s gallery on the site. Then, when something in the solution gets used for the first time the solution gets deployed. I think it is intended to be a seamless deployment (i.e.: it shouldn’t affect the user’s experience – no downtime for deployment).
• Upgrade Path – you have the choice to keep the SharePoint 2007 look or go right to the 2010 functionality and look. You can also preview what your site will look like if you choose to go to the 2010 look. Upgrades should be a lot easier now and less error prone.

So, lots of great stuff. I got a little overloaded with information today, they really revamped the product and I think it is for the better. I’ll write another blog if I learn some more new things while I am here.

MOSS Project Tasks Gantt Chart size issue in Firefox

When you use a Gantt Chart web part, from the project tasks list in MOSS, you get a scroll bar at the bottom so that it fits in the screen (in Internet Explorer). This is done with a div tag and an overflow style of auto in the ms-ganttDiv of the core.css file in SharePoint.

However, in any other browser (other than IE), you don’t get the scroll bar. Instead, the Gantt Chart is set to the full width and your browser page becomes very wide.

This happens because SharePoint uses a different style for browsers other than IE. For other browsers ms-ganttDiv is replaced with ms-ganttDivNonIE. So, using my trusty developer toolbar in IE and Firebug in Firefox, I decided to check out these two styles.

The difference between the two is the “position” property. In IE, the position is set to absolute. In the other browsers, the position is set to inherit.

So, I decided to switch the position to absolute in Firefox to see what happens. And, of course, it looked horrible (I knew the SharePoint developers did this for a reason).  It makes the Gantt Chart overflow over the size of the webpart.

I tried playing around with different css settings to see if I could fix this. But, I think I found the same thing the SharePoint developers found, it is very hard to fix this issue in non-IE browsers (no wonder they hacked this up).

Thus, my conclusion is to make this a fix width Gantt Chart. All I did was set my WebPart to fixed width (instead of 100% height). Then I added a css style to my site to set the width of the ms-ganttDivNotIE.

.ms-ganttDivNotIE{ width:800px; }

Note: making the WebPart width the same size as the .ms-ganttDivNotIE is important. If you don’t do this, the user could see space between the end of the Gantt Chart and the border of the WebPart.

It’s not the perfect solution, but it makes the site act consistent in Firefox and IE (that was my requirement).

Inheriting Themes for SharePoint publishing sites

SharePoint themes do not inherit when creating a site/sub-site structure. Try it, set a theme to the root site in your site collection, set the theme to something other than the default, then create a sub-site under that site. Notice that this sub-site automatically gets set to the default theme again. Now your users have a different design experience as they navigate through your site. That might be ok if you are creating different team sites, but it doesn’t create a cohesive experience when building a portal structure. Of course, you can always set the theme every time you create a sub-site, but wouldn’t it be nice if you didn’t have to do that (especially if you have an environment where less experienced SharePoint administrators are adding sub-sites).

I’ve never  been a big fan of themes in the past. I usually create my own css and put it in the layouts folder and access it in the master page. But, that is only when I have time to customize my site. Every once in a while I have to put a quick SharePoint site together using out-of-the-box functionality and I need to use the out-of-the-box themes to give a distinct look to a particular site collection.

The following technique shows a way to gain that theme inheritance behavior for SharePoint publishing sites.

Note: The following directions are for MOSS publishing sites because you can set the alternate css in MOSS through the interface. In addition, you must make sure that all of your sub-sites are set to inherit the alternate css.  And lastly, you must have the publishing features turned on. Of course, all these settings are set by default when you use one of the publishing templates to create your site and sub-sites. It works really nice with the Collaboration Portal template for the site collection and the Publishing Site templates for the sub-sites.

• Set the theme you want to on the home page of your site collection (Site Settings – Look and Feel – Site Theme – Choose a theme)
• Go to the site collection home page and view the source (right-click on the page in your browser and choose view source)
• Do a search for the word _themes and copy the link from the href tag. For example: a tag on my site looks like this – <link rel=”stylesheet” type=”text/css” id=”onetidThemeCSS” href=”/_themes/Jet/Jet1011-65001.css?rev=12%2E0%2E0%2E6421″/>. I copied: /_themes/Jet/Jet1011-65001.css?rev=12%2E0%2E0%2E6421
• Go to the master page settings of your site collection (Site Settings – Look and Feel – Master page)
• Check the radio button to “Specify a CSS file to be used by this publishing site and all sites that inherit from it”
• Paste the link we copied previously into the text box
• Check the checkbox “Reset all subsites to inherit this alternate CSS URL” if you already have subsites created in your site collection.
• Click OK

Note: If these steps do not work, there is a posibility you do not have the alternate css inhertence setup on your sites. Or, it might mean that you are creating a non-publishing site (like a team site) off of your publishing site collection. Also, if you don’t see some of the links I mentioned in the steps, then that means you either do not have MOSS or you don’t have the publishing features turned on.

Why does this work

SharePoint dynamically creates a _theme folder for a site when you set the theme. Then it associates the theme, through a stylesheet link, in a tag on the sites page. For more information on this process please visit Heather Solomons blog.

The problem is, SharePoint only creates the stylesheet link in the particular site you create the theme at.

Thus, this technique takes advantage of the fact that if you create the theme at the top level site, you can access it through relative paths from any sub-site. So, by creating the theme at the top level site, it will create that _themes folder at that level. Then, luckily, the alternate CSS does inherit through all the sub-sites in SharePoint. So, we can just use a simple relative path, in the alternate CSS, to inherit the theme down through our sub-sites.

Caveat: This is a “no-code” solution for a particular situation (MOSS Publishing Sites). For production systems I always like to do my customizations through solutions, features, custom master pages and custom css. If you don’t have the environment described in this post (MOSS Publishing), then you might have to use other techniques – such as a full customization technique with a solution or by setting the css through designer: Heather Solomons post on CSS Options with Master Pages

Presenting at SUGDC annual users conference

I am speaking at the SUGDC annual users conference on June 27th. It should be a good event with a lot of good speakers!

My presentation isn’t on my usual development topics. I am switching it up this time and presenting on the administrative/setup track. My topic is on using Site Collections vs Sites in SharePoint. Yes, I know it doesn’t sound interesting, but I promise I will try to keep everyone interested. I do feel it is one of the most important topics to understand in SharePoint. Almost all the issues I see when I go into my clients stem from an incorrect topology and permission setup. We will cover these situations with a fictitious company walk-through to see how they messed up, what they can do to correct their mistakes and what considerations they need to make.

Below is more information on the conference as a whole:

The SharePoint Users Group of Washington D.C.’s  (SUGDC) Third Annual Regional SharePoint Users Conference is taking place at the Holiday Inn Dulles June 26-27.  With over 40 speakers (including keynoter Bob Mixon), 15 SharePoint software, consulting and resource exhibitors, and four thematic tracks appealing to experts and non-experts alike, this year’s conference is shaping up to be an exciting event!  Anyone interested can check out the conference agenda, and pre-register at the extended early bird rate of $299.

Developing SharePoint WebParts using User Controls and Web Applications

If you’ve read my blogs before, then you probably know I am a fan of WSPBuilder (http://www.codeplex.com/wspbuilder). I like the intuitive nature and flexibility of the product. It really helps with the deployment aspects of SharePoint features and functionality. However, in the end, it is really just a structured way to create a deployment/feature project that will create the wsp install file for SharePoint. It really doesn’t help much when building UI functionality. For example: if you want to build a Web Part in SharePoint, you still have to build the Web Part code out programmatically (instead of using the WYSIWYG features of Visual Studio). The same issue comes up with building master pages, application pages or anything that requires html and a code behind.

In this article I am going to show you how you can utilize the flexible nature of WSPBuilder, ASP.Net Web Applications and post build scripts in order to utilize WSPBuilder as your deployment project for your UI. 

Solution Overview

SharePoint is a dynamically generated website that pulls information out of a database. It also utilizes files on the server and uses those files as templates or actionable files. The combination of these static files on the server and the information in the database creates the web page we see. This architecture is what allows us to create pages, add webparts, modify navigation, etc… all within the SharePoint site itself.

So, when developing against SharePoint, we need to deploy files to this static place on the server and register the files in the database. This static place on the server is called the 12 hive. It is usually found at: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12. A lot of stuff goes on in the 12 hive. You have the templates for the website, images, themes, etc… You also have very special items called Features. Features allow us to deploy custom functions to SharePoint and then activate/deactivate them at our leisure.

WSPBuilder allows us to “mimic” the 12 hive, within a Visual Studio project. As long as you have the same 12 hive structure setup, it can create the SharePoint deployment file (i.e.: the wsp). You do not need WSPBuilder to create wsp files; you can do the same thing by building extra files in your solution called manifest.xml and ddf files. However, for rapid application development, it is easier to use a third party solution like WSPBuilder because it creates those extra deployment files for you.

While WSPBuilder is a great tool to help us build the deployment files, it is not a web application project in Visual Studio. Web application projects help us build code behind and designer files for our server side controls.

Thus, the ideal solution for building UI elements in SharePoint consists of:

1. ASP.Net Web Application project to build the UI elements
2. WSPBuilder project to create our deployable wsp file

The ASP.Net Web Application project will contain the UI elements (such as User Controls). The build process will move the appropriate elements from the ASP.Net Web Application project to the WSPBuilder deployment project. Then the deploy will move the files from the wsp to the SharePoint Server.

The key to this solution is seperation of concerns. You should build all UI related functionality in the ASP.Net Web Application project. All SharePoint specific functionality (ex: features), should be built in the WSPBuilder project.

 

Create the WSPBuilder deployment project

1. Create your project in Visual Studio (File – New – Project)
   • Choose the WSPBuilder project. I am utilizing the one under c# for this example.
   • Give it a good name. I am using DemoProject for this example.
   • Make sure it creates a new solution when creating the project.
2. Add a folder under the 12 folder called “Template”.
3. Add a folder under the Template folder called “LAYOUTS”.
4. Add a folder under the Template folder called “FEATURES”.
5. Add a folder under the Template folder called “CONTROLTEMPLATES”.
6. Add a folder under the project called “GAC”.

Note: The “GAC” folder in WSPBuilder is a special folder. We can place external dlls in this folder the the resulting WSP will deploy those dlls to the GAC for us.

 

Create the UI project

As I mentioned in the beginning of this article, the point is to create our UI elements in an ASP.Net Web Application project. So, we need to create another project, in the same solution, so that we can develop our UI elements.

1. Create the UI project (File – Add – New Project)
   • Choose the ASP.NET Web Application Template. I am utilizing the one under c# for this example.
   • Give it a good name. I am using DemoProjectUI for this example.
2. Delete the Default.aspx
3. Sign the project (this is because we are going to deploy to the GAC)
   • Go to the properties (right-click the project and choose properties).
   • Go to the Signing tab.
   • Choose “Sign the assembly”.
   • Under the “Choose a strong name key file” – choose <New>
     • Give it a strong name – I usually use the name of my project (for example: DemoProjectUI).
     • Uncheck “Protect my key with a password”.
4. Add in the post build commands
   • Go to the properties (right-click the project and choose properties).
   • Go to the Build Events tab.
   • Add the following into the post build section:
xcopy "$(TargetPath)" "$(SolutionDir)DemoProject\GAC\" /Y /s
xcopy "$(ProjectDir)*.ascx" "$(SolutionDir)DemoProject\12\TEMPLATE\CONTROLTEMPLATES\" /s /Y /R


Let’s recap what we did in the steps above. First we created a WSPBuilder project called DemoProject. This is our deployment project. It will create wsp files that we can deploy to SharePoint. Then we created an ASP.Net Web Application project called DemoProjectUI. This is where we will create all our UI elements. This will allow us to create user controls with html and code behind files. Lastly, we made sure that we moved the dll and ascx files, from the DemoProjectUI project, to the appropriate place in the DemoProject project.

 

Create a Web Part

Our next step is to create a Web Part. As anyone who has developed in SharePoint before knows, Web Parts are complete code files. They are not the html with code behind files we are used to when developing in ASP.Net. Some people are fine with developing Web Parts completely programmatically. However, it is much easier to create UI elements when you have WYSIWYG editors, html and code behind.

One way to get the normal ASP.Net web development experience, when developing Web Parts, is to use the SmartPart. The SmartPart is a very clever Web Part, developed by Jan Tielens, which can render .Net user controls in Web Parts. I really like the SmartPart, especially for people learning to build SharePoint Web Parts as user controls. However, I like more control over what I do and there are some limitations to the SmartPart. It is not my intent to go over those limitations in this article, but you can read them here: http://weblogs.asp.net/erobillard/archive/2008/03/04/what-to-know-about-smartpart-and-loadcontrol.aspx

In the end, you can accomplish the same thing as the SmartPart using the “LoadControl” method in .Net. Thus, this article will show how to create a Web Part, which will load the user control from our UI project.

1. Create the Web Part using WSPBuilder
   • Right-click on the DemoProject project
   • Go to Add – New Item
   • Choose WSPBuilder – Web Part Feature
   • Give it a good name. For this example I am going to use DemoFeature
   • A popup will come up with Title, Description and Scope. Since we are developing a Web Part, you must choose “Site” for the scope. This is because we need the Web Part to deploy to the Web Part gallery of our Site Collection.

   Notice that WSPBuilder did two things for you:
   - It created the feature in the features folder
   - It created the Web Part code in a folder called WebPartCode

2. Modify the Web Part code to use “LoadControl”
   • Open up the DemoFeature.cs file in the WebPartCode folder
   • Remove the MyProperty property and attribute for now. This is just WSPBuilder showing you how you can use properties. We aren’t going to use them for this demo.
   • Find the CreateChildControls method and find the comment that says “Your code here…”
     • Remove the line under it.
     • Replace it with this: this.Controls.Add(Page.LoadControl("~/_controltemplates/DemoControl.ascx"));

     Your CreateChildControls method should look like this:
     protected override void CreateChildControls()
{
    if (!_error)
    {
       try
       {
          base.CreateChildControls();
          this.Controls.Add(Page.LoadControl("~/_controltemplates/DemoControl.ascx"));
       }
       catch (Exception ex)
       {
         HandleException(ex);
       }
    }
}


3. Add the control to the UI project
   • Right-click on the DemoProjectUI project
   • Go to Add – New Item
   • Choose Web – Web User Control
   • Give it a good name. For this example I am going to use DemoControl.ascx

Now, when you build your solution, the DemoControl.ascx will move to the ControlTemplates folder in the DemoProject project. The SharePoint Web Part will look for the control by using the _controltemplates path.

Note: SharePoint can find any control in the ControlTemplates folder by using the _controltemplates path because of a mapping it creates in IIS. SharePoint maps the _controltemplates path to the servers 12 hive at 12/Template/ControlTemplates.

 

Utilizing the Code Behind

We now have our basic solution setup. We have our UI project and can build our user control there. We have our WSPBuilder deployment project that will create our SharePoint install file. But, we aren’t ready to deploy just yet. We still need to tell our user control how to talk to its code behind. Because we are utilizing the GAC for our assemblies, we need to put a fully qualified domain in our ascx file. There are a couple of techniques for figuring out this fully qualified domain. What I like to do is deploy the project and go to the GAC to get the properties.

1. Deploy the WSP, so that the assembly gets added to the GAC, so that we can pull out the assembly information.
   • Right-click on the DemoProject project
   • Click WSPBuilder – Build WSP (wait for it to finish)
   • Right-click on the DemoProject project
   • Click WSPBuilder – Deploy WSP (wait for it to finish)
   • Get the assembly information from the GAC
     • Usually found at C:\Windows\assembly
     • Right-click on the DemoProjectUI assembly and click properties
     • Note the public key token and version ( I suggest copying the public key token at this point because we are going to use this information in the next step).
2. Add the assembly information to the ascx
   • Go to the DemoControl.ascx file in the DemoProjectUI project
   • Add an Assembly reference as the first line in this file. Below is an example. However, you cannot copy this example. Your assembly reference must have the correct information about your assembly (including your public key information).


<%@ Assembly Name="DemoProjectUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=772ab5f02712b819"%>


 Now we are ready to test our solution!

 

Deploy the Solution

Now that we are finished setting everything up, we can deploy the solution. This is real easy with the use of WSPBuilder as long as we are developing on a SharePoint server.

Note: Please make sure you have a web application and site collection setup in SharePoint before doing the following steps. When you deploy the WSP solution, it will deploy to all web applications on your development server. Thus, the web application must exist before you deploy.

1. Right-click the DemoProject project
2. Click WSPBuilder – Build WSP (wait for it to finish)
3. Right-click on the DemoProject project
4. Click WSPBuilder – Deploy WSP (wait for it to finish)
5. Open up your SharePoint site.

Note: if you go to the SharePoint site at this point and it says “Server Not Available”, then just keep refreshing the page until it shows up. The WSP install recycled the application pools because it needs to every time a dll in the GAC is added or modified. It sometimes takes a few seconds for this process to finish.

6. Go to Site Actions – Site Settings
7. Go to Site Collection Features
8. Activate the DemoFeature
9. Go back to the site
10. Go to Site Actions – Edit Page
11. Click “Add a Web Part” in one of your web zones
12. Find your WebPart. It should be under “MyGroup” unless you changed the group name in your feature. The elements.xml file in the feature folder of the DemoProject lets you configure this information. I
13. Add your Web Part to the page

At this point your Web Part is empty because we didn’t add any html or code to it. However, you solutions architecture is ready to go. Now you can go back to your User Control, do your development, deploy the solution and it will show up on your page. Let’s give it a try.

1. Go to the DemoProjectUI project
2. Open the DemoControl.ascx
3. Put a label tag on the control

<asp:Label runat="server"  ID="test" />

4. Go to the code behind (i.e.: DemoControl.ascx.cs)
5. In the Page_Load type the following
protected void Page_Load(object sender, EventArgs e)
 {
      test.Text = "Hello World";
 }

6. Right-click the DemoProject project
7. Click WSPBuilder – Build WSP (wait for it to finish)
8. Right-click on the DemoProject project
9. Click WSPBuilder – Deploy WSP (wait for it to finish)
10. Open your SharePoint site and see your Web Part. It should say “Hello World”.

Remember: if it says “Server Not Available”, then keep refreshing the page until the site shows up again.

Wow, that was a lot of setup just to create a user control that can render in a Web Part. But, the great thing is, you only have to do the setup once. As a SharePoint Architect, I set this up for my team and they can just concentrate on building the user controls. It runs very smooth!

Per popular demand, here is the demo solution from the walkthrough. I used Visual Studio 2008, WSPBuilder Extenstions 1.0.5 and .net 2.0 for this solution (I used 2.0 so it can work for a client of mine, it can be upgraded to 3.5 easily)
DemoProject

‘IsReference’ property specified was not found

The other day I got an error message that said “’IsReference’ property specified was not found”. I started doing some research on it and most people were referring to WCF. The interesting thing in my case was:
1. I wasn’t using WCF
2. This wasn’t happening on the development environment. It only happened when we moved to staging.

So, I had to start figuring out what was going on. I narrowed the issue down to DataContractSerialization. Basically, the situation I was dealing with was that I was serializing Linq to Sql objects. If you have worked with Linq to Sql before, you would know that they are not easily serialized. In fact, they are not marked with the serializable attribute. Instead, they are marked with the Data Contract attribute. So, if you want to serialize them for any reason (my reason was that I wanted to store them in Session), then you have to use the DataContractSerializer to do the serialization. The DataContractSerializer was introduced for WCF – thus the reason why most of the references I saw about this error were talking about WCF.

So, now that I narrowed the issue down to my serialization, I had to figure out what was happening. I noticed that my Linq to Sql objects were marked with the Data Contract attribute and a property called “IsReferenced”. Ok, now I know this marking is causing the issue. But, why was this issue working in my environment and not staging.

Well, the answer ended up being the version of .net. I was told that the staging servers were upgraded to .net 3.5 sp1. However, when I looked closely, I noticed that one of the front end servers (in our case there were many front end servers) was only .net 3.5. That’s what I get trusting IT guys, I have to double check everything they do .

It turns out that even though the DataContractSerializer was around in the .net 3.5, the marking of “IsReference” wasn’t introduced until .net 3.5 sp1. So, if you get this error, you might want to check out your version of .net before starting to debug.