views:

325

answers:

4

I have multiple projects/wsp solutions for my different Sharepoint webparts and event receivers. This is fine for development, however I would like to merge the resulting .wsp files into a single one for production deployment. Is there a way to do so? I am using vsewss 1.2 only.

+2  A: 

Hi driAn

I haven't seen a tool which does this, but it shouldn't be hard to create:

  1. Unzip the wsp packages (They're just cab files with an odd extension)
  2. Merge the directory structures
  3. Merge the manifest.xml files
  4. Zip the combined package
Per Jakobsen
+2  A: 

This is going to be painful, but to really do this correctly for production pushes you should drop vsewss 1.2, re-organize your projects inside of Visual Studio and use WSPBuilder.

WSPBuilder is great because it takes a lot of the manual work out of creating manifest, ddf and compiling the CAB.

JD
What is the advantage of WSPBuilder?
driAn
It strikes me as the least effort approach to addressing the root (project) structuring issue.
Jason Weber
+2  A: 

You are going to have to do a lot of the work that vsewss is doing in the background your self. there is a artical on MSDN about the basics on creating a WSP Creating a Solution Package in Windows SharePoint Services 3.0 A WSP is a cab file that contains a manifest.xml and a file structure, it is imortant that you place files in the right location in the WSP so they are deployed to the right location in SharePoint.

I agree with JD

This is going to be painful, but to really do this correctly for production pushes you should drop vsewss 1.2, re-organize your projects inside of Visual Studio and use WSPBuilder.

This would be a good time to restructure you code and assembly structure so as to minimise the number of assemblies you need to deploy.

If you have any Web Parts be sure to check that the Feature xml files are all corect as vsewss preparses and does text replacment befor generating its WSP files. It commanly stores a guid in the file where a full assembly name is requierd.

If you are going to be doing a lot of SharePoint dev work it is probly worth spending a bit of time learning how the manafest.xml and rest of the WSP packages work.

JC Vivian
+2  A: 

There is an advantage to not having all your code in a single WSP.. you can do partial deployments and you don't have all your code in a single gigantic Visual Studio Solution.

Why don't you script all WSP deployments in 1 script file? It seems a far more transparent solution than fiddling with the WSP itself.

ArjanP