Carl Franklin

Does this include the Express versions as well?

I have a clean install of VS2005 on Win xp machine. I have build and successfully deployed a Windows App on multiplle machines and I did not experience any bugs. I must that it's pretty stable. I first installed the Launch (std) edition and then, middway in the project, I seamlessly upgraded to Professional (MSDN download) and it's all good and rock steady.

I think I understand your ground rules. I did install Resharper beta and it failed. Uninstalling it cured the system. NUnit works very seamlessly too from the solution explorer but I can't get to may a key to it with TestDriven .NET.

Erwin,

Yes, but keep in mind, having old beta versions of express products can really screw up the release version of Studio.

So why can't we tell stories about machines that had beta versions? Doesn't Microsoft have a responsibility to clean up thier own mess?

Tim Murphy

Beta means never having to say you're sorry.

i agree that beta machines should be included. go-live was provided for the tools, so that uninstall environment should be included.

Regarding betas,

1) We're talking about the state of the final product. The final product does not include beta software or beta removal software. In order to test the software correctly, it should be as far away from beta bits as possible.

2) Get your own show. :-)

Why limit this to just XP? I'm developing on both XP and 2003 (both are clean installs). Is Microsoft realisticly expecting VS.NET 2005 to only be used on XP?

Here's my setup and a short list of my problems:

Platform:
Windows 2003, SQL2005, VS.NET2005 Pentium D 820, 2GB PCI 5400, 250GB Mirrored SATA storage.

Application:
DotNetNuke 4.0

Random compilation errors that do not show up when you build the solution, only when you run the page. Yes it says Compilation error and gives specific lines of code to look at.

UserControls lose property pane access when they have a compilation error (even though the solution successfully builds)

UserControls dissapear from intellisense when they have compilation error (see above)

Random problems with dll's after building a solution. You go to run the page and it cannot find/access/verify/etc a random dll. Recompile again and it works fine.

IDE takes way too long switching from HTML view to Design view, over 1 minute in some cases. (just opening the DNN4.0 project requires over 350mb of memory)

Most recent problem was a compilation error that only showed up when trying to run the page. It said a duplicat type was found. rebuilt, restarted the IDE, restarted the aspnet worker service, restarted the server, nothing fixed it. Had to remove a random node from the web.config file to make the page generate a different error and then put the node back in. This fixed it temporaraly.


I've got more, but all of this is happening on a fresh install of win2003, VS.NET 2005, and SQL2005.

So you're trying to find out how people get by if they're working in a completely unrealistic setup of VS 2005? Hm...

Personally I haven't had any real problems with VS 2005 at all, although I do use VMWare, CodeRush, Refactor!, TestDriven and lots of the additional packages for Office and InfoPath support, things like that - and I had two different betas on the same machine before installing RTM. I don't know how much of a difference that makes to VS 2005 stability, but I don't think there's much to prove by showing that if someone didn't do all the things everybody does, he wouldn't have any problems.

Why the limits? Seems logical to me.
If you want to isolate the problems, you want to look at as clean a setup as possible as well as a real life setup. And this is about the former.
And after you found the clean setup problems you can use those findings to look at real life situations and try to figure out which part of the problem is VS2005, which are other factors and what are matters of interaction.
And why XP? Most people have that, less have W2K3, so that is being pragmatic, I think.

I've built and deployed three Smart Client Apps, a Compact Framework application and a small web application using 2005 and haven't run into any bugs or crashes yet.

Also, if you've installed Beta software on a production machine you deserve any problems you're having.

Alot of my 2005 issues all seem to relate with the old VSS driver we need to use around here.
That's the only difference between the home and work machine.

I am using VS2005 to create a large web application. Everytime I edit a CSS file, save it, edit it, save it again, the IDE process is killed.

Currently I am using textpad to edit all my CSS files, which is pretty sad.

I am using Vs2005 RTM. I did have the sql 2005 beta installed previously, but I don't see how this could affect the VS2005 CSS edit functionality.

This is the only bug I have noticed so far, but it's incredibly annoying because I often forget about it.

I have not had any problems with VS 2005. I haven't come up with any bugs, and everything has run just great.

I haven't had any problems and I have had previous betas on my machine.

For those of you who complain that MS should cover those machines that had betas on it.... MS has always said that you should never use beta software on machines that you rely on. Why should they have to spend the time and man power on a problem that we created ourselves?

1) Web (ASP/JavaScript)
2) Bug
3) Yes

The IDE is non-responsive for a second or two when I open a Classic ASP page. I have the .asp file extension mapped to the Web Forms Editor so it doesn't the syntax highlighting for VB and HTML/JavaScript correctly. Almost everytime I open an existing file it become non-responsive for a second or two. Sometimes it doesn't become non-responsive until I try to click on the code to edit or try to scroll. This is quite annoying. And my machine qualifies to the criteria you stated.

So far I've only encountered great support for obsolete namespaces in a smooth app upgrade path from .NET 1.1 to .NET 2.0. I had a looming fear of finding/fixing unsupported properties and methods, but the IDE's support has been great.

Re the clean vs beta-laden systems...duh, think "running in a responsible production environment". If having a beta in such an environment is acceptable in your shop, good luck and keep on "justifying" it.

I have found VS 2005 to be quite stable. I primarily build interfaces for databases so I do not use all the avaiable controls. However the database tools have saved me many hours and work great. Connecting my business objects is simple and the Table adapters are very usefull. I have deployed three smart client apps with no problems as well as integrating with Mapforce, an XML data mapping app.

I'm just going to tell you, man. I've done everything to my PC (running XP) with the Beta except piss on it and I've never had a problem. I love VS 2005 (VB.NET, of course). If you want to limit the responses why not exclude SQL Server CTP installations (a few real problems there), VSS Beta (OMG!), 3rd party libraries (DevExpress 2005 - Suite) etc. Your show rocks but your survey lacks balls

> If you want to limit the responses why not exclude SQL Server CTP installations (a few real problems there), VSS Beta (OMG!), 3rd party libraries (DevExpress 2005 - Suite) etc.

We did. In fact, we're requesting no VPCs, no beta versions currently or previously installed, and no third party products. We didn't want to limit the responses, per se. We just want to filter out problems people are having because of issues with other software.

> Your show rocks but your survey lacks balls

Perhaps you could make a suggestion?

Sorry, a buddy of mine said I was too rough on you. And, since we are now installing the production version of VS 2005 we see that MS states that all Betas should be removed first. That is good business, but my point is that VS 2005 will have to work with other software. So, let's hear about those experiences too. In other words, where are the problems? What causes them? The best defense of the product is to show that it runs well with some load - something that stresses it. And finally, I respect the fact that you didn't just remove my flame. Thanks

> VS 2005 will have to work with other software

That's true. But before we can tell if interacting with other software causes problems, we have to know if the product is stable by itself, no? What I'm trying to do is establish that it works in a vaccuum first, and then slowly introduce other products to see if interactions with those products are troublesome.

> I respect the fact that you didn't just remove my flame.

That's not a flame. Any one of the flames on this page run rings around your so-called flame:

http://weblogs.asp.net/cfranklin/archive/2005/07/07/418284.aspx

Smart trouble-shooting must consider isolation. If I want to check my TV picture problem, I first turn off the VCR and try. Carl's constraints only make common testing sense. Most testing assume a certain set of 'givens' for the collected data to be useful for much.