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.

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.

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.

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).

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

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.

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

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.

Deploying webparts in SharePoint can be difficult (when you are learning) because of the many ways to do it. You can manually add webparts to the WebPart gallery, you can add WebParts through features and you can even manually add them to certain file system folders.

If you have developed extensively in SharePoint, you probably choose the feature way to deploy WebParts. I am not going to go into this conversation right now, but it is well known that the best practice for building webparts is to deploy them with features. However, one thing that nobody really talks about is removing the WebPart from the WebPart Gallery. If a WebPart is placed in the WebPart gallery when the feature is activated, shouldn’t it be removed from the WebPart gallery when the feature is de-activated? In this article we are going to go over the basics of how WebParts are added to the WebPart gallery during activation of the feature and then we are going to show how you can clean up your gallery when the feature is deactivated.

Overview of WebParts and Features

The premise of WebParts is simple – you are adding an xml file to a special list in SharePoint. This special list is called the Web Part Gallery and the xml file you add is called a .webpart file or a .dwp file. The .webpart or .dwp file “describes” the properties of the WebPart and points to a code file where the .net code runs that builds the WebPart controls. If you want to visit this special WebPart Gallery you can go to your SharePoint site and put “/_catalogs/wp” after your url (i.e.: http://server:port/_catalogs/wp). If I have already confused you at this point, you probably want to start looking into some beginner guides to WebParts in SharePoint. I will do a small overview of WebParts in this article (that might be helpful for beginners), but the point of this article is to show some advanced techniques to how to clean up your WebPart Gallery.

When deploying webparts in SharePoint I always use a Feature to deploy the WebPart to the WebPart gallery. Then I always wrap these features up in a WSP solution in order to deploy a single solution to my SharePoint farm. This is best practice and is really easy once you have done it a couple of times. Personally, I choose to use WSPBuilder to build my WSP solutions (but the process is the same if you use Visual Studio Extensions or if you build your WSPs manually).

If you are using WSPBuilder you can just click Add – New Item – WSPBuilder – WebPart Feature. This will create a .webpart file, feature.xml, element.xml  and code file for you. And, I choose “Site” scope so that the WebPart is added to my Site Collection WebPart Gallery. If you don’t use WSPBuilder, the process is the same, you still have to build the .webpart file, feature.xml, element file and code file (WSPBuilder just does it for you).

So, let’s talk about what these files do:

1.       Feature.xml – this file defines “how” the feature will get deployed and the general settings for the feature. Technically, this is the only file required for a feature to work.

The important part of this file is the “Scope”. The scope defines where the feature will be deployed (Site, Web, Web Application, Farm). For webparts, we usually choose “Site” in order for the WebPart to be added to the WebPart Gallery. The other important part of this file is the “ElementManifest”. This tells the feature where the element file is located. The element file is the actually actionable file in a feature.

<?xml version=“1.0“ encoding=“utf-8“?>

<Feature  Id=“7801227a-326a-4a65-8769-6e56ade76b66“

          Title=“Custom Webpart“

          Description=“This is my custom webpart Webpart“

          Version=“12.0.0.0“

          Hidden=“FALSE“

          Scope=“Site“

          DefaultResourceFile=“core“

          xmlns=“http://schemas.microsoft.com/sharepoint/“ >

  <ElementManifests>

    <ElementManifest Location=“elements.xml“/>  

  </ElementManifests>

</Feature>

2.       Elements file – usually we call this file elements.xml, but you can call it whatever you want. You just need to make sure it is an xml file and you need to make sure that the name you call it is the same as the reference in the feature.xml.

This file tells SharePoint “what” to do with the feature. There are a lot of different things you can do with SharePoint Features. So, you have to do your research to understand the different xml combinations. In the case of the WebPart, we are using a “Module” action. Module actions move files to different galleries (or lists) in SharePoint. With webparts, we want to move the .webpart gallery to the WebPart gallery list. We do this by setting the “url” property to the “_catalogs/wp” path. That is the path for the WebPart gallery list. The other thing to notice in this file is the “Group” and “QuickAddGroups”. These define the grouping when you click “Add New Webpart” on your SharePoint site.

<?xml version=“1.0“ encoding=“utf-8“ ?>

<Elements xmlns=“http://schemas.microsoft.com/sharepoint/“>

  <Module Name=“WebPartPopulation“ Url=“_catalogs/wp“ RootWebOnly=“TRUE“>  

         <File Url=“CustomWebpart.webpart“ Type=“GhostableInLibrary“>

                <Property Name=“Group“ Value=“RDA“></Property>

                <Property Name=“QuickAddGroups“ Value=“RDA“ />

         </File>    

  </Module>

</Elements>

3.        .webpart file – this is the file that “describes” the properties of the WebPart. This could also be a .dwp file (it all depends on the version of the WebPart you are using). SharePoint supports .net webparts and SharePoint webparts. That is why you can have .dwp and .webpart files. So, any property you can set in your WebPart, can be set in this file. I am not going to show an example here because the set of properties is different for every WebPart.

This file also contains the assembly path to the code file. This is important, because if you ever change information about the Code file (name, version, etc…), then you need to change the path in your .webpart file.

4.       Code file – this is the file that actually runs the webpart code. These files inherit from one of two classes depending on the version of WebPart you are building (.net webpart or SharePoint webpart). For example, a .net framework webpart will inherit from Microsoft.SharePoint.WebPartPages.WebPart. Once again, I am not going to show an example of this, because it is different for every customization. The basis of this class is that you build out your html controls programmatically and add them to the Control collection.

Side Note: On a side note that is not really part of this article, don’t think the SharePoint webpart (i.e.: dwp) is better to use than the .net webpart (i.e.: .webpart) just because one is labeled a SharePoint webpart. If you don’t plan on using SharePoint webpart connections or part caching, I actually recommend using a .net webpart in SharePoint. Also, you might hear .dwp webparts referred to as Version 2 webparts and .webparts referred to as Version 3 webparts. This is because .dwp webparts were originally built just for SharePoint 2.0 and are backwards compatible. But, in SharePoint 3.0 we got the ability to use the asp.net webparts.

Cleaning up your WebPart Gallery

Ok, so you know how to deploy a WebPart to the WebPart Gallery. But, you notice that when you de-activate your Feature the WebPart is still hanging around in the Gallery. Some developers don’t really care about this. But, other than the obvious problem of keeping a clean Gallery for maintaince, there is another big issue. Let’s say you are using versioning for your assembly for the WebPart code. The reference for the assembly is located in the .webpart file. Thus, if you don’t remove the WebPart from the gallery before you make version changes, then your new assembly version will never make it to the gallery.

So, the easiest way to do this is to just go to the WebPart Gallery and remove it before you install and activate your updated feature. However, as most SharePoint developers know, you want to stay away from manual processes as much as possible. That makes your customizations almost impossible to maintain as your code base grows.

But, the answer to this problem is easy. Create a feature receiver to remove the webpart from the WebPart Gallery when the feature deactivates. I saw this done for the first time when I was reviewing the code for the Forms Based Authentication project in the Community Toolkit for SharePoint:  http://www.codeplex.com/CKS. I modified the code a little to meet my needs, but it is basically the same. Here is how you do it.

Create a Generic Class

This class is a generic class that will work for any WebPart feature receiver. The idea behind this class is to implement the Feature Deactivating event and remove the WebPart. Here is the code for this class:

     class GenericWebPartFeatureReceiver : SPFeatureReceiver

    {

        /// <summary>

        /// Remove the webpart from the webpart gallery. This is to fix a shortcoming of SharePoint

       ///       that it doesn’t remove

        /// the webpart when the feature gets deactivated (even though it adds it when the feature

       ///       gets activated).

        /// </summary>

        /// <param name=”properties”></param>

        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)

        {

            SPSite site = null;

            try

            {

                site = properties.Feature.Parent as SPSite;

                using (SPWeb web = site.RootWeb)

                {

                    SPList list = web.Lists["Web Part Gallery"];

                    // go through the items in reverse

                    for (int i = list.ItemCount – 1; i >= 0; i–)

                    {

                        // format name to look like a feature name

                        string webpartName = list.Items[i].Name;

                        webpartName = webpartName.Substring(0, webpartName.IndexOf(‘.’));

                        // delete web parts that have been added

                        if (properties.Feature.Definition.DisplayName == webpartName)

                        {

                            list.Items[i].Delete();

                            break;

                        }

                    }

                }

            }         

            finally

            {

                if (site != null)

                    site.Dispose();

            }

        }

        public override void FeatureActivated(SPFeatureReceiverProperties properties){ }

        public override void FeatureInstalled(SPFeatureReceiverProperties properties){ }

        public override void FeatureUninstalling(SPFeatureReceiverProperties properties) { }

    }

