Vault performance with VS2005

[axyonych]

Our company uses Vault version 3.1.6. We have the following problem with Vault IDE plugin and Visual Studio 2005.

Our solution consists of a Class Library project, a File System Web Site project and a Database project. The problem always reproduces with the following steps:

1. Get latest version from repository using Vault Client.
2. Start Visual Studio 2005 and try to open the solution file.

Visual Studio freezes and Vault IDE plugin downloads about 8Mb of data from Vault server. If you close the solution without closing Visual Studio and reopen it, then the download does not occur. If you close Visual Studio, start it and try to open the solution again, Vault plugin downloads significant amount of data again. This issue makes discomfort for us because we use Vault over internet through VPN connection and download takes significant time amount.

With Visual Studio 2003 this issue does not occur.

I have enabled the logging and save the logs from Vault IDE plugin and Vault GUI client to compare:

VaultGUIClient.txt:
01.02.2006 0:00:56 <refresh>: [GUIClientWorkerThread:2544] Refresh started
01.02.2006 0:00:56 <refresh>: [GUIClientWorkerThread:2544] delta passed in was null, retrieving one
01.02.2006 0:00:56 <refresh>: [GUIClientWorkerThread:2544] calling GetRepositoryStructure(2, 42213, -1, ref, 01.07.2005 2:41:10)
01.02.2006 0:00:56 <connection>: [GUIClientWorkerThread:2544] GetRepositoryStructure started.
01.02.2006 0:00:56 <refresh>: [GUIClientWorkerThread:2544] GetRepositoryStructure started
01.02.2006 0:00:56 <refresh>: [GUIClientWorkerThread:2544] Calling client service GetRepositoryStructure(2, 42213, -1, 01.07.2005 2:41:10, ref, ref, ref)
01.02.2006 0:00:56 <refresh>: [GUIClientWorkerThread:2544] Client service GetRepositoryStructure returned: dtLatestCheck 01.07.2005 2:41:10, nReturnDestRevision 42213, rd not null True
01.02.2006 0:00:56 <refresh>: [GUIClientWorkerThread:2544] GetRepositoryStructure finished
01.02.2006 0:00:56 <connection>: [GUIClientWorkerThread:2544] GetRepositoryStructure finished.

VaultIDEClient.txt
01.02.2006 0:03:32 <refresh>: [<No Name>:3472] Refresh started
01.02.2006 0:03:32 <refresh>: [<No Name>:3472] delta passed in was null, retrieving one
01.02.2006 0:03:32 <refresh>: [<No Name>:3472] calling GetRepositoryStructure(2, 42213, -1, ref, 01.07.2005 2:41:10)
01.02.2006 0:03:32 <connection>: [<No Name>:3472] GetRepositoryStructure started.
01.02.2006 0:03:32 <refresh>: [<No Name>:3472] GetRepositoryStructure started
01.02.2006 0:03:32 <refresh>: [<No Name>:3472] Calling client service GetRepositoryStructure(2, 42213, -1, 01.07.2005 2:41:10, ref, ref, ref)
01.02.2006 0:03:41 <refresh>: [<No Name>:3472] Client service GetRepositoryStructure returned: dtLatestCheck 01.07.2005 2:41:10, nReturnDestRevision 42213, rd not null True
01.02.2006 0:03:41 <refresh>: [<No Name>:3472] We got a compressed delta we have to download, getting download file stream
01.02.2006 0:03:41 <connection>: [<No Name>:3472] GetDownloadFileStream started.
01.02.2006 0:03:41 <connection>: [<No Name>:3472] GetDownloadFileStream finished.
01.02.2006 0:03:41 <refresh>: [<No Name>:3472] Get download file stream and response stream
01.02.2006 0:03:41 <refresh>: [<No Name>:3472] Reading delta from stream
01.02.2006 0:03:41 <connection>: [<No Name>:3472] ReadDownloadFileFromStream started.
01.02.2006 0:06:15 <connection>: [<No Name>:3472] ReadDownloadFileFromStream finished.
01.02.2006 0:06:15 <refresh>: [<No Name>:3472] Completed reading delta from stream, calling EndDownloadFiles
01.02.2006 0:06:15 <connection>: [<No Name>:3472] EndDownloadFiles started.
01.02.2006 0:06:16 <connection>: [<No Name>:3472] EndDownloadFiles finished.
01.02.2006 0:06:16 <refresh>: [<No Name>:3472] EndDownloadFiles completed
01.02.2006 0:06:16 <refresh>: [<No Name>:3472] Uncompressing delta on disk
01.02.2006 0:06:17 <refresh>: [<No Name>:3472] Uncompress finished, reading into memory from disk
01.02.2006 0:06:18 <refresh>: [<No Name>:3472] Successfully read from disk into memory, delta loaded
01.02.2006 0:06:18 <refresh>: [<No Name>:3472] GetRepositoryStructure finished
01.02.2006 0:06:18 <connection>: [<No Name>:3472] GetRepositoryStructure finished.

