This is another issue that I can now make public since it won’t be fixed and I guess that VS 2010 RC has it too:
EnvDTE.FontsAndColorsItems.Item(textEditorItem).Background returns 0 instead of actual background color
https://connect.microsoft.com/VisualStudio/feedback/details/518919
This can affect you if your add-in uses RichTextBoxes to colorize code simulating a code window.
I think that VS 2010 uses the correct behavior, while VS 2008 used the convenient behavior…
In VS 2005 and 2008 (but not in VS.NET 2002 or 2003), you could press the Shift key while VS was being launched to prevent the loading of add-ins that were marked to load on startup. This was very useful for developers of add-ins to prevent the following issue:
PRB: ‘Could not copy temporary files to the output directory’ error building Visual Studio .NET add-in.
http://www.mztools.com/articles/2005/MZ2005013.aspx
On Windows 7 and its new bar to launch/show running applications, the Shift key is used to launch a new application, so Microsoft removed that behavior of VS 2010. I reported it when I noticed it in the Jan LCTP build. The report is here:
VSIP: VS 2010 Jan LCTP: Shift key doesn’t prevent loading add-ins when VS is launched
https://connect.microsoft.com/VisualStudio/feedback/details/526271
The workaround is to use the /SafeMode command-line switch, I updated the article above.
This is something that happened me three days ago when I installed VS 2010 RC for the first time. I have tried to reproduce it several times to no avail, so I haven’t opened a Microsoft Connect report. FWIW, I will post here what happened just in case some of you want to test.
First, some background: when you develop an add-in for commercial or freeware use (not for in-house) chances are that you want to target multiple Visual Studio IDEs, ideally with the same binary DLL, just registering the add-in for several hosts. For example, an add-in built using CLR 2.0/.NET Framework 2.0 can target VS 2005, VS 2008 and VS 2010 (even if VS 2010 doesn’t install CLR 2.0/.NET 2.0 but CLR 4.0 / .NET 4.0). When the setup of the add-in is run, it can do two things:
I had a new version of my MZ-Tools add-in that uses XML registration and targets VS 2005, 2008 and 2010 using a single XML .AddIn file, and it is marked to load on startup, and then I installed VS 2010 RC for the first time in that particular machine. The installation went OK, and when I launched VS 2010 RC for the first time, VS showed the usual message asking for a profile and indicating that it was initializing for first use, which could take a few minutes. The add-in was loaded two (I know because it shows a welcome kind of message).
When VS 2010 RC was done, I noticed that most of the user interface of my add-in was duplicated: two main menus (one of it disabled), two toolbars, etc. I went to the Add-in Manager and unloaded it, which caused a crash in VS and finally I was able to delete by hand the toolbars, menus, etc. Once cleaned, next times the add-in loaded well as expected.
I don’t know for sure what happened there, but it seems as if VS 2010, as part of its initialization, tried to persist the menus, toolbars and buttons of my add-in (that uses temporary UI) on disk as it does with packages and add-ins that use permanent UI. So the IDE ended with duplicated UI.
To reproduce the problem, I thought that the same thing would happen if I created another user account and launch VS 2010 for that user, since VS will need to ask profile, initialize user settings, etc. But I was unable to reproduce the issue.
Then I went the long route of installing VS 2010 RC on virtual machines with the add-in already registered, and I was unable to reproduce it too.
So, I don’t know if it is a timing issue (when the add-in is loaded and when VS persists UI on disk) or what… but I know what I saw and there is a bug somewhere there…as I explained in other posts, VS doesn’t take much into account that buttons can belong to add-ins that use a temporary UI, not always to packages or add-ins using permanent UI.
To play safe maybe I will change the setup to not register the add-in for IDEs not installed yet, but I am almost sure that the problem should happen too if the VS is launched by a new user on the same machine
I hope this helps. Let me know if you encounter this issue to reproduce it and send it to Microsoft.
I noticed yesterday that an enhanced version of the ADO.NET Connection Assistant feature of my MZ-Tools add-in causes an exception for OLEDB connection in VS 2010 RC, not in VS 2008 or 2005. After a couple of hours debugging and trying to figure out why, I finally noticed that VS 2010 RC also suffers that problem in its own Add Data Source dialog. Here it is the bug report:
Data Links button on Add Data Source dialog causes AccessViolationException
https://connect.microsoft.com/VisualStudio/feedback/details/534307/
In the last couple of weeks two important things happened: after several secret LCTPs, Microsoft released a new public build of VS 2010 (the Release Candidate), and… I got married 🙂 I spent the honeymoon at Argentina, which has arguably the most impressive natural wonder of planet Earth (the Iguazu Falls), and impressive glaciers too (Perito Moreno). And if you like to eat meat, the beef is superb. Definitely a very recommendable traveling destination.
I have just downloaded VS 2010 RC and I am installing it. I don’t expect many changes from previous LCTPs since the focus of this build was only performance fixes, but it is a big change from the last public build (Beta 2), which was unusable for add-ins due to commandbar bugs (that I blogged a lot about in last months). All the critical bugs that I reported were fixed in LCTPs but not the minor bugs. I will change to “public” my private bugs to Microsoft for my next posts but basically VS 2010 will be a release with some bugs relating its new WPF-based commandbars. I was able to workaround most of them so Microsoft told me that they would prefer not to fix them, to avoid the risk of breaking something else.
You may have noticed that I am not blogging too much these weeks. The reason is that I have been working on the next version of MZ-Tools (and it is too early to comment about it) and testing the VS 2010 Super-Limited-CTPs that Microsoft provide to some people to test their extensions (add-ins, packages, etc.). These SLCTPs are under Non-Disclosure-Agreement (NDA) so the bug reports are private and I can’t comment what is fixed or it is still wrong. I am looking forward to the public VS 2010 Release Candidate to provide more information in the add-ins area.
On a separate thing, I have finished watching the videos of the Visual Studio Extensibility (VSX) Developer Conference October 2009 that were of my interest. I have updated the Resources page on my web site to list all the videos.
The first thing that strikes me is that none of the 20+ sessions is devoted to add-ins, and none was devoted in the 2008 conference too. Add-ins is an area of extensibility that is basically dead for Microsoft, only maintained due to the number of add-ins out there. While not as easy as they should be, historically add-ins have been the easiest way to extend Visual Studio, and originally in VS.NET 2002, the only way to do it providing a user interface (macros don’t provide user interface, the VS SDK was not introduced until VS 2005 and the former VSIP SDK was introduced in VS.NET 2003). The EnvDTE API is not certainly elegant and it suffers lots of inconsistencies and drawbacks that I have blogged about extensively all since I started this blog back in November 2006 (it turned 3 years recently), but it worked for most of us, specially because it was powerful enough for most purposes and the alternative (the SDK) was even worse until recently. If I had to start today building a VS extension, the SDK would be the way to go, but when you have an 8-years old add-in with tons of lines of code, it is difficult to think about migrating it knowing that it will provide no added value to the end users once migrated and tested completely.
The second thing that strikes me is that there are no progress in the extensibility of ASP.NET Webforms or the new WPF / Silverlight forms for add-ins (or may even for packages, I don’t know). If your extension wants to manipulate programmatically those forms or usercontrols, it’s going to be a difficult time. The Window.Object may return something for ASP.NET forms, but nothing for WPF / Silverlight forms. AFAIK, the designer of WPF is even a separate process and when they talk about WPF Designer Extensibility, they mean extensibility for developers of WPF controls to provide editors, adorners, custom actions or menus, etc. It seems that all emphasis about VS extensions is about to explore or manipulate code, and never to explore or manipulate forms/usercontrols.
The last striking thing, on the positive side, is that Visual Studio has got so much extensibility in several areas to deserve an annual conference with lots of sessions. That’s certainly great.
Happy New Year!
I have just received the Most Valuable Professional (MVP) award again, the 7th one that I receive from Microsoft. As always, I am very grateful for this award 🙂
Finally, on the contrary to what I posted some days ago, Microsoft announced yesterday that there will be a public VS 2010 Release Candidate, and that “the planned final launch date is moved back a few weeks”.
This is good news for developers of add-ins, because:
1) That release will be the first one where the automation model of the WPF-based commandbars will work without the many critical bugs of Beta 2.
2) Developers will be able to release add-ins compatible with VS 2010 RC for the end users to test them.
That said, there will be minor bugs that finally won’t be fixed
even in RTM because the bar to get them fixed is very high already today, but I
think there will be workarounds. I will post about them when the RC is released.
Channel 9 has now the video recordings of the talks that were given at the 2009 Developer Tools Ecosystem Summit:
http://channel9.msdn.com/tags/Development-Tools-Ecosystem-Summit/
I’d suggest to start with the keynote:
VSX100: Visual Studio Extensibility Keynote: Past Present and Future
http://channel9.msdn.com/posts/VSIPMarketing/VSX100-Visual-Studio-Extensibility-Keynote-Past-Present-and-Future/
Brian Harry, Microsoft Technical Fellow and Product Unit Manager for Team Foundation Server (TFS) has commented about my last post “No public VS 2010 Beta 3 or release”. (Brian is making a huge effort in transparency about the performance problems of VS 2010 Beta 2 and the work to get them fixed for RTM)
I reproduce his comments here:
“I don’t know Quan but I can say definitively that this is not an official Microsoft communication. I’ve remarked before (on my blog) that when you have an organization of 2,000 – 3,000 people, you have to assume random stuff happens. Said another way “Don’t believe everything you read” 🙂
1) We’ve had an RC on the books from the beginning. We are investigating the possibility of making it a public release. We didn’t originally for that but the Beta 2 feedback has made us rethink it. We will ensure that there is time to incorporate customer feedback. Quan wrote this a while ago and, to be honest, I’m not sure we had reached that conclusion yet.
2) We haven’t decided what we are going to call the public release yet. We’ve discussed both “Release Candidate” and “Beta 3”. I responded to one comment on this post: http://blogs.msdn.com/bharry/archive/2009/12/05/anatomy-of-a-performance-problem.aspx with some thoughts on this. Regardless of what we call it, we will be looking for customer feedback/validation and will allot time to get it before releasing.
3) March 22 is NOT the release date. It never was. March 22 is the marketing launch date. We generally don’t announce RTM dates ahead of time but we do communicate launch dates. Sometimes RTM happens before the launch, sometimes after. I think it’s fair to say that we are targeting an RTM in the general timeframe or we wouldn’t have set the launch date there but there are many considerations that go into launch dates – lining up with other events, hollidays, venue availability, … Further, it would make no sense for us to have set a final RTM date before getting Beta 2 feedback. We always say “we’ll ship the product when it’s ready”.
Am I the official Microsoft spokesman on this topic, well, um, no. However, I will say that I’m in all of the discussions about when we’ll ship, how do we know, what prereleases will we do, etc, etc. And those who do actually own the “official responsibility” know I’m writing about it and are keeping quiet. Maintaining plausable deniability, I think 🙂
If you want to learn more, please visit my blog at http://blogs.msdn.com/bharry. I’m passionate about shipping a great developer tool and partnering with all of you to accomplish it. I’m always listening and open for feedback. Nothing I like more than a productive debate.
Thanks for listening,
Brian”
It’s great that Microsoft is considering another public release before RTM. I know it would be to validate the performance fixes after Beta 2, not because add-ins are broken in the current Beta 2. I am fortunate enough to get the private Limited CTPs (LCTPs) after Beta 2 but I am under a Non-Disclosure Agreement (NDA) so I can’t blog about their fixes, workarounds or new problems as I did with the public Beta 1 and Beta 2 in the last months to help others, and my new Microsoft Connect bug reports are now private to Microsoft too. But other developers of add-ins would benefit from that public release, and working add-ins could finally be made available to end users for testing before VS 2010 gets RTM. I wouldn’t have any hope of getting fixes in the automation model between that public release and RTM, though.