Lance77035

It seems that we cannot do anything in Visual Studio 2005 without surreptitiously going out to SourceSafe and churning for 3-5 minutes.  Granted we have (unavoidably) made the mistake of placing the SourceSafe database on a network file share -- it does not explain these covert and constant SourceControl accesses.

For example, loading the project does something like "verifying source control".  Why do we need to verify anything and why does it take so long   I can launch SourceSafe myself and verify faster than the IDE can.

Refreshing the solution (recursively) appears to be doing just that -- RECURSIVELY refreshing the solution -- meaning the refresh of the SLN file causes a refresh of the child projects, and then the child project get refreshed AGAIN.  This is especially evidenced if you select ONLY the SLN for get latest and de-select everything else.  It goes and gets EVERYTHING again.  This is also evidenced if you currently have a file checked out -- it will ask you if you want to replace the file -- then after a few minutes it will come back and ask you AGAIN!

Lastly, I am finding that simply clicking to expand a folder node in the Solution explorer for my web project is causing SourceSafe activity.  I click the folder, wait 3 or 4 minutes while it accesses SourceSafe, then I click one of its subfolders, and have to wait 3 or 4 more minutes.  This is absurd.  I can see it accessing source control using FileMon, otherwise you'd never know what it was doing.

We have also seen this sort of surreptitious updating of source files at random by simply clicking on a node in the Solution Explorer.  Suddenly, though you've made no changes locally, your local solution no longer compiles because VS has secretly brought in select new pieces of code from SourceSafe!

Further... I just tried closing my solution... nothing modified at all... and I'm still starring at a frozen UI and see through FileMon thousands and thousands of Sourcesafe file access occurring with no end in sight.  For what

What can I do to control these incessant and unwanted accesses to SourceSafe

Thanks!



Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Richard Berg MSFT

You can turn off some of the automatic SCC features in Tools -> Options -> Source Control.




Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Lance77035

I already looked there and the only setting that appeared relevant was "Perform background status updates", which I've already de-selected with no apparent benefit.



Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Richard Berg MSFT

Look on the "Environment" page. Unchecking "Get everything when opening a solution" and setting "On Edit" -> Do Nothing are the most important.




Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Lance77035

None of the checkbox selections on the Environment page have been checked. "On Edit" is set to check out automatically, but doesn't that just mean that when I attempt to start editing a source file that it will check it out for me if it's not already I don't see a possible connection between that setting and the long running and untimely accesses to SourceSafe.

One thing I read was regarding VS2005's behavior where it goes (unprompted) out to SourceSafe to get the current status of all files just for the sake of updating the icons displayed in the Solution Explorer. My hunch is that this occurs every time you click a folder node in the solution, and maybe in other cases as well. That article described changing a setting in the registry, but I already had the suggested value anyways, and I believe the article was in reference to C++.





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Alin Constantin - MSFT

"Lastly, I am finding that simply clicking to expand a folder node in the Solution explorer for my web project is causing SourceSafe activity. I click the folder, wait 3 or 4 minutes while it accesses SourceSafe, then I click one of its subfolders, and have to wait 3 or 4 more minutes. This is absurd. I can see it accessing source control using FileMon, otherwise you'd never know what it was doing."

Lance, websites in VS2005 work that way. The web project package (Venus) does not discover the files in the website until the nodes in solution explorer are expanded. Only when a node is expanded, the Venus package calls scci to let us know the project has more files in it - and this is when scci has to hit the scc database to retrieve the scc status of the newer files "added" to the project. A possible workaround is to use web application projects instead of websites (WAP are project based instead of folder-based, and Venus package knows the content of the project from the project file, therefore it can tell scci which files belong in the project when the project is open)

"We have also seen this sort of surreptitious updating of source files at random by simply clicking on a node in the Solution Explorer. Suddenly, though you've made no changes locally, your local solution no longer compiles because VS has secretly brought in select new pieces of code from SourceSafe!"

Hm... This sounds strange. To my knowledge scci package doesn't do "secret" Get operations without user interaction. Is it possible you're checking out some files (or editing them which causes a checkout on edit) VSS can peform a GetLatest during checkout, and the latest version may not be anymore buildable if the whole project is not in sync. If you're using VSS2005 you may mitigate this by using checkout local version feature (in SSExplorer, Tools/Options/General "Always checkout working folder version").

"Further... I just tried closing my solution... nothing modified at all... and I'm still starring at a frozen UI and see through FileMon thousands and thousands of Sourcesafe file access occurring with no end in sight. For what "

There must be some accesses to the VSS database when closing the solution (VSS has to close the connections opened to the database, flush any unsaved changes to ss.ini files, etc). However, I don't expect these to be thousands and thousands of accesses. Do you have by any chance set in VisualStudio Tools/Options/SourceControl/"Checkin everything when closing a solution or project"

Alin





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Lance77035

Concerning folder nodes in the "Venus" project, I did read that VS goes to source control for the purpose of updating icons.  But really, for such a small number of files in our folders (avg 3 or 4) it sometimes takes up to 3 or 4 minutes.  Just not sure what it's doing here.  I'd expect better performance from a modem, let alone our LAN.  I cannot imagine the painful labor it is going through to find those file statuses.

The thing with files unexpectedly being discretely refreshed from source control has not happened in a while.  Not 100% sure what was going on when it was reported earlier -- probably will never reoccur.

Regarding the source control setting you mentioned, I do not have any of those optional settings enabled on the "Environment" page, including that one.  We don't like implicit behaviors.  When closing the solution I don't usually have more than a couple of items checked out anyways, and I keep those checked out until I am ready to check them in myself.  Although, it's not every single time I close the solution that it goes off on a source control feeding frenzy.