Call Feature Receiver

After your Generic Feature Receiver is built, then you just need to call it from the feature.xml file for all your WebParts. Here is some sample code. It is the same as the feature.xml file I showed above, except for the fact that I placed a reference to a RecieverAssembly and a ReceiverClass.

<?xml version=“1.0“ encoding=“utf-8“?>

<Feature  Id=“7801227a-326a-4a65-8769-6e56ade76b66“

          Title=“Custom Webpart“

          Description=“This is my custom webpart Webpart“

          Version=“12.0.0.0“

          Hidden=“FALSE“

          Scope=“Site“

          DefaultResourceFile=“core“

          xmlns=“http://schemas.microsoft.com/sharepoint/“

   ReceiverAssembly=“MySolution, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3cbe19ecf7353dae“

   ReceiverClass=“MySolution.GenericWebPartFeatureReceiver“>

  <ElementManifests>

    <ElementManifest Location=“elements.xml“/>  

  </ElementManifests>

</Feature>

Note: You cannot just copy the xml above. The reference to the features ReceiverAssembly and ReceiverClass is specific to my implementation. When you deploy the assembly that contains the “GenericWebPartFeatureReceiver” to your BIN or GAC, then you need to get the information necessary to build out these two lines. Make sure the name of the Assembly and Namespaces match your implementation. And, make sure that the PublicKeyToken matches your public key for your assembly.

