Wednesday, August 11, 2010

Speaking engagements 2010

For those of you who are interested, or just happen to be in the neighbourhood, here is a list of some of my speaking engagements;

July 6 2010 - Mississauga SharePoint User Group - All about the SharePoint Ribbon for developers

August 7 2010 - SharePoint Saturday Denver - Upgrading customized solutions in SharePoint from 2007 to 2010, Delegate Controls: What, Where and How

August 12 2010 - Microsoft HQ in Ft. Lauderdale - Upgrading customized solutions in SharePoint from 2007 to 2010, Delegate Controls: What, Where and How, All about the SharePoint Ribbon for developers

August 18 2010 - Toronto SharePoint User Group - All about the SharePoint Ribbon for developers

September 11 2010 - SharePoint Saturday EastBay - All about the SharePoint Ribbon for developers

September 18 2010 - SharePoint Saturday LA - All about the SharePoint Ribbon for developers

September 25 2010 - SharePoint Saturday Boston - All about the SharePoint Ribbon for developers

October 2 2010 - SharePoint Saturday UK - Cancelled due to travel limitation

October 16 2010 - SharePoint Saturday DC - All about the SharePoint Ribbon for developers

November 13 2010 - SharePoint Saturday Toronto - All about the SharePoint Ribbon for developers 

December 17 2010
- SharePoint Saturday Boston Webinar - All about the SharePoint Ribbon for developers

January 31, February 2 2011
- SharePoint Summit 2011 - All about the SharePoint Ribbon for developers *

So, see you there!

If you are interested in inviting me to speak at your event, or if you are interested in speaking at the Toronto SharePoint User Group - Please email me to shai at kwizcom dot com.

* - Working on a special lab for this event!

( my 2011 speaking engagements page: Speaking engagements 2011 )

Monday, August 9, 2010

Upgrading customized solutions in SharePoint from 2007 to 2010

This is an updated version of the session given in Microsoft’s SharePoint 2009 conference in Vegas, and other SharePoint Saturdays events.

Delegate Controls: What, Where and How - Updated

Here is the updated presentation from SPSDenver:

Note: Code example is embedded in the power point file so you have to download to get it.

Tuesday, August 3, 2010

Assembly redirection in WSP

Recently I have started upgrading our utilities to the new SharePoint 2010 version,

One of my main goals there was to get rid of the MSI installer we had to use on our products for SharePoint 2007, and go with a "cleaner" installation process of using the SharePoint WSP package alone.

One of the challenges was that as an ISV we have no control over our customer's server, setup or versions installed. Which means, any customer may have any mix of products and versions at the same time.

For example: say we have 2 products - ProductA and ProductB (both at version 1.0.0.00) that were build using our shared utilities DLL: utilities.dll version 1.0.0.01

A month later, we add a new feature in our utilities.dll that is used on ProductB, so now we have upgraded our utilities to version 1.0.0.02 and our ProductB to version 2.0.0.00 and we publish that to the Internet.

Now our customer upgrades his copy of ProductB only.
We had 2 options here:
1. keep both utilities version
2. upgrade and keep only version 1.0.0.02

The first option was no good, since for example our utilities declare a feature called FeatureA. if 2 different packages declare that same feature, and one of them is retracted later on - the feature will be uninstalled with it (There are some other issues like this one, but this is not the scope of this article).

So, sticking with the second option was pretty simple: just install the latest version of utilities with no other older versions of it anywhere.
The only issue was, How will it "tell" all other older products (ProductA) to start using utilities.dll version 1.0.0.02?!

I have looked everywhere for a solution that was just under my nose.

Apparently in VS2010 and SharePoint 2010 there is a new XML node in the package XML definition, right next to the assembly "SafeControls" node.

This new XML node is called "BindingRedirect", and it allows you to specify in the solution package itself any Assembly version redirection you might need!

Problem is - the package designer does not expose this property, so you have to enter it in the Package.Template.Xml directly.

here is how my package.template.xml file looks like:

The end result is:

And this simple produces the following entree in the web.config:

Now, as far as I tested:
  1. Retracting solution cleans this entree up with no problem!
  2. Deploying a new version upgrades this entree and does not create duplicate entrees!
  3. It is safe (like in my example) to give a wide version range in the oldVersion property - even for future versions that do not exist yet. it will simply allow you not to update this every time you build a new version.
So far, this solution had worked out perfect for me, and it is by far the easiest and most simple way to do it in SharePoint than any other way I found on the web - so hope this helps any of you.

Cheers, Shai.