I am not really sure if I've posted anything on this topic before. I feel like I have, but if so I couldnt find the post in the archive.
So I am risking a second post. However I did asked a similar question up on the sharepoint newsgroup some time back.
Over the past few months my team has been building an intranet application based on SharePoint. We've basically being rolling out our own custom WebParts.
Whats very odd about managing a WebPart development project is that, versioning is a pain.
To increment the version of a webpart library there are several locations where a version string needs to be changed.
- assemblyinfo.cs (i feel like I have blogged this topic before)
- webpart dwp file
- web.config file
So wanting to simplify the process for the team, I built a mini versioning system that took care of all of this.
All that needed to be done was run a command line tool and say something like increment or set <version> (e.g. vwl.exe -newbuild)
But all is not well in portal town. If a webpart has been added to a webpart page, and then the version is changed, the page throws an error when it tries to load.
Why? because the Tagprefixs on the aspx page still point to older version of the dll.
The resulting situation (if you change the WebPart version) is very messy.
Was wondering if there were any known Bestpractices around this.