"Connect to server" dialog preventing any automati

alexis_michel · Post by **alexis_michel** » Wed Jul 13, 2005 6:13 am

Hi, I tried to find an answer in the forum but didn't seem to find anythin related, pardon me if it has already been answered somewhere else.

I need to automate nightly builds. The one thing that makes it impossible is the dialog "Connect to server" that pops up as soon as I open the solution (from COM via the Visual Studio automation).
I am getting very frustrated with this, especially when what this dialog asks me, it should already know very well by now, ie the server name (It should now which server the solution is bound to), login (same, it should even remember my password) etc.
Help ! would anybody know how to prevent that dialog to pop up, by any means necessary ?

lbauer · Post by **lbauer** » Wed Jul 13, 2005 9:16 am

See my response to your post in the Vault forum:

http://support.sourcegear.com/viewtopic.php?p=16422

alexis_michel · Post by **alexis_michel** » Wed Jul 13, 2005 10:01 am

To clarify things, I am using SourceOffsite 4.0.2 on visual Studio 2003 and SourceSafe6.0d

I have read your post, and I will try it straight away. I am a bit concerned however that this is just not going to work. I can get the latest from a command line client it is not a problem, but my point is that if I try to then open the solution from within Visual Studio (and Visual Studio COM interface more importantly) It then displays the "Connect to server" dialog asking for a server, databse, user name login etc ... This makes it absolutely impossible to do automated build.
I need to be able to open a solution and see absolutely nothing, not a single dialog.
I tried recreating the bindings myself manually (the file format for this is so simple my 2 years old could understand it) but there is still something important I must be missing.
I can't imagine I am the only one that has ever had this problem am I ?

alexis_michel · Post by **alexis_michel** » Wed Jul 13, 2005 10:19 am

Unfortunately, I was right to believe this woulnd't work.

Using the command line client is just like using the GUI client. It is all fine to ask for Get the Latest Version, it indeed does it, but somewhat something gets lost on the way (bindings ? password ? server name ? some cache gets cleared ?).
So that when I open the solution (or more importantly, when my automation program opens the solution via COM (no windows)) I get that nagging dialog about which server I want to connect to. It will be stuck there forever until I manually answer that question (by the way, the answer to that question is just about the same as it has been for the 250 000 previous times that I answered it).
This kind of defeats any attempt at automating things don't you think ?

Again I have difficulty imagining I am the only one ever experiencing this problem.

What I want to do is that I get the latest version, the bindings (or whatever) *stay* correct, and when Visual studio opens the solution nothing else has to be answered.
I would even settle for some directions as to what exactly I need to recreate (MSSCCPRJ.SCC file ?) so that I don't have to see any dialog in Visual Studio. Or what I would need to do to *emulate* the fact that it has been opened "from source control".

Post by **Tonya** » Wed Jul 13, 2005 11:45 am

Have you attempted to enable the "Connect Automatically" option found in the SOS "Connect to Server" dialog?

If this option is enabled and the "Remember my password" in the SOS login dialog is also enabled, then no SOS dialogs should appear when the solution is being opened.

Tonya Nunn
SourceGear Support

alexis_michel · Post by **alexis_michel** » Wed Jul 13, 2005 1:29 pm

alas I have tried it all, even when you stipulate to "connect automatically", at least one dialog is displayed that needs clicking on.

Exact Steps to reproduce this problem :
- Open Visual Studio
- Open from source control a project (small if possible it is faster).
- Tick everything as you said, Connect automatically and remember password
- Close Visual studio.
- From then on, you will be able to open the solution and never see a dialog again (which is great) (somewhat this seems to be short lived though, but this is not the main problem).
- Go to the directory where that project is and delete all files.
- In the SOS Client do a "Get Latest" on the project (as an automated build software would do to pull a "clean" build during the night)
- Open the solution in visual studio : at least one Dialog is displayed. Your automated nightly build program sits here waiting for you to click on a dialog that just appeared out of nowhere.
- Arrive in the office, get frustrated, click on the dialog and then wait for the build to finish while venting frustration onto the coffee machine

What I would really love, is some kind of indication as to what to do (even black magic goes at this point) to be able to pull an entire project, and open it inside visual studio without having to click on anything.
As I said, I did try to recreate all the MSSCCPRJ.SCC which are fairly easy to do anyway, but this is not enough, something else is missing somewhere.

alexis_michel · Post by **alexis_michel** » Wed Jul 13, 2005 1:44 pm

Just in case it helps :
I have tried the above on Vault, with the addition if recreating the MSSCCPRJ.SCC file before reopening the solution, and it works beautifully.
Unfortunately, at my place we use SOS and we will not commit to anything else until having seen at least SourceSafe2005 and Visual Team System.

