I was working with Whidbey since the early betas and I'm still waiting for some changes in order to improve usability of the VS IDE on C# property pages.
May be I'm the only user that feel that the usability of setting project properties C# is not good. But let me explain a bit more.
When you select properties on a C# project the property dialog appears. It seems like a document window but if you change something nothing happens, there isn't dirty flag, there isn't apply button, so after I change a value in this dialog, I alwayspress in some place in the screen so the window loses the focus, and sometimes I come back to the dialog in order to see if the property was set, this interaction is really unintuitive for me.
Additionally this dialog seems to be generated on the fly (and this generation is slow), and the screen is not well used (big textboxes, etc), I always have to scroll to see the button selectors, and more.
In VS 2003 I could select 3 C# projects for example and change a property, how can I do that in VS 2005?
VC++ continues with the old style dialog, Is VC++ going to change to the new style ?
I was converting some 2003 packages today so I gotta enumerate the most common tasks that you should do if you wanna do the same.
1- Delete all Microsoft.* references in your project.
2- Be sure to change the References Path (Project/Properties/References Path) from VS 2003 to VS 2005.
3- Add References to the new interop assemblies, in general you need references to:
- Microsoft.VisualStudio.Shell ( In this assembly there are almost every class that was in the VSIP.Helper )
4- A lot of errors are because some needed class reorganization.
Constants in NativeMethods are migrated to Microsoft.VisualStudio.Shell.VsConstants
So I recommend you for example to find all NativeMethods.S_OK and replace for VsConstants.S_OK, etc
Calls to Win32 api that were in NativeMethods where moved to Microsoft.VisualStudio.Win32Methods,
for example NativeMethods.SetParent --> Microsoft.VisualStudio.Win32Methods.SetParent
5 - Be careful because the signature of InstalledProductRegistration changed. Idem for ProvideToolWindow.
6- You may consider to use ToolWindowPane (From the Managed Package Framework) as base of your toolwindows, an Microsoft.VisualStudio.Shell.Package as base of your Package.
7- As you probably know the way to handle commands in packages, toolwindows, editors in VSIP 2003 is by implementing IOleCommandTarget (QueryStatus and Exec), well in VSIP 2005 there is a newer elegant way to handle commands using OleMenuCommandService (you can see how to use it in the samples). The problem here is that convert this is not just change a name or a reference. So in this point you have to refactor the probably big case of your querystatus and exec methods.
Obviously there are more things but if you change these 7 points you have your work almost done.
Hope this help.