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/
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.
I knew it privately but I have realized today that it is public (from a Microsoft source):
TAP is the Technical Adoption Program (TAP) and VSIP is the Visual Studio Industry Partner Program (VSIP).
Given the really horrible / bad / unusable / state of the automation / commandbars model for add-ins in public VS 2010 Beta 2, it is a pity that there isn’t a public Beta 3 available to everybody so that:
– All developers of add-ins (not just those invited to TAP of paying the fee of VSIP) can test that the reported bugs about VS 2010 Beta 2 extensibility are fixed without praying or crossing fingers waiting for the RTM.
– Better yet, consumers of their add-ins can test the add-ins for them also in real life. It is interesting that Microsoft itself is going to suffer the same problem of a lack of a public Beta 3 or RC to verify that their internal fixes / tests actually solve the performance problems of VS 2010 Beta 2 in real scenarios …
Since the bar for bugs to pass the triage and get fixed becomes higher and higher as Visual Studio reaches Release Candidate status. I don’t even think that a public Release Candidate would be of any benefit for developers of add-ins, since bugs discovered and reported at that point wouldn’t be fixed unless they are critical (that is, prevent launching the product or affect a large number of users).
In general, given the “application monster” that Visual Studio is becoming (with more and more features each release) and the huge internal changes that Microsoft is doing to migrate it from a native app to a managed app, what is required IMHO is longer cycles, maybe 3 years instead of 2 (as it happens with Windows / Office / SQL Server, etc.), where the beta 2 is “fully feature completed” and then you devote several months to a beta 3 to fix all the bugs, and then you release a product that you know that will work great rather than just being confident without actual external verification. Otherwise you end with things like Windows Vista or, to less extent, like Visual Studio 2005 (with its embarrassing performance problems in real scenarios), products that were fixed in the next releases (Windows 7, Visual Studio 2008).
While VS 2010 Beta 2 has still an undesirable number of bugs as I have blogged a lot, Microsoft is putting a lot of effort to fix them. This one was fixed today (for the RTM release):
VS 2010 Beta 2 Bug: EnvDTE.WindowEvents.WindowActivated event not fired for window getting the focus after closing other window
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=515234
More than a year ago I wrote a popular post:
.NET Frameworks, CLRs and Visual Studio add-ins
https://www.visualstudioextensibility.com/2008/11/14/net-frameworks-clrs-and-visual-studio-add-ins
I stated that VS 2010 would install .NET Framework 2.0, 3.0 and 3.5 (all of them based on CLR 2.0) and, of course, .NET Framework 4.0 (based on CLR 4.0). You may have noticed in the betas of VS 2010 that .NET Framework 2.0, 3.0 and 3.5 are not installed by default, you have to download and install them separately for VS 2010 to use them in projects. So, I have updated the post.
BTW, in the December 2009 issue of MSDN Magazine there is a good article about loading multiple CLRs in the same process
In-Process Side-by-Side
http://msdn.microsoft.com/en-us/magazine/ee819091.aspx