I just noticed, in the MSSCCPRJ.SCC file, it is slightly different from the file created with SOS :

[TestApp.csproj]
SCC_Aux_Path = http://bourrin/VaultService|Admin default:1
SCC_Project_Name = $/TestProject/TestApp

The same file in SOS looks more like :
[TestApp.csproj]
SCC_Aux_Path = sos:8086:D:\SourceSafe\Test\srcsafe.ini
SCC_Project_Name = $/TestProject/TestApp

I really don't lie the "sos:8086:D:\" (it doesn't look right !).
And also, since that file seems to contain info about the user in case of Vault, may I ask where that info is stored in the case of SOS ?

Post by **Tonya** » Wed Jul 13, 2005 2:34 pm

How are you recreating the MSSCCPRJ.SCC file before opening the solution?

alexis_michel · Post by **alexis_michel** » Wed Jul 13, 2005 2:43 pm

Programatically in C#.
Both path are pretty well known when using an automated build utility.

Post by **Tonya** » Wed Jul 13, 2005 3:38 pm

I was able to successfully complete the process that you reported by recreating the MSSCCPRJ.SCC file in Notepad. There may be some sort of timing issue involved from when the file is created in C# and when VS.Net actually needs the file.

My suggestion is to either make your automated build not delete the MSSCCPRJ.SCC file or make a backup copy of the file and retrieve it once everything has been deleted. You can also attempt to recreate the file using notepad like I did.

The user information that you previously asked about is kept in the registry information under HKEY_CURRENT_USER, Software, SourceOffSite, SourceOffSite, Settings. The problem that you are experiencing is caused by Visual Studio not know which server and port to connect to, it's not user name or password related.

Tonya Nunn
SourceGear Support

alexis_michel · Post by **alexis_michel** » Wed Jul 13, 2005 4:00 pm

yes but that info (server name and port) is in that MSSCCPRJ.SCC file.
In Vault, only that file counts, so recreating it (regardless of timing) works fine.
Somewhat in SOS as you say there is a problem and even if you recreate it perfectly well it would still not consider it and assume it doesn't know the server name and port.
There is no guarantee that keeping the MSSCCPRJ.SCC file before deletion and restoring it afterwards will work, as you said, if it depends on some timing, then I would rather understand that timing issue.
I will try as you suggest, not deleting (or keeping somehow) the MSSCCPRJ.SCC file and seeing if that makes a difference, but I would bet reasonable amounts that this isn't going to work.

Are there any fundamental differences between the way Vault and SOS handle the MSSCCPRJ.SCC file (I would think there are, seeing the format is a bit different) ?

Post by **Tonya** » Thu Jul 14, 2005 8:04 am

If you are recreating the MSSCCPRJ.SCC file correctly (the exact same way it appeared before it was deleted) then there should be no problems. I followed the exact steps that you are taking but instead of recreating the MSSCCPRJ.SCC file in C#, I created it using Notepad. Before I deleted all of the files, I copied the information from within MSSCCPRJ.SCC, deleted the file and then created a brand new one by pasting the information back in. I was able to open a solution from within VS.Net without any dialogs appearing.

The timing issue that I was referring to may be that the file wasn't quite complete when VS.Net needed it. For example, make sure that the file is finished and saved before the solution is opened in VS.Net. Let me know if any of my suggestions work.

Tonya Nunn
SourceGear Support

alexis_michel · Post by **alexis_michel** » Thu Jul 14, 2005 8:45 am

On a simple project, I was able to do just what you said, Get the Latest version for the project (clean) and then recreate the MSSCCPRJ.SCC file and then it worked beautifully.
I am now looking in my own project (a bit more complex than a simple project) and I am starting to think that it doesn't work just because my project isn't in some standard "shape".
ie : I have a solution directory that lives *alongside* the projects it contains, not with the projects *inside* and somewhat it seems to give me problems.

Post by **Tonya** » Thu Jul 14, 2005 12:04 pm

Could you e-mail me a screen shot of how one of your solutions is set up? I would like to see a solution from Solution Explorer in VS.Net and then from the SOS Client. Once I get an idea of how your solutions and projects are configured, I may be able to give you some more suggestions on how to make this work properly.

Tonya@SourceGear.com and please CC:Support@SourceGear.com

Tonya Nunn
SourceGear Support

TonyKInTexas · Post by **TonyKInTexas** » Thu Jul 21, 2005 7:42 am

alexis,

what about using Nant to do your automated builds? We use that here in the office and have great success.

Nant is freeware and if you can get the latest code using a command line tool from SOS, then I think you can craft a solution that works for you without having to start Visual Studio.

Take care,