1

In the initial release, I had 2 solutions: one is timer job and the other is event receivers/lists. In hindsight, the event receivers/lists should've been separated as well.

In the newest iteration, I've attempted to split the two. Taking the Event Receivers and putting them into a separate solution. Thus far, it works. For the most part.

However, there is the issue of the fact that the list definitions are deployed to the production site and have data in them. If I deploy as-is, it'll wipe the data clean. There is the ListInstance object that I can change the Deployment Conflict Resolution to None, which I did and attempted to deploy. In doing so, it fails at activation because it says a list (or one of the other categories of SharePoint objects, but it is list in this case) already exists with that name. As such, it won't allow it to activate.

The only thing I changed with the feature for what is now the Lists solution was the removal of the event receivers (migrated that code to a separate solution). Anything related to the lists (columns, views, etc.) remained the same. So in reality it should be the same but isn't treated that way (from what I read, if they're the same, it is no harm, no foul. If not, the system won't like it).

In the development environment, I've been able to make it work but the solutions were handled as such:

Timer job - deployed and activated Event receivers - deployed and activated Lists - deployed

At this stage, everything was handling fine. If I don't have the list definitions deployed, the links to the lists result in the page giving an ASP.NET error (understandable), but for some reason the solution just being deployed makes it functional again. Not optimal, but there's that.

What would be a method of making it where all three solutions can be deployed and activated without losing the data within the lists in question? Event Receiver

1

I would look into using a Feature Upgrade. By adding versions to your feature, you should be able to get around re-deploying the list instances and overwriting what is there, because the version you are deploying now is, for example, version 2.0.0.0, and the original version (that included the action of deploying the list instances) is 0.0.0.0. Since you're deploying version 2.0.0.0, and 0.0.0.0 is already deployed, SharePoint will skip the actions associated with deploying version 0.0.0.0 (i.e. creating list instances).

Here's some MSDN documentation on Feature Upgrading, and here is the first of a several part series on Feature Upgrading on Chris O'Brien's blog.

Another thing that may be useful to you in this situation is the Powershell cmdlet Update-SPSolution, that will allow you to overwrite / upgrade an existing WSP without needing to retract and remove it first.

| improve this answer | |
  • Haven't implemented/tested yet, but per reading Chris O'Brien's series, it looks like this will be the direction I need to go in. – Robert Jul 25 '14 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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