Sharepoint WSP solution management

Question

We have a product which is developed using SharePoint foundation 2010. We are hosting on port 80 and which was stand alone installation of the MSF 2010. Now i need to deploy the same product on different ports for different clients in the farm environment.Right now i am facing some challenges as follows:

we have css, images, jquery files which are mapped to 14 hive folders. Since we were deploying in standalone environment, entire 14 hive folders were serving for one client. Now challenge is, how to manage these css, jquery, images folders in 14 hive folder for different clients(different web applications). If i do small change in one js file(test.js) for one particular file, it should affect for that client itself. It should not affect on other client's js(test.js) file. Since we are having only one wsp solution, and we need to add this to solution repository. Since sharepoint allows only solutions whose names and GUID are unique. So, if i do some change in one solution for particular client , when i upload it to solution repository , it will not allow, since old wsp is already existing. So, how to manage wsp to serve for multiple clients ? . if i do changes for one client, it should not affect on other clients. please let me know the best practice for this.

Answer 1

Given that a feature can be activated and deactivated at a SPSite or SPWeb level, there could be a more elegant solution to this situation.

Instead of packaging your images, CSS and JS files to be deployed to the 14 Hive, you could actually have them deploy to a new Document Library that your feature creates in the SPSite/SPWeb when your feature is activated. You can also configure your WSP such that the JS, CSS and Image files get uploaded to the document library so created.

This way one of your problems is solved wherein you can modify the files for one client manually directly through the document library and it won't affect other websites/clients.

Also, in this configuration, your single WSP will be sufficient and should not conflict since you won't be deploying a whole new WSP when you change some code for just one client.

I found this blogpost that shows you how to achieve the above: http://jcapka.blogspot.com/2011/05/deploying-document-library-including.html

I also would recommend this series to know more about different options of packaging things to your WSP: http://blogit.create.pt/blogs/andrevala/archive/2007/12/02/SharePoint-2007-Deployment_3A00_-Overview.aspx

Its written for SharePoint 2007 but most of it hasn't changed in 2010.

If there are any challenges in the above approach, you can probably find workarounds for it.

Answer 2

When you deploy solutions to SharePoint 2010, they are generally packaged as WSP, which are generally named as business area.

If you are using Visual Studio, Open "View -> Other Windows -> Package Explorer" to explore contents of WSP.

So if your clients have different html, css, javascript, consider packaging them in different WSPs. One solution per client

This way under 14 hive, each solution (WSP) items will be contained in their respective folders, which means changes in css of one solution won't affect other solutions.

If you have application pages, they can go: 14\TEMPLATE\LAYOUTS\Client_1\ 14\TEMPLATE\LAYOUTS\Client_1\css 14\TEMPLATE\LAYOUTS\Client_1\javascript

14\TEMPLATE\LAYOUTS\Client_2\ 14\TEMPLATE\LAYOUTS\Client_2\css 14\TEMPLATE\LAYOUTS\Client_2\javascript

14\TEMPLATE\LAYOUTS\Client_3\ 14\TEMPLATE\LAYOUTS\Client_3\css 14\TEMPLATE\LAYOUTS\Client_3\javascript

If you have client specific webparts, they can go:

14\TEMPLATE\CONTROLTEMPLATES\Client_1\Webpart1 14\TEMPLATE\CONTROLTEMPLATES\Client_2\Webpart1 14\TEMPLATE\CONTROLTEMPLATES\Client_3\Webpart1

All you need is to create well defined directory structure in your WSPs.