bharry's WebLog

Hi,

Just wanted to relay my problems with VS2005.

For a long time - it would take ages to start up. I mean 40-60 seconds spent trashing the disk and showing the splash screen.

I installed the SP1 Beta - hoping it would resolve the issue. It didn't.

So i went investigating (with filemon from sysinternals) - and realized that 99% of the time spent was writing to the following files:

User.vsk and Current.vsk located in the folder:

C:\Documents and Settings\Vlad Ivanov\Application Data\Microsoft\VisualStudio\8.0

I backed up the files just in case and deleted them.

Upon the next start - VS2005 started instantaneously.

So there. Is it a bug or something could be done to prevent it from happening - i don't know. I spent no time researching the problem. Just thought it might be useful for your team.

So far so good, I haven't seen my IDE bomb and send an error report to Microsoft since I installed the SP1 Beta (and that used to happen almost daily to me).  The debugger stepping seems to be faster and it looks like when running unit tests, it will rebuild your base projects now (I don't think it used to do that which would drive me nuts since sometimes I would forget to do a build after a fix and wonder why my fix didn't work)

The install did take a really long time (so long that I almost thought it wasn't working), but so far, my impression of the SP1 beta is very favorable.

Vlad, thanks for your information on VS 2005 startup performance.  I've logged a bug with the information provided, but would appreciate it if you can contact me at DevPerf@Microsoft.com with your contact data in case we need to follow up with you on this.

Anyone else with performance issues in VS 2005 (including TFS) is welcome to contact me at the same e-Mail.

David Berg

Microsoft Developer Division

Performance Engineering Team

I deleted my vsk files and startup went from >40s to <10s. I'm not running SP1.

VS seems to work ok, but is this 'recommended'?

Hi David,

I logged the bug in Microsoft Connect for VS2005 SP1 Beta - just search for "user.vsk" - it's under Vincent Evans (i go sometimes by that pseudonim). My contact info there is accurate.

Will this include hotfixes for the framework like the one below?

http://support.microsoft.com/default.aspx/kb/913177/

It seems to me a lot of my problems are in the framework itself. Asking our users to install a stack of hot fixes not available via Windows update is hard.

Sourcesafe doesn't appear to be included in this Service Pack.

We are using the hotfix for KB915312, as we were seeing data corruption from binaries that we check into sourcesafe.  We also see regular crashes with Sourcesafe, both with and without this hotfix.

Is the Sourcesafe Service Pack going to appear seperately, at the same time, or will it be included in the final build?

The time it takes to install was somewhat long overall but the real problem was the amount of time it took after launching the installer to start interacting. (I had already downloaded it to my local hard drive.) It took so long that I ended up actually launching twice thinking that my double-click hadn't taken. It had no UI at all for a minute or so.

Paul

Follow up to Vlad Ivanov and FreeToDev:

The *.VSK files are Visual Studio Key Bindings.  So if you delete them, you loose any custom key bindings you have.  The sample files we have appear to be corrupted for some reason, which may be the cause of the performance issue.  We're continuing to investigate.

Feel free to send additional information to me at DevPerf@Microsoft.com.

David Berg

Developer Division Performance Engineering Team

Microsoft Corporation

Brian Harry on Visual Studio SP1 Feedback and The Training That Just Won't Die. Eric Jarvi on VSTS...

Adding domain  users to global groups doesn't work from Visual Studio, whereas the adding of domain groups does.

When adding the user via tfssecurity, it works. Maybe it's a problem of the TeamExplorer plugin for Visual Studio (the error message is "TeamFoundation Server could not resolve the user or group <Displayname>..."

There is a known problem in the RTM TFS server adding domain users or groups that have special characters in their common name (parenthesis and slashes).  I just checked, and the fix for this problem is in the SP1 source tree.  Note that since the problem is on the server, you must have patched the TFS app tier, not the client.  I don’t have the exact version number for the SP1 server, but the RTM build is 50727.147.  If you check the file C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Services\ Microsoft.TeamFoundation.Server.dll version, it will tell you if you have SP1 installed on the server.  If you do have SP1 installed on your TFS Server, please log a bug against SP1 Beta and include your contact information.

Matt Hoover

Software Design Engineer

Team Foundation Server

You asked for bugs bothering people:

The following bugs really annoy anyone doing cross platform development or using source control systems with Visual Studio (look at all the comments on the votes).

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=184136

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=220944

Thanks for forwarding the report.

It's probably not your fault, but I must say I'm a bit perplexed about how the Visual Studio team handles serious bugs.

While I can understand that you don't want to ship untested bug fixes in a Service Pack, what I do not understand is that you're willing to live with serious unfixed bugs in your product until the next release comes out in a (few) year(s). Here I'd define as a serious bug any bug that either causes compiled code to malfunction (especially if it's difficult to detect) or a bug that disrupts the work flow of developers. As a "tool builder" I just wouldn't want to be "responsible" for the potential consequences...

Brian,

Thanks again for all your efforts.

I might take the support route for the file name bug. Other bugs, especially compiler/library bugs which only show up at run-time, I might not be aware of until it's too late. And even if I could get hotfixes through the support, I can't tell every client to call Microsoft support before compiling my source code library.

I think there is a strong case for more frequent updates of developer tools, especially compilers. A long development cycle focused on fixing bugs in the first half and developing features in the second half doesn't strike me as a very responsible one.

Let me give you two example of competitors with a different approach to bug fixing:

Intel makes available new minor versions of its compiler products every few months. These download versions incorporate bug fixes for issues found during the last months.

WingWare usually fixes bugs in its (pretty sophisticated) Python IDE within a few hours and offers patches through an online update mechanism integrated into the IDE.

Just wanted to say again that your initiative is very much appreciated.

Service Pack 1 (SP1) for Visual Studio 2005 clients and Team Foundation Server is scheduled to release

Service Pack 1 (SP1) for Visual Studio 2005 clients and Team Foundation Server is scheduled...

I am using VSS 2005 & VS 2005. After installing SP1 Beta to VS2005, sourcesafe "updating" performance suffered very badly when opening a web site project which only includes classical "asp" files.

Before installing SP1, it always checked 100 files per "tick", while it is now checking 10 files per "tick" after installing SP1 Beta.

Ünsal,

Thanks for reporting this.  It's a known regression in the SP1 beta SCCI performance.  It has already been fixed for the final SP1.

How can I tell if SP1 installed? Mine choked on the 1st attempt (CPU heated up, so I left the windows open all night, stuck a big box fan on the computer, and lay in my sleeping bag on the couch while the 2nd install took place).

I can't see anywhere that it tells me that sp1 was installed. This usually is pretty easy to find.

Cheers,

John A. Davis