I am sitting in the presentation by KwizCom who are telling about their expirience with upgrading their products and web parts to SharePoint 2010. This is exactly the kind of session I came here to hear - get real life expirience from real life senarios.
Shai Petel is a huge expert in SharePoint development - his presenation is focused on what you need to do Today to make your current projects be ready for the upgrade.
He suggests to train the developers to use Ajax, JSON, silverlight, visual user controls (which I have to admit - it has been ages since I developed a web interface with a designer!).
He also suggests that if you want your solution to be hosted in the cloud, try to limit the solution scope to a site collection level. He did not explain, but I am guessing this is because of sandboxing restrictions.
Shai also encourages you to make sure you use the ASP.NET web part class for your web parts. He explains that the WSS web part class is supported for backward compatability, but does not recommend it.
Shai also recommends working on windows 2008 R2 and running hyper-v machines as your development environment. I don't agree - windows 7 is a (almost) perfect operating system, you can run moss on it, and using Sun VirtualBox (free, and open source) you can create 64bit virtual machines - and from my expirience on my laptop - win2008 just doesnt run as fast.
Now to upgrading a solution. Shai stresses that you should use the same namespacec and assembly evidence - this will allow sharepoint to recognise your solution during the upgrade.
Shai talked about upgrading his "sharepoint list forms extensions" - he showed how the solution looked like in 2007 - both in the screen (new links in list settings and in list forms) and in the code - showing a solution (connected to source safe? who uses source safe these days? or maybe I misread what I was looking at?). He then showed what he added in the 2010 version for the same solution - explaining how in 2007 they couldnt use WSP packages for the solution (due to limitations of the WSP infrastructure) and how now they are using WSP (due to improvements - mostly around version management - see further information below).
Shai opened a new empty VS2010 project, and built the structure for the project that you want, and then migrated his old code into the new project. Then, using a designer in visual studio, defined what features (from the old solution) should be deployed by the solution. He suggested it takes up to 4 hours to do that on a big and complex project.
He then showed how he added new code (or, rather, XML definitions) to replace old custom actions with new ones that would put the custom actions he had in the tool bars into the ribbon instead.
At this point Shai's Virtual machine crashed (working on pre-beta version - this is happening to many speakers here I guess. this is the second presentation in a row that I see this happening to) so he continued with his powerpoint and concluded that with a project that DIDNT use VSEwss (visual studio extensions for wss3) is pretty simple - create new project in VS2010, import existing files, set up the features (using a designer) and add what ever you need.
With projects that were created using VSeWSS need to be opened using a tool that comes with visual studio 2010.
To upgrade an existing WSP package - there is an import wizard in VS2010 that allows you to select which part of the solution you want to import, and it imports it into a new VS2010 project - all except the code. So it does give you the feautres and images and so on, and puts them in the new project structure that VS2010 needs.
About versioning support in packaged solutions - Shai explained that this was missing in 2007 - and is now available. I had many headaches with WSP packages versioning - it is very hard to mark a version number in a package - you have to keep updating a web.config file to make sure sharepoint uses the new version if you change the version of the dll. Shai suggested the same method I have been using - store the version number on a file that is deployed with the package instead. An "about" page can show the user what version is deployed on the server.
Shai then explained that he recommends deploying solution resources into a folder marked with the version number - for example : "_layouts/mysolution18.104.22.168" - this will make sure the solution can be hosted - and then upgraded just for one customer that uses the server, while other customers use the old version - the resource files were not overwritten (remember the assembly in such scenarios is sandboxed - so not in the GAC but rather in SQL and is unique per site collection - which allows this kind of trick).
The new user interface for managing solutions in a site collection (sandbox) will show you if there is an upgrade available for a solution. Us developers can specify that a solution can be updated, and then sharepoint will show that to the users. I expected something more sophisticated - something like how most applications today do upgrades, but I need to get my hands on this feature before I can comment on it fully.
To summarize - good presenation (if a bit rushed and mis-titled) and exciting things ahead!