That’s it; you now have a Generic WebPart Feature Receiver that will remove the WebPart from the WebPart Gallery whenever your WebPart Feature is deactivated. This should help you keep your gallery clean and will help eliminate possible issues with assembly versioning.

This is the second part of a two part series on Linq to Sql and the Entity Framework. In the first part we talked about the two different frameworks. Specifically we talked about detached objects. This part of the series will discuss the options to re-attach objects. We will be discussing this in terms of Linq to Sql. However, the “ideas” will work for the Entity Framework also.

How do I Re-attach my objects?

During my research I found 3 different techniques for re-attaching objects. Each of these techniques has pros and cons, so I will attempt to explain each one. I will be explaining these techniques in terms of Linq to Sql. However, the architectural decisions are the same with Linq to Sql or the Entity Framework.

Technique 1: Re-Query

The re-query technique is basically re-querying the database in your save routine. The reason to use this is to get the “original” values back before you save. However, there are some serious downsides to this technique.

Here is an example of this technique in action. Let’s say we have already done our retrieve and then hit the save button on our asp.net application. A postback ran and we filled in an “Employee” object. Now we have to attach that employee object to our context to save. However, if we just attach it, then the framework will always thing the object is “New”. So, we will re-query to get the original values so the framework knows we are doing an update.

//Instantiate a context to do our save

MyDataContext saveContext = new MyDataContext();

//Run a query to get the “original” objects

MyDataContext origContext = new MyDataContext();

Employee origEmp = origContext.Employees.Single(e => e.EmployeeID == 1);

//Attach the new employee object to the save context and pass in the original context

