I'm curious if anyone has seen any guidance/best practices on developing web parts that can work for both SP2007 & SP2010 with minimal conversion? They wouldn't take advantage of any new 2010 functionality. Rather, I'm thinking about forward migration - taking parts written for 2007 and ensuring that they can run on 2010. Recompilation to target new SP DLLs is OK but I'd rather not maintain two completely separate code branches.
2 Answers
You don't have to do anything. Your 2007 Web Parts will run in SharePoint 2010 as long as you are not using any of the deprecated APIs (such as the old SSP stuff).
SharePoint 2010 ensures (using assembly redirection) that the referenced v12 DLLs will use the new v14 assemblies. So you do not even have to recompile your stuff. Just deploy them...
-
2And remember not to use the new Visual WebPart template of Visual Studio 2010, they won't work in MOSS 2007.– FloFeb 5, 2010 at 8:01
-
1Just to elaborate on Wictors comment regarding compilation: as long as it is code running inside IIS you dont need to recompile. For timerjobs, eventhandlers etc. recompilation is needed Flo: thats a good point! Feb 5, 2010 at 18:32
-
-
Compatibility is from 2007 to 2010 in most cases (assembly redirection etc makes it work, except as Anders says). But you should never use anything developed for 2010 in 2007. The feature framework has changed a lot, which is not supported in 2007 and there are no reverse assembly redirection. If you need Viusal Web Parts in 2007, make a manual one using LoadControl or use SmartPart. Feb 5, 2010 at 18:48
The new Visual WebPart designer is really just a "pattern" that makes it easy. You can use the exact same code + ASCX method with a WSP project today - for 2007. It's just .NET code that you load the control.
The only bit you DON'T get is the actual visual design / drag+drop within Visual Studio.
Another thing to note is that .NET 4.0 is what would be targetted by VS-2010 - whereas you should remain at .NET 3.5 for SharePoint 2007 AND 2010.