I did come across some code where someone was using reflection to do this. I’ve tested this and it works fine.

However I’ve since come to see that even though the .stp was passing in properties to the workflow features. These exact properties are already defined in the feature.xml them self for the workflows in question. I presume that when activating the feature via the object the properties in the feature.xml are respected? So this time I don’t think this is an issue

In case I ever have a custom feature though where it needs to be dynamic then using reflection OR having the feature in the site def are the only options.

Thanks.

You are right, there is no method for dynamic feature creation as you describe it. It is not a limitation of this method but rather one of SharePoint. In other words, you can only activate features that are defined in a feature.xml file (or similar) and cannot create dynamic properties.

.b

I’ve just been tasked with creating something very similar to the example Project site. A slightly more complex site though.

However I now have an issue with the process explained in this issue. I have gone through the .stp and some of the features I need to activate use properties. e.g. the workflow features.

In code I can’t seem to activate the feature and pass these properties.

using:
web.Features[feature.Id].Properties.Add(p);

before:
web.Features.Add(feature.Id);

Does not work! I don’t get this since Micrsoft allow us to create an SPFeatureProperty. I just can’t add it to the feature before it gets activated thus causing a problem.

Any ideas? Workarounds?

Thanks for your kind words

You can certainly apply ths method to existing projects that haven’t been designed with the specific features in mind, and yes, I have done so.

The way I’d do thi this would be to use a feature stapler, as described. Since feature stapling only works on a site definition level, however, you may want to further narrow using a custom filter inside the feature receiver, for example filtering by content (site has a Project Tasks list), by owner (only upgrade sites created by a certain person or group), or other attributes as required.

As for how you would cope with ever changing requirements. Well, beyond telling the PM to get their acts together and make up their minds, you could isolate an expected change into a separate specialization solution. That way, rather than overriding the specialization solution with a new specialization solution, you could simply uninstall it thus preventing the change from happening.

Hope this helps

.b

Development on SharePoint has been a troublesome love. Not for understanding it’s building blocks but for stream lining the development process/life cycle AND especially upgrades.

This article I’m hoping will help loads. Just a shame it’s too late for some projects. Currently updating a project and it’s a becoming a nightmare. Custom scripts I think are going to have to be run to fix the live site back to what the source now reflects, not nice!

1) Wondered if you’ve used your process on an already deployed project which wasn’t developed orginially with your way in mind? i.e converting a project to your ideas.

2) Say a project starts from scrach. The development involved a content type. And the meta data, fields and their types including properties like ‘required’ changed in varying interations. Would this be handled by lots of specialised features which in turn just varied the same content type? i.e what has happened throughout the interations would happen again if the project was deployed to a clean environment.

I’ll keep reading because I’m certain if I’d fully understood then the need to ask Question 2 would not be required.

Great work and worth every £/$