But still it seems I cannot do anything in Visual Studio without heavy, LONG-running delays from constant source control interaction.  The one major delay that always takes a long time (minutes) is loading the solution and "verifying source control".  Not at all sure what that this is for.

Also noteworthy is the significant amount of time it takes when I want to check the SLN file into source control.  I right mouse the solution node, and select "Check In...".  It goes off for *minutes* before producing the dialog where I can confirm my selection.

Just very frustrating and I can't seem to find any options to minimize these seemingly unnecessary and overabundant accesses to source control!





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Alin Constantin - MSFT

Hi,

Are you sure the string in status bar is "verifying source control"

Definitely the source control integration package does not contain this string (try for yourself to search it in VssProvider.dll or VssProviderStub.dll with a resource editor). The string we display is "Updating source control status...", and we certainly don't have anything to "verify". I'm searching now the rest of VS packages strings and I don't find such string.

BTW, which version of VSS are you using Is it possible you have VSS 6.0 and experience the same problems as in this post http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=837677&SiteID=1

Are you running any antivirus (either on your machine or on the machine hosting the database) If yes, can you turn it off and see if it influences anything (in the past we had problems with antiviruses interacting badly with VSS and causing performance regressions)

Alin





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Lance77035

Alin, thanks for the response.

You are correct. It is "Updating source control status..." that takes so long upon loading the solution. I don't really have knowledge of whether it's verifying or updating something. What exactly needs to be updated when I open a solution

We are using VSS 6.0.

There is antivirus software present, but it's the same one that we've been using all along -- only now sitting at another point in our WAN. (I technically misstated earlier when I said LAN). Again, the WAN is pretty sluggish, but I can't imagine it being so sluggish as to make me wait 30+ minutes for the check-in dialog to appear when invoked from the solution node. There just aren't that many files in this solution!

I'm going to take your advice and get the paperwork started to disable the AV software. My belief is that we'll have to add the sourcesafe folders to an exception list for the AV software. Do you believe that would satisfy the requirements for this test





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

johnj1984

By the way, we are also experiencing this sourcesafe nightmare. vs2005+vss 6.0.

We are experiencing all the symptoms mentioned above. It is really frustrating to be waiting a full 3-4 minutes -- as much as 7-8 minutes for it to be updating source control, when we are not checking in or out anything.

not only that, our source safe directory is on the same machine! no network issues there...





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Ray Dyce

The short answer ( see other threads on this topic) is that vs 2005 has been designed texplictly by Msoft to not work with vss 6.0. They by design block any calls to vss 6.0!

The only solution to get a working system is to upgrade to vsss 2005..





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Ray Dyce

Actually there is a major downside to upgrading to vss 2005.

When VB.NET crashes, it now also causes vss to crash!!





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Alin Constantin - MSFT

Ray, you're wrong. Microsoft has not done anything to block calls to VSS 6.0 or to make VS2005 not work with VSS 6.0. Anyway, you are free to believe what you want.

As for VB .NET, when it crashes, the whole application is closed, and all the dlls loaded by the IDE don't get a chance to shutdown nicely. The access to VSS (both with 2005 and 6.0) is done through MSSCCI dlls that are loaded by the IDE. When the IDE crashes the connections to the VSS databases are still open, and if VSS had data not flushed in the database yet, or if the VB.NET crashed while VSS was still writing files in the VSS database, your database will be corrupted no matter which VSS version you're using (6.0 or 2005).

VSS2005 has a new feature of detecting these abnormal shutdowns - this is why you see the database corruption warnings next time you attempt to connect to the same database only with VSS2005. Be aware though that VSS6 may cause the same corruption so if you experience lots of VB.NET crashes it's advisable to run periodically analyze and check the database for errors.

Alin





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Ray Dyce

Alin Constantin - MSFT wrote:

Ray, you're wrong. Microsoft has not done anything to block calls to VSS 6.0 or to make VS2005 not work with VSS 6.0. Anyway, you are free to believe what you want.

<The facts say otherwise, but hey I am just the one who pays for this rubbish)

As for VB .NET, when it crashes, the whole application is closed, and all the dlls loaded by the IDE don't get a chance to shutdown nicely. The access to VSS (both with 2005 and 6.0) is done through MSSCCI dlls that are loaded by the IDE. When the IDE crashes the connections to the VSS databases are still open, and if VSS had data not flushed in the database yet, or if the VB.NET crashed while VSS was still writing files in the VSS database, your database will be corrupted no matter which VSS version you're using (6.0 or 2005).

< having used vss for many years without problems, I think I understand how it works in my envionment.

All of the above is true, except that VS 2005 throws the error without any basis at all, which is just a waiste of time..
Is this betetr than vs 6.0 which did nothing I thnk not from a users perspective..

Useless messages are just that useless..

VSS2005 has a new feature of detecting these abnormal shutdowns - this is why you see the database corruption warnings next time you attempt to connect to the same database only with VSS2005. Be aware though that VSS6 may cause the same corruption so if you experience lots of VB.NET crashes it's advisable to run periodically analyze and check the database for errors.

> Would prefer it that MSoft fixed the crashs, but at least the stuff should work together and be usable..

Alin





Re: Visual Studio Source Control and SourceSafe VS2005 and Visual SourceSafe Nightmare

Ricomyer

Has anybody found a solution to these huge delays yet It is unbearable to work on VPN anymore with this slowdown. We are using VS 2005 and VSS 6d. Is VSS 2005 any faster Can VSS 2005 connect to VS 2003 (we can't upgrade all our old code yet)