Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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

share|improve this question
    
Why deploy the solution during the web provisioned event? Why not just have the solution already deployed on the server, along with the solution that includes your web provisioned event? –  GavinB Sep 17 '12 at 20:45
add comment

2 Answers 2

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?

share|improve this answer
    
You are making sense - I haven't looked at sandboxed solutions to achieve this, and I didn't know app pools are being restarted, which makes all pieces of the puzzle fit together –  Vroomfundel Feb 17 '13 at 12:45
add comment

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.

share|improve this answer
    
Yes, I have clearly indicated that I know that the job is done asynchronously, and I have shown the code I use to poll for the completion. The problem is that the thread gets aborted before this gets a chance to finish. I don't see how this could change if I implement an alterantive polling mechanism that uses job status - I'm polling successfully, it's just that my thread gets killed It actually never gets to finish - the features from the solution don't get activated if it was deployed in the context of the WebProvisioned event receiver, while they get activated if I deploy with PowerShell –  Vroomfundel Sep 27 '12 at 16:26
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.