How to modify the Feature Activation Workflow? [duplicate]

Question

Possible Duplicate:
How can I show an Application page on Feature Activation?

Is it possible to modify the Feature Activation Workflow?

For example, you have developed a Feature that simply add up a link in Site Settings. Here, on Feature activation click you want to redirect on a custom developed Application Page where you take user input. Based on the provided input you decided whether you should allow to set it as activated or not.

If this is possible then how can we do it?

Thanks.

Answer 1

This sounds dangerous as the only way to achieve this would be to access the current httpcontext within your feature receiver and redirect the response to your custom application page. This will work just use the following code:

    Dim context As HttpContext = HttpContext.Current
    context.Response.Redirect("URLToApplicationPage", False)

The problem with this approach is that you are essentially hijacking the request and redirecting it without allowing any further code to execute. So this could cause serious implications with regard to object disposal and other issues.

The other problem is that SP will not think that the feature is activated as you have not executed any further code beyond your redirect.

You can do what you like in the application page so you could activate another hidden feature that makes the true changes (based on the users actions on the application page) however SP will still display the original feature as unactivated in the UI. If you try to activate the original feature via the UI in the application page then you'll end up being redirected back to your application page when the feature receiver runs again. You could try to wrap the above code in some logic so it will redirect if called from the UI but not from the API maybe inject some additional data in with the API call or set a value on the SPWeb's property bag (SPWeb.Properties.)

It is highly likely that there are hidden problems and issues with this that are not obvious at first. I would get a very clear idea of what code you are not executing by hijacking the response in this fashion.

Either way this is a pneumatic drill to crack a nut. What is the requirement that needs this approach? I suspect if you revisit the actual requirement you will find a better approach then this. It does appear to be achievable though.

UPDATE

As @Wictor has pointed out on another thread for a similar question this approach would not work if the feature was being activated outside of the HttpContext i.e. via STSADM. This is a big issue. Do not follow this approach. I said there would be problems with this approach.