|
Dr. Dobb's recently sat down with some industry experts who use Visual Studio 2005 on a daily basis to get their impressions about its stability and usefulness.
April 21, 2006
URL:http://drdobbs.com/architecture-and-design/visual-studio-2005-unstable-and-highly/186500706
Visual Studio 2005 started shipping in November of last year. On behalf of Dr. Dobb's, Scott Swigart recently sat down with some industry experts who use the product on a daily basis to get their impressions about product stability and usefulness. Rockford Lhotka, Billy Hollis, Bill Vaughn, and Kathleen Dollard took the time to chat with Scott on this topic. During the conversation, they describe in detail stability problems with Visual Studio 2005, and point out resolutions to many of the specific issues. It's also worth noting, up front, that despite the notable stability issues with Visual Studio 2005, the panel strongly and unanimously recommended Visual Studio 2005 over earlier versions of Visual Studio. Microsoft has also provided additional information.
DDJ: Thanks everyone for making time to talk. I wanted to get some people together who work on a wide spectrum of things. I know with this group, I've got representation for everything from stand-alone applications to distributed systems. Across this group, there's Windows Forms, Web, VB.NET, and C#. As people evaluate Visual Studio 2005, as people start using it, I figured that you would have some great advice and insight for them that might save them a lot of time and trouble. Specifically, I want to focus on the stability of Visual Studio 2005. Right after it released, there were some prominent postings indicating that the product was buggy. It's been out for a few months, you all are using it daily, what's your impression? Is there an issue around stability?
Billy H.:I'll go first. There are three significant issues that I've run into with Visual Studio 2005. One is the 99 percent CPU problem. (Editors note: While working in Visual Studio, the IDE becomes unresponsive for tens of seconds, and the CPU shows 100 percent utilization.) That seems to be fixed now. The possible things that could have been the fix for that are the hotfix, uninstalling Refactor!, and turning off edit-and-continue. (Editors note: Any issues where Refactor! was causing 100 percent CPU have since been fixed by DeveloperExpress. If you are using the latest version of Refactor! you will not experience this issue as a result of the Refactor! add-in. See the response from Microsoft for more details.) I heard from various sources that one of those things might make a difference, and in fact, at least one of them did, because I no longer see that problem.
The second problem is the Windows Forms designer loses its sanity and tells me that there's something wrong with a form. That problem has been reduced, but it's not entirely gone. It doesn't seem to be predictable, it just happens some times for no apparent reason. If I shut the development environment down, and bring it back up, it will be okay again for a while.
The third problem is when it loses its internal references, and it claims to no longer know about an assembly that is referenced. This happens regularly, and predictably, and I can pretty much play around and make it happen. It happens when I'm working with controls and extender providers. The controls appear in the toolbox, and when I drag one over to the form and drop it, sometimes this problem appears. That is frequent enough that I have to tell my audience that this is likely to happen during the course of a demonstration. I do demonstrations a lot, and it happens in front of audiences, and I shut the development environment down, and bring it back up, and the problem is gone.
DDJ: Okay, you mentioned three there. The first is that you're working along, and the CPU pegs at 99 percent, and that was fixed by the hotfix, or turning off edit-and-continue, or uninstalling Refactor!, correct?
Rocky: I can shed a little light on that. I have not yet applied the hotfix, and I have not turned off edit-and-continue, but I did uninstall and reinstall Refactor!, and that did solve the problem for me. It appears that one of the beta versions of Refactor! didn't remove everything from the GAC when you do an upgrade. A lot of us installed beta versions of Refactor! When the RTM version came out, I installed the RTM version of Refactor!, but I had a DLL left over in the GAC. (Editors note: Again, this problem has since been solved. If you are using the latest version of Refactor! you will not experience this.)
DDJ: Ah, so some beta debris. Is anyone else running into common problems? Is anyone seeing lots of: "It did this weird thing once, I can't get it to repeat, but I just keep running into strange instabilities. I shutdown, and restart, and it's okay again for a while."
Kathleen: It's that, but it's more than that. I do a lot in C# and Visual Basic, and I see problems in both. I was a little surprised to hear that the 99-percent CPU problem has gone away. There's a similar problem, though not quite as severe, in C#. For me, the IDE comes up with a little gear icon, and becomes non-functional for 5-20 seconds. It does tend to come back in C#, which is different than the way the problem manifests itself in VB. There are also problems with references that are hard to track.
I have one problem in a form, which I've been unable to solve. I have a form that contains a treeview control. When I open that form in the designer, Visual Studio removes the designer generated line of code that instantiates the treeview. I have to manually put that line back in the designer code section every time I work on that form. There's definitely weird stuff that goes on in other corners of the product.
DDJ: Is it possible that a lot of the problems that people are experiencing are just a result of beta debris? I know that Microsoft provided an uninstall tool to try to help keep previous problems. Is it possible that if people do a clean install of Visual Studio 2005, that they won't see any of these problems?
Kathleen: No, this machine was built clean with Visual Studio 2005.
Billy H.:With my two laptops, one was a clean build, and one wasn't, and they both experience this drag and drop problem.
Bill V.: I'm with Kathleen. Mine are all clean builds to start with. My recent area of focus is a lot different than what I think a lot of other people are working with. I've been working with the CLR integration in SQL Server, using .NET languages to write stored procedures. I've crashed Visual Studio countless times. Most of the time, it's when I'm trying to do remote debugging, when I'm attached to the SQL Server process behind the scenes. (Editors note: Bill Vaughn has great information on troubleshooting connection problems here.) This works reliably about 90 percent of the time. But every so often, the system gets in a mode where it looks like it's starting remote debugging, but it gets lost and doesn't seem to know what to do. I thought I had traced it down to not assigning a default test script, but that doesn't always help. The only way out of this is to shut down Visual Studio. If you just try to stop debugging, that invariably crashes Visual Studio. I've also hit some new nuances that I can't reproduce after rebooting, where the debug manager crashes at the end of a test script. There are a number of things that are flakey. I'm also seeing the "Form is confused" issue now.
DDJ: Is that the "White Screen of Darn" (WSOD) issue? (See Figure 1.)
Bill V.: Yes, that's the "White Screen of Darn".
DDJ: What are some recommendations on ways to get back from the WSOD? I run into that one a lot myself.
Billy H.:That one is the most baffling to me. It seems so intermittent, and there doesn't seem to be anything specific that causes it. But, restarting the IDE seems to fix it.
Kathleen: The ability to go into the Windows Forms designer generated code is required. For example, with the form that eats the TreeView instantiation.
DDJ: That's the file that shows up in the Solution Explorer under the form file, the one that's hidden in VB projects? (See Figure 2.)
Kathleen: Right.
Bill V.: I've found that if I wear white socks, the problems don't happen nearly as often.
(laughter)
DDJ: For me, it's in working with user controls. When you're developing user controls, it's inevitable that you will modify the interface to the control. You'll rename properties, for example. If this control is sited on a form, then the designer generated code in that form will no longer be valid. When this happens, the form will no longer open in the designer. To get the form to open again, you have to go into the designer file that says all over it, "Designer generated, don't modify this!" You have to modify that code to fix the problem and get your form showing again. In the past, if there was a problem with a user control you could still at least see the form. The user control would show up with a red "X". You could delete the control, and re-add it, and probably fix the problem.
Kathleen: I've been lucky in the mentoring stuff I do that we don't have to go into that file very often. Unfortunately at this stage, even with folks new to .NET, you can't pretend that the designer file doesn't exist. You absolutely will have to go in there from time to time to fix problems.
DDJ: Just to narrow this down, some people are running third-party products, but there are still issues even if you're running a clean load of Visual Studio, with nothing third-party installed, correct?
Bill V.: I'm still seeing issues without anything third-party installed.
DDJ: It can't be attributed to beta debris. I can't be attributed to third-party products. Those might exacerbate the problem, but even without those, there's significant instability. Is it possible that maybe this is a perception issue? Is it possible that Visual Studio 2005 is really just as stable as any other release of Visual Studio? When the previous version shipped, blogging hadn't taken off. Every time someone found a bug, it didn't get broadcast around the world. Is blogging the problem? Has it just created an impression that the product is less stable than previous releases, or is there really something different about this one?
Kathleen: It's different with this one.
Rocky: I think it has to be put in perspective. I think it's roughly comparable to the very first version of Visual Studio .NET.
Bill V.: I was about to say the same thing.
Rocky: I think it's quite similar to the original Visual Studio .NET. But then the next version, Visual Studio 2003, had to be one of the best releases for stability that Microsoft has ever done. It just came out of the gate really solid.
Bill V.: 2003 didn't have a lot of new features, but they really did stabilize the product with that release.
Rocky: Yep, I agree. I think the blogging makes it seem worse than it is. And if you're like me, and you get hit with some beta debris, it's really bad. But, having fixed that, and hopefully after I install the hotfix, I'm hoping that almost all of my common issues will be solved.
Kathleen: I did not personally have as many problems with the original Visual Studio .NET as I'm having with Visual Studio 2005. Maybe I'm banging on the product differently now, but I did not have to close and reopen Visual Studio nearly as often. I don't think it crashed as often. And the weird stuff, like having a dialog appear on the left, when it's docked on the right, and then when I click on it and give it focus, it pops back over to the right where it's supposed to be. I don't recall seeing that kind of weird stuff in the original Visual Studio .NET. Now, I did switch to 2003 as quickly as I could, so it's possible that there were more problems than I'm remembering. It's a matter of degree. To me, it's somewhat less stable than the original Visual Studio .NET, and no where nearly as stable as Visual Studio .NET 2003.
Billy H.:I have to pretty much come in at the same level as Kathleen. I did a lot of production work in the original Visual Studio .NET, and my recollection is that I'd have to restart the IDE to get it to regain its sanity maybe twice a week. With Visual Studio 2005, it's more like twice a day.
DDJ: Another hypothesis that I was going to forward, but I think you've preemptively shot it down, is that maybe Visual Studio 2003 set expectations artificially high. In a lot of ways, Visual Studio 2003 was just a massive service pack for Visual Studio .NET. It's logical that 2003 was very stable because it didn't introduce very many new features. It was mainly a big cleanup of the original Visual Studio .NET. However, even so, compared to the original Visual Studio .NET, Visual Studio 2005 is less stable.
Kathleen: It's worse by degree. It's not night and day. Even with the stability problems of 2005, I would choose to work with 2005 over 2003 any day of the week because of the features in 2005. I won't go back.
Bill V.: Agreed.
Kathleen: 2005 isn't so bad that you feel like you can't use the product. However, I do know people who are not moving to 2005 because of what they've heard about stability. They don't want to use something that still feels like a beta.
DDJ: I think some people would say some of these issues aren't technically stability problems. Instead, it's working as designed, the proverbial, "It's a feature!" For example, if the user control throws an exception at design time, or if there's an error in the designer generated code because you've changed the control and that code is no longer valid, then the WSOD, by design, is what you're supposed to see. Do you feel that this is really stability problems, or are things working as designed, but the design isn't really adequate in some areas?
Bill V.: I think a lot of these issues did show up in Ladybug (Editors note: also known as the MSDN Product Feedback Center.), and they were tagged as "Won't fix", or "By design". This happened for issue after issue after issue. Now we're looking at Orcas, and we're talking all these new features, we're talking about LINQ and things like that, and I think Orcas should the 2003 type of release. It should be bug fixes, stability issues, and working really hard on the documentation and discoverability of features that they already have. Push all those new features out to the Hawaii version.
DDJ: Is there any way, today, to obtain the hotfix without actually picking up the phone and calling PSS?
Bill V.: That's totally ridiculous. I called PSS; I talked to three different people. It was a painful waste of almost an hour of my time that I'll never get back.
DDJ: There was a petition. I looked up on the MSDN Product Feedback center this morning, and there was a recommendation that Microsoft not ship Visual Studio 2005. The recommendation was, "Have a Beta 3. It's not ready to release." I don't know when the voting closed on that feedback, but this morning, it had something like 230 votes. For something on the MSDN Product Feedback center, that's a lot. Writers for trade publications picked up on it and wrote articles saying that Microsoft's customers feel that it's not ready. On the other hand, all we had to look at were CTPs, and with CTPs, all bets are off. They are a snapshot, but the quality of a CTP is unlikely to accurately reflect the quality of the final product. Did people see this coming? Should Microsoft have known? Did Microsoft know that the quality wasn't going to be near that of 2003?
Kathleen: I think to get a stable product, we have to have something in the field that's about as good as what we have right now. Now I would prefer to call a Beta, and shake down something that's 98 percent of the way there. I think that would get the final product correct. But we desperately needed this releases to ship last fall. That's particularly true in Windows Forms because we can't release production stuff on Beta software. If I was inside of Microsoft, and someone had said to me, "You make the call. Do you ship now or wait?" I'm not sure I would have said to wait. Even though it's a pain to work with, there were a lot of people out there waiting for this to release. They had stuff that they wanted to get to the field. The .NET runtime is stable, so I'm not sure I would have delayed the release because of the development environment issues.
DDJ: Let me get other people's impressions on that. Given what we know now, if you had to make the call to ship back in November, would you have pulled the lever to ship it? (silence)
Bill V.: That's a tough call.
Billy H.: It is.
DDJ: Let me maybe make a distinction. Are we talking about something that's a tool problem, or is it the tool and the Framework? In other words, is it an issue where the development environment is unstable, but the underlying .NET Framework is solid, so that you can have very high confidence that the applications that you build against the .NET Framework will run well, and be stable for your customers, even if the tool that you're using to build them gives you grief?
Bill V.: Some of the problems related to Data Access are in the Framework, and the tools can only be as good as the Framework. I think it's both.
Billy H.:I don't have anything in production yet on 2005, but I haven't seen any issues with the Framework that concern me.
Kathleen: In my experience with Windows Forms, it's pretty good. There have been a couple issues, but I'm not worried about release.
Bill V.: One thing about the Framework, if you do run into an issue, you just code around it. You just know that there's a pothole in the road at mile 45, and you drive around it. It doesn't have to affect the stability of your application.
DDJ: So any Framework issues that you have seen fall into the category of things that are repeatable, not intermittent?
Bill V.: The thing I've seen have all been, "Okay, the Framework does it this way, so I'll have to code it like this."
Kathleen: I feel the framework does hit the mark for stability.
DDJ: I've focused on stability, but looking at the product as a whole, and you've alluded to the fact that there's so much new functionality in here. What do you recommend to people? Do you recommend that they wait for the first service pack? Do you recommend that they wait for the next release? Or, do you recommend that they move forward to 2005, as-is?
Kathleen: Move forward.
Bill V.: Move forward.
Rocky: Move forward.
Billy H.:Move forward.
DDJ: Wow. The responses came pretty quick, and were unanimous that people move forward. So even though we've spent a lot of time taking about stability issues, when taken as a whole, you feel the product is a big improvement? You feel the productivity enhancements and the new Framework are that compelling? And is that across the board? Do you make that recommendation for Web and Windows, for C# and Visual Basic?
Kathleen: I can't speak for Web, but for Windows Forms in C# or Visual Basic, I recommend moving forward to 2005.
Rocky: In my mind, it includes all of them. Magenic has been doing Web, Windows, Visual Basic, and C#, and no one is willing to go back to 2003.
Kathleen: I won't take a job that makes me go back. I will turn down work before I will develop using Visual Studio 2003.
What I think Microsoft should do for their long term plan is have a point release planned for one year after a major release like 2005. For clients that I'm working with, it would be really nice if I could say, "Look, lets just wait three months. A year after release, you're going to see an update. I understand that you don't want to feel like you're working with a Beta product." If we knew that was coming, and that was the focus of the next release, then those people who need that comfort level could wait. And then another year, or year and a half after that, we could see spectacular new features, because like you said, we do think everyone should move forward.
Rocky: This might be a bit of a tangent, but I think that historically with .NET, Microsoft has tried to synchronize the release of Visual Studio to a curve based on a new release of the .NET platform. That didn't use to be the case, especially in the VB world. COM and Windows didn't really change much, and we got VB 4, 5, and 6. I would like to see us return to that model. The focus has shifted so much to be on the framework that we've lost sight of what the dev tools can do for us. In some ways, that's too bad. Instead of Visual Studio leading the way, and saying, "Hey, we could solve this issue, or that issue." And then later the Framework could come along and incorporate the idea. Instead, it's the other way around, and the .NET platform always seems to be ahead of the tool.
DDJ: And that's what's driving a lot of this problem. I'm hearing people say, "Make Orcas the stability release," but we know that a lot of new technology is coming. We know that LINQ, WPF, WCF, and WWF are coming. We know what people will say if there's no designer experience for those. Do we really want Microsoft to focus on stability in Orcas, at the expense of support for these new Framework things? Do we want Microsoft to focus primarily on great tool support for these new paradigms, or is stability more important, even if the tools don't support those paradigms as fully as we might want?
Kathleen: Well, I could wait for things like LINQ.
Rocky: With Orcas, they're focusing, hopefully, on stability, and then only support for the new layers in WinFX. I think if they get in the habit of doing that, and this is probably a pipe dream, but then maybe we could see a release that's post-Orcas, that similarly says, "We're going to do a release of Visual Studio, and it can't change WinFX, it can just add new developer productivity."
Eclipse is an interesting model. It's independent of Java and any of the other technology that it targets. The upside is that they're able to do some things in the tool that Microsoft has locked themselves out of doing. But then to be fair, the down side is that Eclipse can't really integrate as deeply with a platform.
DDJ: We've all released software, and we all know that there's always a little bit of holding your breath for the first 24 hours after you've shipped. You hope that all your testing and work that you've done proves itself in the field, and the product works without a hitch. But we've all been part of things that have shipped that probably haven't worked as well initially as we would have hoped.
Let's just say, for the sake of argument, that anyone can ship a buggy release every once in a while. So now that it's out there, what do you, as a customer, want from your software vendor?
Kathleen: You mean in addition to a service pack that fixes these issues that we've discussed?
DDJ: Okay, so a service pack, is that what people are looking for at this point? Microsoft has said that they'll have a service pack in Q3 of this year. Is that good enough?
Kathleen: Other than just sticking their finger in a hole in the dike here and there, I think 9 months to a year is reasonable, and it's just what we'll have to live with. I want the service pack done right.
Billy H.:It depends on accessibility to the things that the service pack will contain. If I have to be on the phone with PSS to get a hotfix, then I want the service pack sooner.
Kathleen: I think the hotfixes are the fingers in the dike. If they need us to sign something saying that we understand that the hotfixes have risks, and they haven't been tested to the same level as a service pack, if that's what it takes to get them into our hands sooner, then I'm all for that.
Billy H.:And that takes the problem of blogs, where information spreads very quickly, and turns it around so that blogs help instead of hurt. That's where people can find out about a hotfix, and if the hotfix if easily available, and you don't have to call PSS to get it, then that's good. On the other hand, if you see in a blog that there's a hotfix, but you have to call PSS, then it just makes the whole fact that you even need this hotfix more frustrating.
DDJ: Rocky, one thing that you touched on was that you'd like to see the tools decoupled from the Framework so that they could rev independently.
Rocky: I don't think it's healthy for the platform to change radically and often the way it's been changing.
DDJ: What about other dependencies. If Visual Studio 2005 didn't ship, then SQL Server 2005wouldn't ship, and Team System wouldn't ship. There's a log jam of Microsoft products backed up behind Visual Studio 2005. The dependencies don't just go up the stack from the Framework to the development tools, but also across some really large products. What are your thoughts about the number of things dependent on Visual Studio 2005, and version 2.0 of the .NET Framework. Does that make the problem worse?
Bill V.: Dependencies have always been an issue, and it's a growing issue. The operating system will be dependent on the Framework. Office will be more dependent on the Framework. As these other teams want change, it just makes things far more complex than it used to be.
Rocky: I agree with Bill, and yet I honestly think that it has the potential for an upside. One problem that we often face is that Microsoft often tends to hire a lot of young, smart people, who have never worked in business. They've never worked in IT. They build compilers, and they build tools, and I think they generally do a wonderful job, but they really don't have any idea what it's like for us. We build stuff that's always dependent on Windows, .NET, and SQL Server. By definition, all the stuff that we build, whether it's Windows or Web, is dependent on a broad set of Microsoft technologies. And we're vulnerable to them changing any one of those pieces. Well maybe, Microsoft itself, by accepting some of these dependencies, will start to understand our pain, and will come up with interesting ways to address it. Basically, if they fix their own problem, they will inadvertently fix many of our's also.
DDJ: That's an interesting perspective. On one hand, yes, the SQL Server team probably filed a lot of bugs. On the other hand, the SQL Server team was probably saying, "You have to ship, because we have to ship!" And I guess that's no different than customers who start building products based on a Beta version, because they've been "promised" a certain release date for Visual Studio. They also need the Framework to ship, because they can't ship until it does.
Kathleen: As somewhat of an aside, the most expensive decision I ever saw regarding moving forward was to not move forward. Not moving forward can be as expensive, or even more expensive, than moving to the newest version. It turns into this big gamble for companies that have real people driving trucks or making doughnuts, to decide when to move forward to a new technology, and a lot of it comes down to how much they can trust the release dates announced by Microsoft or any other company.
Billy H.:I guess I'm just pessimistic that this won't get any better. The problem is that we have so many platforms now. We have the Windows platform, and the .NET platform, and the SQL Server platform. Soon we'll have changes in the form of WinFS, which changes the platform. You pretty much have to have all that stuff working right, before you put anything on top of it. As bad as it is to have products wait on other products, I think it's even worse to do things incrementally. Part of the problem today is that Windows XP doesn't have the .NET framework on it. The platforms got out of sync. As much as I hate the delays, I think the platforms have to be synced up, to be the fundamental foundation on which we build.
Rocky: I really don't think this current rate of change is sustainable in the long run. I don't think that the corporate world is going to put up with it. For any investment they make in Windows or Web right now, they have to be concerned about how much of that will change with Avalon. If Microsoft turns around after Avalon, and comes out with more radical changes, I think they really do run the risk of losing people.
DDJ: It sounds like the core question is quantity vs. quality. I think the question to Microsoft is, "You know that you're going to have tool support for all these new technologies, like WinFX, Atlas, and so on. These new technologies aren't small things. How can you add in tool support for all those technologies, in a relatively short time frame, and still insure that the tool is stable and high quality?" It seems like a tall order.
Kathleen: But we all said that we want the new features. We all said that we wouldn't go back.
Bill V.: I think the third parties could expand their role. If they knew that the platform would be stable for a long time, and they weren't going to have to rewrite their stuff every couple of years, they could go a lot farther.
DDJ: But we've all said, "Please, Microsoft, put this feature in the box so that I don't have to go to a third party for something that's this fundamental. I don't get the same support from a third party. Their stuff is often practically undocumented. It's not as stable. Loading add-ins can hurt the stability of Visual Studio." Don't get me wrong, I end up using 3rd party products in every application that I work on, but it's one more layer of stuff that can cause problems.
It almost sounds like we don't know what we want. On one hand we're saying, "Stop! You can't change this fast." And then on the other hand, we're saying, "The changes you made for 2005 are so good that I'll never go back." The changes that they make for 2007 will probably be just as great. As soon as we see them, we'll say that we can't live without them, and we'll say, "What's taking so long to ship the dang thing?" Once we get it get it, we'll say we won't go back. If it's not stable, we'll cuss about it not being stable, but we'll use it and recommend it anyways. Are we just at a point where we have to resign ourselves to a certain level of frustration? The technology is going to change fast, and while in abstract, we don't like the rate of change, when we see specific features, we want them very badly. We'll push to have it ship soon because we want to use it for new products, and then when it does ship, we'll point our fingers at it and say, "It should have been more stable."
Rocky: The problem, I think, is that it's all being driven by geeks, and we're geeks too. Most business applications are forms over data. All of these new technologies exist to feed the technology frenzy. They don't actually make it any easier for the user to type in the data that gets entered into the database. None of this stuff is really benefiting the user. It makes it prettier, whatever, but it's all technology driven for technology's sake. That's all very cool, and as geeks, we all love that. Microsoft loves it because they're all geeks too. But I just wonder how sustainable this rate of change is in the long run.
DDJ: Everyone, thanks for taking the time to chat.
This article raises a number of different and widely varied issues regarding the release of the Visual Studio 2005. Microsoft is proud of the quality of Visual Studio 2005 and the .NET Framework. We worked with thousands of customers through the development process to ensure the quality of the product. At the same time, these are complex software projects and we recognize that some customers may run into issues. We take these issues very seriously and are working to ensure that they're addressed in a timely fashion.
There are a couple of interesting points that I want to highlight from the article. The first is that everyone who participated in the interview recommended that people immediately adopt Visual Studio 2005 and the .NET Framework 2.0. They feel, as we do, that the improved functionality is a tremendous step forward for developers regardless of whether they are building Windows, Web, Office or Mobile applications. The second interesting point is that the issues that were raised were almost universally around the behavior of the tool.
The article starts by raising issues that cause product instability with the designers and the compiler. Several of the solutions that the MVPs recommend, such as uninstalling third-party products and disabling Edit and Continue, are things that we asked them to try as a part of helping us to debug the issues that had been raised by the community. Some of these issues are now addressed in the HotFix available by calling Microsoft's Product Support Services and referencing KB 915038. We are in the process of combining this HotFix with another fix that is currently being verified by customers and will post these as a freely available General Distribution Release (GDR). As the article points out, we are also working towards a general Service Pack that will be available in the third quarter of this year.
However, Microsoft has never recommended either uninstalling third-party products or disabling Edit and Continue as a part of a permanent solution to the problem. The interviewees also raised some questions about Developer Express' Refactor! product. There was an early issue with that product that impacted developers who had installed the Beta, but that has now been addressed. The Visual Basic team worked with Developer Express because we felt that this product added significant value to the VB development experience and we continue to believe this.
The White Screen of Darn (WSOD) is the screen that is displayed to users when a designer fails to load. In previous versions of Visual Studio we tried to show the designer at all costs, and only showed the WSOD in extreme cases where we could not locate a designer. In Visual Studio 2005 we changed this behavior, since showing a broken designer can cause loss of work where broken controls are deleted from the designer and all of the work put into creating and customizing them is lost. By using the WSOD we are trying to bring attention to the errors that appear in the Visual Studio task list so that the user does not continue to work on a broken project. Errors that can cause the WSOD include broken user code that is run at design time, or a deleted or missing reference that is relied upon by components in the project. We recognize that these issues are sometimes hard to diagnose, and we are working on ways to make the process easier.
Beyond the specific issues discussed above, we remain committed to producing the industry leading development experience in terms of functionality and product quality. One of the key initiatives in doing that has been the Developer Division's focus on increased transparency throughout the development cycle. This has manifested itself to developers through efforts like the MSDN Product Feedback Center and our frequent releases of Community Technology Previews (CTPs). Because of these and other community initiatives, we've received significant feedback about the product, which has given us an enormous amount of valuable information about what customers love and about areas where they feel that we can improve.
A related issue that's raised in the article is how Microsoft can guarantee a quality release for Visual Studio "Orcas" given that we are adding new functionality to support WinFx. This effort continues to build on the product quality and transparency initiatives that we initiated in the Visual Studio 2005 release. Customers can expect to see us releasing CTPs throughout the product cycle--including some of the early CTPs that we released before the Visual Studio 2005 product even shipped. We encourage customers to download these CTPs and to provide feedback through the MSDN Product Feedback center. We realize that not all of our answers will be the "thing you want to hear" but we are committed to evaluating each issue that's raised and addressing it as appropriate.
As software, including Visual Studio, gets more complicated we need to enhance our processes in order to ensure that we continue to ship quality software. In an earlier blog entry, S. Somasegar, the vice president of the developer division, talked about our MQ efforts and the ways that we're improving our internal processes. Additionally, we've made a conscious effort to ensure that the "Orcas" release is focused on the right features to meet customer requirements. We know that professional developers will depend on us for providing tools support for Windows Vista and the 2007 version of the Office System, so we have concentrated team efforts on ensuring that our technology solutions in these spaces are rock solid.
Kathleen Dollard has been developing business applications for over 20 years, programming in Visual Basic for almost ten years, and working with .NET since the early betas. As an independent consultant, she has had the opportunity to work in a variety of domains, including the finance and justice sectors. Kathleen has worked extensively with application code generation and is the author of Code Generation in Microsoft .NET (Apress). Kathleen is also a long time Microsoft MVP, president of the Northern Colorado .NET SIG, and is an active member of the Denver Visual Studio User Group.
Billy Hollis is the author or co-author of a number of books on .NET, including the first book ever published on Visual Basic. NET. Billy is a Microsoft Regional Director and MVP, and was selected as a .NET Software Legend in 2002. Billy has his own consulting practice for training, consultation, and software development on the Microsoft .NET platform, focusing on .NET architecture and design, advanced smart-client systems, Tablet PC, and commercial packages.
Rockford Lhotka is the author of several books, including Expert VB and C# 2005 Business Objects and related CSLA .NET framework. He is a Microsoft Regional Director, MVP and INETA speaker. Rockford is the Principal Technology Evangelist for Magenic (www.magenic.com), a Microsoft Gold Certified Partner.
William (Bill) Vaughn is an industry-recognized author, mentor and subject-matter expert on Visual Studio, SQL Server, Reporting Services and data access interfaces. He's written six editions of the Hitchhiker's Guide to Visual Basic and SQL Server. He and Peter Blackburn also wrote the best-selling and critically acclaimed Hitchhiker's Guide to SQL Server 2000 Reporting Services.
Scott Swigart spends his time consulting, authoring, and speaking about converging and emerging technologies. With development experience, going back over 15 years, and by staying in constant contact with future software development technologies, Scott is able to helps organizations get the most out of today's technology, while preparing to leverage the technology of tomorrow. Scott is also the author of several .NET books, a certified Microsoft trainer (MCT) and developer (MCSD), and a Microsoft MVP. Feel free to contact the Scott at [email protected].
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.