I have marked out with bold the differences in log files.
As you can see the call of the GetReporistoryStructure with same parameters occurs in both cases, but in the Vault IDE plugin this call results in a call of ReadDownloadFileFromStream that takes significant amount of time (3 minutes in my environment).

[dan]

If Vault always starts downloading files when the project is opened in VS 2005, then there might be a problem with the state of the files that it is trying to correct.

Some questions:

1. Was the project initially created using Open From Source Control from within Visual Studio? If you do a Get from the GUI client and then try to use it from VS, the bindings are not really set up correctly - you have to do the Open once, and then after that doing a Get from either client should only Get the files that are out of date.

2. Is the whole project about 8MB worth of data? Or, do you have 8MB worth of files that are out of date that VS is trying to sync up?

3. Check the status of the files in the GUI client and verify they are not Unknown or Missing.

4 Check the working folder set in the GUI client, and verify it is the same working folder as specified in Visual Studio.

[axyonych]

There is another way to reproduce the problem of Vault plug-in with VS2005.

1. Start Vault GUI Client, login and wait for repository tree showed up. This step guarantees that you got the latest version of catalog to Vault’s local cache.
2. Start VS2005.
3. Choose “Open From Source Control”.
4. Enter Login information (if asked).
5. Choose repository (if asked).

After these steps, Vault IDE Client starts downloading about 7Mb and the log file contains the same lines which I posted early. Only after this download completes IDE shows the dialog with the repository structure.
This issue appears after each restart of the Visual Studio 2005.

There are no files to update now, because the project wasn’t selected and Vault’s local cache contains latest catalog version (step 1).

[dan]

This is actually the way VS designed the Open From Source Control command to work. It sets up the project initially to be used from within Visual Studio by setting the working folder and getting all the files. It is only supposed to be invoked the first time you use a project, since it always downloads the files and sets the working folder.

If you already have the files on your local system, you could try the Change Source Control to bind them (which sets the working folder) to the repository version (VS doesn't actually read Vault's working folder info, but keeps its own).

You might want to read Microsoft's primer on Source Control in Visual Studio - it does a much better and more complete job of explaining it that I can

It is at http://msdn2.microsoft.com/en-us/library/zxd4dfad.aspx

[Vlad]

We upgraded our projects from VS2003 to VS2005 and got the same problems that described in the topic.

I repeat the issue which "axyonych" described in our environment. Sorry Dan, but your answers are not appropriate with the heart of the problem.

I actually don't understand why Vault downloads the whole repository structure if you try to open a project from source control (File/Open From Source Control) or start VS2005 and open a project. And it happens every time you open any project in VS2005.

We spent lots of time waiting for downloads over VPN.

I wrote about the problem in another topic but the problem still exists.
Dan, would you please be able to increase the priority of the problem?

[dan]

Maybe I'm not understanding the issue. As I understand it, an Open From Source Control is done everytime VS is launched. Open From Source Control is designed to download all files from the source control tool (this is Visual Studio asking that all the files be downloaded, and not Vault doing it on its own).

If files are downloaded when you merely open a project that is under source control (e.g., File->Open->Project), then that indeed is a problem. Opening a project is supposed to just connect to Vault and get the latest version information from Vault, so VS knows which files are out of date, checked out, etc. It is not supposed to download files, nor have we seen this behavior here.

One possibility is that the Visual Studio option to automatically download files from source control when opening a project is turned on. This wouldn't explain why it downloads *all* the files, unless all the files are out of date. Checking the GUI client (and the search pane for old, missing, etc files) would verify which files would be downloaded in that case.

