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
1
  • This is dead simple in VS2008, are you using VS2010? Commented May 26, 2011 at 15:22

4 Answers 4

Reset to default
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
4
  • 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. Commented May 26, 2011 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. Commented May 26, 2011 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). Commented May 26, 2011 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 Commented May 26, 2011 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
2
  • Please expand on this answer, as it is now it is really not much help :/ Commented May 26, 2011 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. Commented May 27, 2011 at 12:45

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.