//so it can do concurrency checking

saveContext.Employees.Attach(newEmp, origEmp);

saveContext.SubmitChanges();

The above technique will seem like it works. However it has two issues:

1.       Performance – there is no need to run that extra retrieve when saving

2.       Concurrency – this is not really checking concurrency, it is doing a fake check

Let me explain a little more why this is doing a fake check. Let’s take an example of two users in a system. This system has a status field and the users really need to know the current status when they are changing data because another user might have already made the changes that they wanted to make for this particular status.

1.       User 1 retrieves the data

2.       User 2 retrieves the data

3.       User 2 updates the data

4.       User 1 updates the data

That is a concurrency issue on step 4. When User 1 updates the data, they should know that someone else slipped in an updated the data before them and they never saw that updated data. Well, in the above approach where you query the data in the save logic, just to get the original values, you are not really solving the underlying problem. Because User 1 just retrieved User 2’s data when they were saving and never saw the changed data. Concurrency checks will all pass and User 1 will never know there was an issue.

So, I don’t ever recommend this technique if concurrency is something you need in your system.

Technique 2: Session

Using session to store your objects across PostBacks is a valid technique to keep original data around. The basic steps are to retrieve the data in load, set that data to session, run the save PostBack, get the data out of session and reset the fields with the data from your user controls.

This sounds easy, but there are many considerations when using this technique.

Consideration 1

Session can hurt performance of a server and eat up resources. You have to be very careful when using Session on an asp.net application. If your objects are too large, then you don’t want to store them in session. Also, if you have many users accessing the system at the same time, session can become an issue. So, weigh in the normal architectural decisions of using Session when validating this approach.

Consideration 2

You have now disconnected the original object and want to re-attach it to the context. Don’t you lose all “state” information (i.e.: new, modified, deleted, etc…)? Well, yes, you do. But, this is where that Code Plex project I mentioned earlier comes in to play http://www.codeplex.com/LINQ2SQLEB. This keeps the state and original values in the base class for the objects, instead of just keeping them in the context. And, it reattaches the objects to a new context and sets all this information. Thus, I can serialize my objects, reattach them to my data context and still have my original values and state around for optimistic concurrency checks.

Consideration 3

Linq to Sql objects are not marked as Serializable. Thus, they can’t just be set into session easily. However, the Entity Framework objects are marked that way, so this is only an issue with Linq to Sql.  Luckily, there is a trick to this. Linq to Sql does support DataContracts. Thus, you can use the DataContactSerializer to store Linq to Sql objects in session http://www.squaredroot.com/post/2008/01/30/Storing-LINQ-Objects-in-SQL-Based-Session-State.aspx

This technique was the approach I picked for my last project. We had other architectural decisions in which we were storing objects in session anyways, so it seemed like a perfect fit. And, because of this technique, and the base class I found (LINQ2SQLEB) is the only reason I picked Linq to Sql over the Entity Framework. If there was something available like this for the Entity Framework, I would use it in a second. Hum, maybe I will create something like that.

Note on Technique 2

Be careful with this technique and the concurrency checking mechanism of Linq to Sql. When you re-attach your object, to do an update, here is what the update statement will look like:

@originalValue1 = 02/11/2009 12:33:31 PM

@originalValue2=”testing”

@newValue1 = 02/13/2009 12:33:31 PM

@newValue2=”test”

UPDATE [MyTable]

SET [lastUpdatedTime] = @newValue1, [field1] = @newValue2

WHERE ([lastUpdatedTime] = @originalValue) AND ([field1] = @originalValue2)

This is fine and the update statement will do optimistic concurrency perfectly. However, there is a performance consideration here. The update statement builds a check on every field in the “Where” clause. This can make a bloated sql statement when you are updating lots of fields. If you want to clean up these sql statements, here is my suggestion. Add a field to your table in the database that always changes, I recommend a timestamp field in sql server. Then, go to your Linq to Sql designer and turn the concurrency check from “Always” to “Never” on all your fields except this timestamp field. This way, the timestamp field is the only field that will be checked in the “Where” clause. You will still have the same optimistic concurrency and a much quicker update statement.

