Supplying input to a feature receiver

Question

Hello.  I am trying to solve a problem that I haven't seen addressed on the forums yet, and I can't figure out a good way to do it (or even if there is one).

 

We are building a feature that we want to be able to distribute widely and that is easy to deploy for administrators.  We want the feature to make updates to the web.config when it is installed, so a feature receiver sounds like the way to go.  Unfortunately, we don't know what the exact change that needs to be made is without input from the administrator.  For instance, we'd like to be able to have the feature receiver add a connection string to the web.config, but we don't know what should be in the connection string until the administrator actually installs the package.  We almost need to be able to pass paramaters to stsadm when it activates the feature, or be able to deploy an answers file that can be used for input by the feature receiver, but that file would have to be included in the WSP file when it is built.

 

Does anyone have any suggestions?

 

Thanks,

Bill

Answer 1

I would probably use Feature Properties.

 

The problem is, this will involve modifying the feature.xml to add in the tags ...

 

for example:

Code Block

 

< Properties >

 

< Property  Key="ConnectionString" Value="MyConnectionStringValue" / >

 

</ Properties >

 

then from code, in your SPFeatureReceiver .. your "OnActivated" method should have a "properties" object.

 

Code Block

string strConnection = properties.Definition.Properties["ConnectionString"];

 

 

To make this easy to use .. I would do the following:

 

• Create your SPFeatureReceiever class and your Feature. In the same class, add your "Feature" folder (and the subsequent xml files) as "Content" in the class library project (you know .. you have the choice of "compile", "content" or "embedded resource")
• Create a Setup project which creates an MSI installer.
  • Add your "Content" from your Class Library to the \12\Features\ folder. This will effectively "copy" your feature to the correct location.
  • Add the primary output (the DLL) to the GAC folder in the setup project. This will effectively "copy" your DLL into the GAC when it is installed.
• Add a custom user interface which allows the installer to specify their "configuration" settings (in the above example .. the connection string).
• Develop a custom "Installer" class to your setup project and use that to modify the "feature.xml" once it has been copied across and add in your "Properties" tags.
• Make sure your Installer class then "installs" the feature by finding the STSADM.EXE application and running the command to install the feature.

Then .. when your feature is activated it will make sure that the correct "Properties" are applied to the feature.

 

Wham .. a feature with dynamic "on install" properties ... with the added comfort of a Windows Installer package.

 

If you want to get REALLY fancy .. add object model code to your Installer Class and allow them to install and activate at the same time. While you are at it, why not add "uninstall" and "rollback" methods so that your feature is gracefully uninstalled and deactivated if they decide to uninstall your setup package.

 

Let me know how you get on

 

MKeeper

Answer 2

Wow!  Thanks for the feedback!

 

Just to be clear, I am starting with a WSP file and am using STSADM to install files into the right folders under \12.  So the installation process would be:

 

1. Use STSADM -o addsolution to get the WSP unpacked to the right folders on the system

2. Run a custom script to modify the feature.xml and add the properties I need

3. Use STSADM -o deploysolution to get the files out to the front end servers

4. Use STSADM -o activatefeature to activate the feature

5. The activate receiver function reads the properties and makes the web.config modifications

 

In addition, we should undo the web.config changes when the feature is deactivated.

 

Have I captured the process in a way that makes sense and will work?

 

Thank you very much for your help,

Bill

Answer 3

 

Yes, you can do it that way too.

 

Note - if you want to "automatically" run your custom code when the solution is deployed (stsadm -o addsolution ...) then add a feature which has a "Feature Installed" event handler.

 

Glad I could be of help

 

MK