4

2

What is the best way of updating views on a production environment? Assume you roll out a second version of your sharepoint solution and you want to add/modify the views on the list, but you can't just redeploy the list, because it contains production data.

Is it a good idea to update the views via the sharepoint object model? Or are there better ways to update views without touching the underlying list?

Thanks for any advice.

Update:

I accepted Anders Rasks answer. However I'm still looking for a simpler (more efficient) approach for view upgrades. Please post if there is a new solution for this out there... Thanks

flag

3 Answers

4

To do this i would recommend programmatically adding a view programmatically. You should do this in a feature call-out. Make the feature dependable on the original feature that created the view to avoid race conditions if you later decide to activate both features on a new site or need to recreate your farm.

In general i have moved away from doing lists and views declaratively as much as possible. Its only a few lines of code compared to a bucket full of CAML spit ;-)

Programmatically adding views is done using SPViewCollection.Add method. Heres a good example from SharePoint DEV Wiki: Creating a List View programmatically using the object model

More on creating call-outs from a feature receiver: http://www.sharepointdevwiki.com/display/public/How+to+add+a+Feature+Receiver+to+a+Feature

EDIT: SharePoint 2010 supports versioned features. This will allow you to branch updates based on feature version. One option is to add fields to existing content types:

hth Anders Rask

link|flag
Is it really necessary to update every single property on its own, like fields, query, etc? Isn't it somehow possible to just overwrite the whole schemaxml of the view? The property seems to be readonly :( msdn.microsoft.com/en-us/library/… – driAn Feb 7 at 13:59
try and describe exactly what you want to do. You can ofcourse add existing fields on a list to an existing view. I wouldnt recommend removing anything, since it could break existing code or queries. Rather i would create a new view. Same thing with Content Types, with the twist that you could hide existing CT's and create new ones to avoid loosing data. – Anders Rask Feb 7 at 19:38
I would prefer updating the views without creating a new one. Assume this scenario: You need to insert a new field into a view, you could write some upgrade code and deal SPViews and SPFields. However I wonder if I could simply upate the 'raw' xml through the object model, as this would be more efficient to implement. – driAn Feb 10 at 20:34
1

Depending on what your application is, once you're in production the application is going to be changing dynamically due to user activity (assuming it's at all successful). Why wouldn't you just go to the SharePoint UI and make the changes to the view there? Is this a case of over-developer thinking or am I missing a requirement?

link|flag
1 
 That would work, but it gets more expensive for every time you need to repeat the process. Plus it's more error-prone as it depends on the user performing exactly the right steps. In addition to that, you need to take into account the overhead that comes with documenting the steps and updating the documentation when the procedure changes - which people often seem to forget, leaving you with outdated documentation. This is why I like to wrap things in an automated and reusable update procedure, as described by Anders. – Jaap Vossers Feb 7 at 15:05
1 
 Yea. The problem with manually update tasks is the lack of history/persistence of this change, also in regard of reproducing and version control. Furthermore we have a staging and a production system, so it doesn't make much sense to test a new version on the staging platform if the changes are applied manually to the production system afterwards.. – driAn Feb 7 at 15:30
1 
 As a guiding rule, we dont allow UI access to things like CT, SC etc to intranets or WCM sites (Team Sites are often different). As Jaap say theres the documentation issue, but its also a question of stability. Often fields are used across CAML queries, CQWP or in web parts, so you dont want anyone to mess anything up that would break your site or make you loose data. Also we usually manage CT's programmatically rather than declaratively, which do require a developer being involved when upgrades are needed. We try to mitigate by putting alot of work getting the taxonomy right the first time – Anders Rask Feb 7 at 18:55
All depends on the business situation, of course. I just find that too often SharePoint (the collaboration platform) is considered a traditional application and way more development work is done than needed. Clearly you guys have had different situations than what I was thinking with my answer. – Marc D Anderson♦ Feb 8 at 17:33
I think development is just another way of achieving your goal. I'm happy to go with non-dev solutions, as long as the chosen solution "is better than" all other solutions. Sometimes people talk about development as if it's a disease, and it should be avoided at all cost - simply for the sake of it ("no development, everything must be done out of the box!"). Every option should be considered, both dev and non-dev, and also based on the resources available! – Jaap Vossers Feb 9 at 9:54
show 2 more comments
0

you can also create view on dev/staging environment and then copy ASPX file to the production.Just be sure to set correct list guid.

link|flag
I wouldnt recommend copying files between environments. This is both error prone and time consuming (theres probably more than one WFE). Solutions and features are the way to go for consistent deployments. – Anders Rask Feb 8 at 10:07

Your Answer

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