It sounds like there still may be a basic misunderstanding here, so if that is the case, perhaps listing the exact steps you take and the results of each step would be helpful.

[axyonych]

Maybe I'm not understanding the issue. As I understand it, an Open From Source Control is done everytime VS is launched. Open From Source Control is designed to download all files from the source control tool (this is Visual Studio asking that all the files be downloaded, and not Vault doing it on its own).

Dan, Vault IDE client starts downloading of data before VS2005 shows me the dialog "Create local project from Vault". By some experiments I discovered that Vault downloads full repository structure (instead of using the local cache content) at this time. Log that i posted in my first message confirms this results. All downdload appears in function VaultConnection.GetRepositoryStructure. This function doesn't download any files except repository structure.

[dan]

OK, yes, I see in the log that the repository structure is being downloaded. Do you have a very large repository structure that would account for 8MB of data being sent?

Also, please verify: Does this only happen when you invoke File->Source Control->Open From Source Control, or does it happen also when you use File->Open->Project?

The log file is not providing all the information we need to determine why the repository structure is being downloaded in full, so we may have to get a special debug build out to you. A full repository structure is returned in some cases (like when a user's security settings have changed), but mostly it is supposed to just send the delta. If the dates being sent are invalid, then a full structure will be returned.

A special debug build with extra logging may have to wait until Monday. Would that work for you?

[axyonych]

OK, yes, I see in the log that the repository structure is being downloaded. Do you have a very large repository structure that would account for 8MB of data being sent?

The size of the CacheMember_Repository in Vault cache is 17Mb.

Also, please verify: Does this only happen when you invoke File->Source Control->Open From Source Control, or does it happen also when you use File->Open->Project?

This happens in both cases.

The log file is not providing all the information we need to determine why the repository structure is being downloaded in full, so we may have to get a special debug build out to you. A full repository structure is returned in some cases (like when a user's security settings have changed), but mostly it is supposed to just send the delta. If the dates being sent are invalid, then a full structure will be returned.

As you may see in the log fragment the both calls of GetRepositoryStructure (from the GUIClient and IDEClient) are made with the same parameters, but result is different.

A special debug build with extra logging may have to wait until Monday. Would that work for you?

OK.

[dan]

Send me email via the button below, and I'll get a debug build out to you today.

[axyonych]

Dan, I think that I have found why the Vault server returns the whole repository structure. I has captured the queries for the server from GUI client and IDE client using Microsoft Network Monitor and discovered the following:

VaultGUIClient.xml:

<GetRepositoryStructure xmlns="http://www.sourcegear.com/schemas/vault">
<nRepID>2</nRepID>
<nBaseRevision>42359</nBaseRevision>
<nTargetRevision>-1</nTargetRevision>
<dtLastClientSecurityCheck>2005-07-01T02:41:10.5930000+03:00</dtLastClientSecurityCheck>
<dtLatestServerSecurityCheck>1850-07-01T00:00:00.0000000+03:00</dtLatestServerSecurityCheck>
<nReturnTargetRevision>-1</nReturnTargetRevision>
</GetRepositoryStructure>

VaultIDEClient.xml:
<GetRepositoryStructure xmlns="http://www.sourcegear.com/schemas/vault">
<nRepID>2</nRepID>
<nBaseRevision>42359</nBaseRevision>
<nTargetRevision>-1</nTargetRevision>
<dtLastClientSecurityCheck>2005-07-01T02:41:10.593</dtLastClientSecurityCheck>
<dtLatestServerSecurityCheck>1850-07-01T00:00:00</dtLatestServerSecurityCheck>
<nReturnTargetRevision>-1</nReturnTargetRevision>
</GetRepositoryStructure>

As you can see in request from IDE client there is no Time Zone part of the dates.

[dan]

OK, this will help in trying to reproduce it here, which I'll try to do and get back to you.

Just to be clear: Your client and server are 3 hours apart by timezone? Actually, can you give the exact timezones your client and server are running under, and also what regional settings you are using (via Control Panel -> Regional Settings)

And one other thing: Does the repository you are using have security turned on? If you make a security setting change (on any user, even a temporary change), does that affect anything?

[axyonych]

dan, there is a breaking change in the .net framework 2.0 that affects your IDE client:

http://msdn.microsoft.com/netframework/ ... erial.aspx

Short Description The default for serializing DateTimes is RoundTrip which is breaking
Affected APIs All serialize/deserialize APIs on the XmlSerializer Severity Low Compat Switch Available No

--------------------------------------------------------------------------------

Description We now roundtrip DateTime Kind info. That is, when we write, we write using the Z (UTC) format for the "UTC" kind and without a timezone for "Unspecified" kind. When we read, we create a DateTime of the appropriate kind depending on the format in XML. This is different from version 1.1 behavior. The version 2.0 behavior is correct, but there could have been customers who (a) worked around the incorrect version 1.1 behavior in a way that was contrary to our guidance, which was to always use local times or to convert times to strings before serialization, or (b) interoperated with 3rd-party clients/services that serialized time in the UTC format or in a timezone-less format. These consumers will be broken (they will see some incorrect time calculations). A version 2.0 known issue has been submtited for this. TEXT: Date and Time calculations in Web Services or XML Serialization scenarios may be incorrect after migrating to .NET Framework 2.0 .NET Framework 2.0 changes the way dates and times are written to and read from XML. This change mostly affects the following scenarios: - Using times with an unspecified time zone or times in the UTC time zone - Interoperability scenarios with 3rd-party software which writes out time values to XML without specifying a time zone or specifying the UTC time zone The changes may cause certain date and time calculations and comparisons to become incorrect. In these cases, it may be necessary to revert to the earlier date/time behavior. This can be accomplished by applying the following configuration change:

--------------------------------------------------------------------------------

User Scenario Upgrading from V1.1 to V2.0, using ASMX web services, and one of the following: - Using times with an unspecified time zone or times in the UTC time zone - Interoperability scenarios with 3rd-party software which writes out time values to XML without specifying a time zone or specifying the UTC time zone

--------------------------------------------------------------------------------

Work Around: Compat switch

It seems that this issue takes effect only if the TimeZone of the server and client are different.

I has created the simple example that reproduces this behavior.

Web service code:

Code: Select all

namespace TimeService
{
    /// <summary>
    /// Summary description for Service1.
    /// </summary>
    public class Service1 : System.Web.Services.WebService
    {
        public Service1()
        {
            //CODEGEN: This call is required by the ASP.NET Web Services Designer
            InitializeComponent();
        }

        #region Component Designer generated code
        
        //Required by the Web Services Designer 
        private IContainer components = null;
                
        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        private void InitializeComponent()
        {
        }

        /// <summary>
        /// Clean up any resources being used.
        /// </summary>
        protected override void Dispose( bool disposing )
        {
            if(disposing && components != null)
            {
                components.Dispose();
            }
            base.Dispose(disposing);        
        }
        
        #endregion

        // WEB SERVICE EXAMPLE
        // The HelloWorld() example service returns the string Hello World
        // To build, uncomment the following lines then save and build the project
        // To test this web service, press F5

        [WebMethod]
        public DateTime HelloWorld(DateTime date)
        {
            return date;
        }
    }
}

Compile this web-service with VS2003 and place it on the server with asp.net 1.1 (our Vault server runs under ASP.NET 1.1)

Client code:

Code: Select all

using System;
using ConsoleApplication4.TimeService;

namespace ConsoleApplication4
{
    /// <summary>
    /// Summary description for Class1.
    /// </summary>
    class Class1
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main(string[] args)
        {
            Service1 service = new Service1();
            DateTime value = service.HelloWorld(new DateTime(1850, 7, 1));
        }
    }
}

Compile client code with VS2005 and place it on another machine with time zone that differ from timezone server and run. You will receive from the server date that differs from date that you has sent .

P.S. I has found a workround for this issue:
http://msdn2.microsoft.com/en-us/library/ms229751.aspx
Add to devenv.exe.config for VS2005 the next configuration strings

Code: Select all

<configuration>
             <system.xml.serialization>
             <dateTimeSerialization mode="Local"/>
             </system.xml.serialization>
</configuration>

[dan]

Thanks so much for tracking this down Alex. I suppose this will happen if one is running the 2.0 framework on the GUI client as well.

Is there anything else you need from us on this?