VS 2005 local VSS plugin erratic behavior

Hi,

Assuming I'm using the local VSS plugin in order to access a remote VSS database. I have observed this very strange behavior in VS 2005:

1. I right-click an object in the Solution Explorer and chose the History... command.

2. I accept the default options and the History window opens.

3. Now the strange thing: I do nothing and just click on the Close button. This immediately closes the current solution. VS 2005 then automatically tries to re-open the solution but as explained in the thread titled Using VSS local plugin remotely: problem with credentials , it prompts me again for my credentials since my VSS credentials are not identical to my local network (domain) credentials.

Yes, you read well, just viewing at the history without making any change causes the current solution to close and to automatically re-open! Why does it need to do so

Can I assume it's a bug or do I have a wrong understanding of how the VSS plugin works

Thanks.





Answer this question

VS 2005 local VSS plugin erratic behavior

  • KwanzaBot

    Alin,

    OK. I'll do that as soon as I have enough time.

    Thanks.

  • karlytoz

    Hi Patrick,

    VSS usernames/password have nothing to do with domain usernames/passwords.
    VSS doesn't cache anything (for start, it can't even obtain the domain password).
    VisualStudio passes into VSS the user name that is specified in Tools/Options/SourceControl/PluginSettings (by default, this name is the local Windows logon name)
    When the "Use network name..." option is enabled, and the username passed by IDE matches the Windows network name, and in the VSS database there is a VSS user matching this name, VSS simply opens the database using this user name, and doesn't even prompt for password. There is nothing cached here.

    You can always force a login prompt on System1 if you want. Just go to Tools/Options/SourceControl/PluginSettings and change the VSS login name to something else than your domain name (e.g. Admin, Guest, or the username you use on System2, etc), then open the solution. VSS will prompt for password for that user.

    Credentials aside, I doubt this is causing the reload of the solution.
    The IDE/scci reloads the files involved in the operation (in your case the solution file and along with it the projects) when it detects a change in the files before and after the operation. The IDE looks at the file presence on disk, size, checksum, etc. Normally, opening and closing the History dialog shouldn't change any of these. Can you look at the solution file on disk before and after the History operation and confirm that nothing changes
    Also, the IDE may reload solution/projects if it receives file change notifications from the file system. Is there something particular with the location on disk of your solution (e.g. is created on a virtual drive, network drive, etc) Does the reload happen only for that solution (e.g. if you create a new solution in a different location, would it reproduce the behavior)
    If you login from System1 with the VSS username used on system2, or with Admin/Guest accounts, does the reload happen

    Thanks,
    Alin

  • pallavi_020

    Alin,

    In the VSS Administrator, the following options are enabled

    "Always check out the working folder version of files" (also enabled in VSS Explorer for this database).
    "Allow multiple checkouts"

    In the VS IDE plugin, all options in the Environment page are unchecked. Checkout local version is allowed.

    All files are identical on the server and on the local systems.

    Anyway, the problem is obviously related to what credentials are used. The behavior I observed is diffferent on two systems having exactly the same settings but using different credentials.

    System #1

    It seems that somehow, my credentials are now being cached by the VSS plugin on this system. I can launch the VS 2005 IDE and open the solution (which is bound to the remote VSS database) without being prompted for a userid/password ( ).

    Previously, I changed my local credentials so that they exactly matched the credentials for the remote VSS database. The "Use network name for automatic user log in" option is enabled.  Then I changed my local (domain) password again so that it is different from the VSS password (userids are identical). I guess that somehow, the previous local password (now invalid for the domain but still valid for VSS) was cached by the plugin and that the plugin is still using this password instead of the new local one as it normally should since the "User network name..." option is enabled (but hey, I like this behavior Smile ). Otherwise, I cannot explain why I can launch VS 2005 and open the solution without being prompted by VSS since my local userid/password don't match the VSS credentials .

    On this system, I confirm that right-clicking the Solution item, opening the History window and just clicking Close without doing anything else, closes and reloads the solution. I see explicit messages in the VS IDE status bar saying "Unloading solution file..." and then "Loading project file...", etc. So this is obviously a part of the process. This no longer happens when viewing the history for projects or files. Also, since the credentials now appear to be cached, I'm no longer prompted for them.

    System #2

    Very same VSS settings but the local (domain) userid and password are both different from the VSS credentials. On this system, I must enter the VSS credentials each time I open the solution. The default username presented in the prompt window is the VSS username as expected, not the local username. But the password is not cached in that case. However, right-clicking the Solution, viewing the History and clicking on Close does not trigger an unload/reload of the solution or any other action. The dialog box just closes as expected.

    Cheers.


  • Inga Verbitskaya - MSFT

    Hi Patrick,

    I cannot reproduce the behavior you're talking about.
    Can you give detailed information about your database/users configuration, the project and file type and actions you're taking Does the file have a newer version in the database; is checkout local version allowed, etc. Does this reproduce with only one database/project/file or with any project/file

    Just viewing the history of a file in a project should not cause a reload of the whole project as you say it does. At most it could cause a reload of that file, if you click the Get or Checkout buttons in the history dialog (that would change the file content on disk, so a reload would be necessary when closing the dialog).

    Thanks,
    Alin

  • Thunder0ne

    Hi Patrick,

    I suspect all this weird behavior is caused by the project location in Briefacase, although when I tried it I could not repro it.

    Here is what I'd try:
    - In VisualStudio1 open the solution with the problem
    - create a backup copy of the solution (sln) and the vssscc file.
    - set Tools/Options/SourceControl/Environment/"Get Everything when opening a solution or project" and "Checkin everything when closing a solution or project"
    - checkout a file in the project
    - open the History dialog and Close it
    - this will reload the solution for some reason, and the above settings will cause a dialog to come up (expected either checkin or get dialog, but an error message might come up as well - looks like we have a bug here). Leave the dialog open for now.
    - create a second backup copy of the solution (sln) and the vssscc file.
    - start another VisualStudio2 (this will be the debugger)
    - Tools/AttachToProcess
    - select the first devenv.exe that had the solution open, attach to it
    - Debug/BreakAll
    - Debug/SaveDumpAs... and pick a filename
    (After this you can stop debugging. If you got an error message instead of Get/Checkin dialogs, you may need to restart the first VisualStudio.)

    This should create a minidump that will contain the callstack at the reload time.
    Hopefully this will help us to identify what's triggering the reload.

    Then, open a bug with as much information as possible about how and where the solution was created, about the database configuration, which version of the solution you have locally and what is the latest in database, etc. Attach the minidump and the 2 backups of the solution and vssscc files.
    You can also email vssdev@... alias pointing to this thread and sending the minidump. I'll be in vacation for the next weeks, but someone else will respond and hopefully we'll figure out what's causing this reload.

    Thanks,
    Alin 

  • awsexton

    Thanks for your patience, Alin.

     Alin Constantin - MSFT wrote:
    When the "Use network name..." option is enabled, and the username passed by IDE matches the Windows network name, and in the VSS database there is a VSS user matching this name, VSS simply opens the database using this user name, and doesn't even prompt for password. There is nothing cached here.
    Correct. So I have created a new VSS user having the same name as the system #2 user and indeed, I'm no longer prompted. Also, this doesn't make the unload/reload problem appear on this system.

     Alin Constantin - MSFT wrote:
    Can you look at the solution file on disk before and after the History operation and confirm that nothing changes
    Confirmed.
     Alin Constantin - MSFT wrote:
    Also, the IDE may reload solution/projects if it receives file change notifications from the file system. Is there something particular with the location on disk of your solution (e.g. is created on a virtual drive, network drive, etc)
    I should have mentioned that the project is located in the Briefcase. Sorry (I forgot this because I'm loading from the Start page). System #1 is a portable PC.

     Alin Constantin - MSFT wrote:
    if you create a new solution in a different location, would it reproduce the behavior
    No.

     Alin Constantin - MSFT wrote:
    If you login from System1 with the VSS username used on system2, or with Admin/Guest accounts, does the reload happen
    Yes (solution still loaded from the Briefcase folder although this folder is not the Briefcase folder for the logged on user).

    Hope this helps.

    Cheers.

  • yishyuan

    The problem disappears if I change my local credentials to match the remote VSS credentials.

  • VS 2005 local VSS plugin erratic behavior