So, this is how it feels to write a first blog post :)
Even though I honestly aim this blog to concentrate on MOSS 2010, it seems like there is one 2007 trouble I should share with you.. So I just have to get it off my chest.
We all know and love SPFeatureRecievers .. Those useful little guys can be used for performing additional deployment tasks (or any kind of tasks) that can't be acheived using the default solution installer options specified in Manifest.xml. They can come in quite handy in those cases one might want to verify something is installed on the sharepoint farm, lauch a timer job that will propagate changes accross the whole farm, clean up some stuff upon de-activation, etc...
However, there is one thing that you should not do with them, which I have learnt the hard way: You really should not perform evil evil deployment tasks using SPFeatureReciever(SPFeatureReceiver.FeatureInstalled(...); really..).
As it occurs, updatesolution usually does the following:
1. It stops IIS (or any other proccesses and services as required..)
2. Updates the relevant files "under sharepoint's hood" - that is, files specified in manifest.xml are being replaced if a newer version exists.
3. Restarts everything up.
So, as you can clearly see, there is no Feature install / uninstall / activation / de-activation proccess occurs. This is Sharepoint "by design" behavior, and although Microsoft should really supply a mechanism around this, this behavior makes all the sense in the world.
So, how does this affect us? Simply enough, any Resource that has been deployed using a Feature Recevier method will not be re-deployed, and in a case it was updated -- SharePoint will not redo the custom deployment for the newer resource and our feature will wind up using the older resource.
There are few ways around this, honestly, I'm not really fond of any of them..
You can try to check for resource version in the feature code it self, and in case it's old, re-perform the installation itself. - this is really a bad pattern, atleast imo, since we may never know how this might fail (let's say a locked file - by w3wp.exe!!) and this may temper with user experience.
Another suggestion I found was to generate a new SolutionId every time we rebuild the feature (or rebuild it with a newer 'custom deployed resource') - this way stsadm will refuse to update the older feature using "it's not the same feature" excuse, but it will force the customer to uninstall the older version because two features with the same name may never exist. ("This sharepoint farm is not big enough for both of us, aye?" - sorry it seems funny right now..)
But best option, well, atlest in my opinion, is to avoid this behavior alltogether. Even if it means in the costs of functionality changes. That is untill I think of a better solution..
I really did come to this conclusion after some trial and error (and google..). If there is some additional light to shed on this, please do, by all means, leave any feedback :)
Please keep in mind that this is my first attempt though - so try to spare me the flak...
That's all for now, Next post will be about MOSS2010.. Promise ;)
Cheers, Fusi...
