"Thread abort exception" in event receiver after adding a solution?

Question

I am developing an event receiver for the web provisioned event. It does quite a few things, culminating to add and deploying a solution and activating a feature from it.

When I do the following:

mySolution.Deploy(DateTime.Now, true, true);
web.Features.Add(featureguid);

it complains that the feature is not installed, leading me to think that Deploy is being executed asynchronously. This hypothesis got confirmed when I executed these lines from a test app with sufficient delay. I couldn't find a method to 'join' the process, so I implemented the following loop:

mySolution.Deploy(DateTime.Now, true, true);
while (!mySolution.Deployed)
{
    System.Threading.Thread.Sleep(200);
}
web.Features.Add(featureId);

This didn't work either - something is killing event receiver before it finishes - it never gets out of the loop, and after sever seconds I get the following event in the logs:

SharePoint Foundation Error loading and running event receiver MY_NAMESPASE.MY_FEATURE_RECEIVER_CLASS in MY_ASSEMBLY, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=925ad47513677e46. Additional information is below.

: Thread was being aborted.

At first I thought it's a timeout and I added a timer to see exactly how much time elapses before this happens, starting from the beggining of the WebProvisioned method, even before calling base.WebProvisioned(properties); It's not constant though, sometimes it takes 6 seconds, sometimes it goes till 13. I added executionTimeout="6000" in web.config just in cases - no change

UPDATE: It's not a timeout, I tried the same code without the line that deploys the solution. After that I loop a 30-second loop and it finishes just fine, every time. So, it's mySolution.Deploy that causes the 'Thread was being aborted' exception somehow... but the solution does get deployed!

UPDATE2: I get the same result when I substitute mySolution.Deploy with deployment using PowerShell. Apparently, there's something that is not allowing solutions to be deployed within the context of webProvisioned event receiver in some covert way. For the moment I have no choice but to abandon this requirement and implement a workaround, which will have to involve user interactions instead of being fully automated.

UPDATE3: Actually, not only that my thread gets killed - deployment doesn't ever get to finish properly. I noticed that when I deploy the same solution with PowerShell the feature gets activated - while it doesn't get activated when the same operation is executed in the context of the WebProvisioned event receiver. There is something that's not letting deployment to be finalized (i.e. the feature to be activated) before WebProvisioned event finishes

Answer 1

Deploying solution packages basically resets the Application Pool which would lead simply to your thread being entirelly cancelled.

Although, personally i wouldn't advice in deploying solution packages as such, but rather simply deploy, but use stappling techniques, if you really want to keep up, have you rather considered create a sandbox solution, which would not reset application pools and you would still create a WebProvisioned event inside without issues?

Answer 2

Deployment is asnc, the timer service handles a lot of heavy lifting during this process.

you can either poll the job history or the Deployed property of the solution.

Take a look at this blog post on waiting for deployment to complete, sure it's in PowerShell but the concept is the same.