Technique 3 – Manually attaching with timestamp

The last technique I want to explain is how to manually attach an object with a timestamp field. In this technique we retrieve our data in the load, set a timestamp field to ViewState, run the save on PostBack and use that timestamp field to set the original values.

The technique is actually quite simple when seen in code. Below I am showing the save code. Assume we have already loaded the data and set the timestamp field to a ViewState attribute marked _timestamp.

 //Instantiate a context to do our save

MyDataContext saveContext = new MyDataContext();

//Create a new employee object to fill in

Employee emp = new Employee();

//reset the timestamp viewstate field “before” I attach to set the original value

emp.timeStamp = _timeStamp;

//Attach the object after setting the timestamp.

//This creates an object in state “New”

saveContext.Employees.Attach(emp);

//set the values from our user controls

Emp.FirstName = txtFirstName.Text;

Emp.MiddleName = txtMiddleName.Text;

Emp.LastName = txtLastName.Text;

saveContext.SubmitChanges();

Keys to making this work:

1.       Set the original value, from ViewState, before you attach the object.

2.       Set the new values, from your user controls, after you attach the object.

3.       Turn the “Update Check” to “Never” on all the fields except for the timestamp field in the Linq to Sql designer.

How this works:

Basically, you create a new Employee object. At this point, all the fields (timestamp, FirstName, MiddleName, LastName) are set to null and the state is “New”. Then you set the timestamp field from ViewState. This sets that value to the “original” value we got when we loaded. The state is still “New” at this point. Then we attach to the context. Once the object is attached to the context, any change we make turns the state from “New” to “Modified”. So, when we set the FirstName, MiddleName and LastName we are telling the context that we modified data. This will build an update statement like this:

@originalTimeStamp = “3289t5u23940uewu903285”;

@originalFirstName=null;

@originalMiddleName=null;

@originalLastName=null;

@newTimeStamp = “3289t5u23940uewu903285”;

@newFirstName=”Greg”

@newMiddleName=”Brian”;

@newLastName=”Galipeau”;

UPDATE [MyTable]

SET [TimeStamp] = @newTimeStamp, [fName] = @newFirstName, [lname] = @newLastName, [mName] = @newMiddleName

WHERE ([TimeStamp] = @originalTimeStamp)

The issue with this approach is that it will always think that it needs to update the fields in the database. Because the original value for the First, Middle and Last names always are null, it always thinks we changed them. This is not necessarily a bad thing. You will have to decide that for your architecture. If it is a bad thing, and you really want to use this approach, then you have to set those values in ViewState when you load also. That way you can set the original values, before you attach, and the tool can do a real check against the value to see if you actually made any changes. This process of setting everything into ViewState could become quite cumbersome on larger forms.

The following example assumes I stored the original first, middle and last names in ViewState on the page load.

//Instantiate a context to do our save

MyDataContext saveContext = new MyDataContext();

//Create a new employee object to fill in

Employee emp = new Employee();

//reset the viewstate fields “before” I attach to set the original value

emp.timeStamp = _timeStamp;

emp. FirstName = _firstName;

emp. MiddleName = _middleName;

emp. LastName = _lastStamp;

//Attach the object after setting the timestamp.

//This creates an object in state “New”

saveContext.Employees.Attach(emp);

//set the values from our user controls

Emp.FirstName = txtFirstName.Text;

Emp.MiddleName = txtMiddleName.Text;

Emp.LastName = txtLastName.Text;

saveContext.SubmitChanges();

Conclusion

So far these 3 techniques are the best ones I have found for re-attaching disconnected objects using Linq to Sql or the Entity Framework. If you have any other suggestions please leave a comment. And, let’s just “hope” Microsoft one day realizes this scenario and gives us better options, such as the option to have a mini-datacontext that we can store in Session. That would be nice!