Tell me more ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.
up vote 1 down vote favorite
1

Today I was asked if I could build my wsp solutions in such a way as to not load all of the features (list definitions, content types, etc.) directly in the FEATURES folder of the 12 hive. They would like all of the features to go into a subfolder based on the solution name under another folder like this:

FEATURES\CompanyName\SolutionName

I am using VSeWss 1.3 and have the FEATURES folder created and the other folders. The features exist in the subfolder, but all of the features including any eventreceiver features still deploy into the features folder. Is what I am trying to do even possible and how do I do it with my current setup. I am not allowed to use any other 3rd party tool (wspbuilder etc.)

share|improve this question

3 Answers

up vote 3 down vote

You could structure your wsp in this way if you got rid of VSeWss and packaged your solution from scratch (ie manually look after the manifest.xml and solution .ddf files)

The bigger issue however is that your feature.xml MUST be located in the first level folder under features. In your case your feature.xml would need to be in the Features/CompanyName folder.

What this also means is that you can only have one feature. If you need to deploy assets at different scopes, you need to have multiple features, which means multiple folders directly under /Features/

share|improve this answer
up vote 1 down vote

Agree with Paul. I can't think of anyway that this wouldn't restrict you to just one Feature.

If I were you, I'd pass that piece of information on and say that their requirement isn't compatible with the way SharePoint stores things in the Features directory. One thing to consider however is whether you're suffering from Feature proliferation - I often see more Features created than there really needs to be..

share|improve this answer
The main issue we suffer from sounds exactly like this. We develop solutions in VS because we may have another similar org that says they want our solution. We have to create the solution including the custom lists as one package and a lot of these also have eventreceivers which also add more folders to the features folder. Sometimes it does happen where we decide later that we did not need to have an event receiver but still that features folder gets really big even after 5 or 6 site definition solutions get added. – spevilgenius Apr 7 '10 at 23:51
@spevilgenius: There's nothing else you can do except prefix all of your features with your company name. – Alex Angas Apr 8 '10 at 0:09
It was looking like this was the case but I had to know for sure! Can I vote up both answers and how can I set it as being 'done'? – spevilgenius Apr 8 '10 at 0:29
up vote 0 down vote

If you have a solution packaging driven by WSPBuilder, you can structure many different features, with different names, namespaces, .WEBPART files - or however you want.

I'd suggest you see if you can take the same code + feature.xml - and package using WSPBuilder...

Why can't use you use WSPBuilder ? It's free ! and it rocks !

share|improve this answer
We are not allowed to use 3rd party tools that are not approved by an external group. The process to get something approved is hideous but we are trying to get it approved. I was still under the impression that the features were required to be in the root of the feartures folder. It would be great if that was not the case. – spevilgenius Apr 8 '10 at 16:30
@GrumpyWookie: Please don't add signatures to your posts. It adds noise to the site. Thanks! :-) – Alex Angas Apr 9 '10 at 2:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.