8

In my Visual Studio 2010 SharePoint Project

I have a single SPItemEventReceiver that is contained in its own Elements.xml

I have 2 site collection features that are mutually exclusive they are never both activated on the same site collection.

I want to use the SPItemEventReceiver in them both.

I found that I can add the element.xml for my event receiver into both site collection features.

This seems to work but studio reports a warning.

The Project Item "MyItemEventReceiver" is included in the following Features: SiteFeature1, SiteFeature2

I cannot find any documentation on this warning or the possible side effects of this configuration.

What is the recommended way to share an SPItemEventReceiver between multiple features?

| improve this question | |
  • This is dead simple in VS2008, are you using VS2010? – James Love May 26 '11 at 15:22
2

If this was VS2008, I'd create my receiver class in my project (standalone .cs file) that inherits from the right class and implements whatever it needs to do, and just wire up the two separate Elements.xml files from the two features to use the class by assigning the correct ReceiverAssembly and ReceiverClass properties.

You can probably do something similar with VS2010, but making using of the Feature merge files.

| improve this answer | |
  • If I understand correctly you suggest that rather than sharing the element only the code for the SPItemEventReciever would be shared and 2 different element.xmls would be created. – Steve P May 26 '11 at 15:47
  • Yes, two separate elements.xmls, one for each Feature, and they both call into the same class. My answer had an inaccuracy, I'll update. – James Love May 26 '11 at 15:52
  • Yes, that's what I've done. Two Features using the same assembly. I was also passing in parameters using an SPFeatureProperty, if that helps. I didn't use the elements.xml, but that's cos I was using a feature receiver to register my event handler programmatically (which also let me do something with the parameter I'd fed in). – Andy Burns May 26 '11 at 15:54
  • You might even be able to use a FeatureReceiver then without even needing the elements.xml if you do it through code. Dave Hunter has a code snippet for doing this in a FeatureReceiver (2007, but still relevant): davehunter.co.uk/blog/Lists/Posts/Post.aspx?ID=69 – James Love May 26 '11 at 15:56
3

It's a warning. It's simply there in case you didn't mean to have this configuration. i.e. you've added to the feature you want it in but didn't remove it from the feature it got added too by default.
I've successfully deployed and used solutions that gave this warning while packaging
The solution won't let you package if you're going to have two elements that wind up deploying to the same physical file location so I'd say in this instance you are safe to ignore the warning this time

| improve this answer | |
1

I would suggest you try building the receiver as a separate project item. That should then get deployed with the solution package and can be added to both the features.

| improve this answer | |
0

Not to incite a war here, but... Use WSPBuilder?

| improve this answer | |
  • Please expand on this answer, as it is now it is really not much help :/ – Anders Rask May 26 '11 at 21:20
  • WSPBuilder doesn't change the quesion of whether its safe to package the same ElementManifest in multiple features. As you can imagine we have quite an investment in the VS 2010 toolchain forcing an organization wide switch to a new tool is not really feasible. – Steve P May 27 '11 at 12:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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