This project is read-only.
1

Resolved

[Bug?] Possible issue with receiver class.

description

Hi,
 
I'm writting this notice to report a (possible) issue that I have experience while working with SPVisualDev. I dont't know if it should be considered a bug, a limit of the current version or simply a false issue caused by a missunderstaning of the configuration settings of the artifact project.
 

 
Basically the problem is this: under certain circumstance, SPVisualDev triggers a strange behaviour while working with feature.xml files and feature receiver and automatically updates the current setting with incorrect data. I work on a solution where the feature receiver classes are placed in a different project than the artifac project: every time i install a feature with an event receiver from the ide (but i saw the same issue happening on a wsp build) SPVisualDev tries to update the feaute.xml file and replaces the ReceiverClass and ReceiverAssembly setting with some "random" namespaces (seems to be the namespace used by the artifact project).No need to say that this anomaly leed to problems when you try to activate the feature form SharePoint (a nice "Failure creatin the feature reciver object" if I recall well)...
 
The funny part is that if you have the luck to work source controlled you can simply workaround the problem by dismissing the file checkout prompt on the feature.xml file - the setting will remain untouched and all will work as expected.
 

 
I'm writting this here (and not in the issue section) because I dont know if this issue while dangerous could be considered a bug or it is a limit of the current version, so i'm hoping to bring some light - maybee someone else has experienced this? It would be usefull if Tore could also confirm if having a feature receiver class ina a different project is supported (or if we should configure something with the default feature namespaces??) - just to know if it 's worty to make some other test or it's better to leave this issue alone for now.
 
Thanks again for your tool - will try to see if i discover something else and report here any new discovery.

comments

tore7506 wrote Dec 11, 2009 at 12:03 PM

This has been confirmed as a bug in the FeatureManager class which adds adds the currently assembly name as the receiver class assembly insted of the assembly which the actual class belongs to. A fix is on its way and it will no longer replace the assembly name if the code file exists outside the own project. Unfortunately it will not discover the proper assembly name and fill it in automatically if it is outside the features project. Maybe this will be done in a later major release.

Regards,
Tony

Arran wrote Dec 11, 2009 at 12:46 PM

Hi Tony,
Thanks for your response. I posted on the discussion board only because the "receiver picker" window currently shows only the files in the artifact project so I wondered if my architetture - having the receiver in a separate project - was supported in this version of the tool.
Good to know you have found the source of the issue, and don't worry if there will be no automatically filling of the assembly name - we can just edit the feature.xml file for now.

Thanks again for you efforts.

tore7506 wrote Dec 11, 2009 at 4:02 PM

Fixed as mentioned in my comments earlier.

Regards,
Tony

wrote Feb 14, 2013 at 1:23 AM

wrote May 16, 2013 at 6:08 AM

wrote May 16, 2013 at 6:08 AM

wrote Jun 14, 2013 at 8:51 AM