Problems with clients behind NAT

alexey · Post by **alexey** » Mon Aug 30, 2004 5:52 am

I have:
- two PCs with SOS 4.0.2 clients installed and integrated with VS.NET 2003 (1.1)
- both PCs are behind NAT firewall, so SOS server sees single IP but different ports for both PCs
- a single SOS account/login/key for both SOS installations

What I do is:

Test 1:
- PC#1: launch SOS client and VS.NET
- PC#1: checkout some files in SOS client
- PC#1: press 'Refresh Status' in VS.NET (Source Control bar)
- PC#1: statuses are correctly updated in VS.NET (Solution Explorer tree)
Works as expected.

Test 2:
- PC#1: launch SOS client and VS.NET
- PC#2: launch SOS client and VS.NET
- PC#2: checkout some files in SOS client
- PC#1: press 'Refresh Status' in VS.NET
- PC#1: statuses have not been updated at all (in VS.NET)!
That does not work as expected.

Test 2a:
- PC#1: launch SOS client and VS.NET
- PC#2: launch SOS client and VS.NET
- PC#2: checkout some files in SOS client
- PC#1: press 'Refresh File List' in SOS client
- PC#1: statuses are correctly updated in SOS client
- PC#1: press 'Refresh Status' in VS.NET
- PC#1: statuses have not been updated at all (in VS.NET)!
Even that does not work as expected.

Can you help me please? TIA

corey · Post by **corey** » Mon Aug 30, 2004 2:18 pm

Unfortunately, the "Refresh Status" menu item in the VS.NET menu does NOT tell the client to refresh against the server. Here's why:

In the Microsoft source code control API, there is only one method for refreshing file status. This method is called when:

(a) A user selects the "Refresh Status" menu in VS.NET, as you are doing

(b) Within the context of several other API calls, such as Check In, Check Out, etc. And often its called numerous times within the context of one of those operations

To make matters worse, there is no distinction between (a) and (b). So if SOS performed a server refresh each time the refresh status method was called, because of (b), the performance would be so bad that the SOS integration component would be unusable.

The best workaround is to go to SOS options within VS.NET and turn on the "automatic file refresh" option and specify a value such as 1 minute.

alexey · Post by **alexey** » Tue Aug 31, 2004 4:51 am

Thank you, Corey, for your prompt answer!

Well, I was honestly surprised that "Refresh Status" worked in some cases and didn't in others. That was my only concern. I really thought that there were some problems with my configuration. After all, so many developers use SOS already and have not seen such problems so far.

Now, when you say that you don't really invoke Refresh when I press "Refresh Status" (because it is used in so many places across all the functions of VSS API, so it would slow down SOS performance), well, that's even double strange to me as that means that "Refresh Status" must not work at all. But why it worked in some cases? Or I got it all wrong?

When does SOS really perform honest refresh of file statuses? I need a reliable and, hopefully, handy way to update file statuses within VS.NET. That's all.

About the workaround you suggested, yes, I tried it, so I am getting every minute the following message in the Output window of VS.NET:

"Retrieving File List: $/..."

But, still, the statuses are not updated correctly. I really don't know what I shall do to overcome this problem.

TIA

corey · Post by **corey** » Tue Aug 31, 2004 10:28 am

Well, if its the "checked out by another user" status that you want to see reflected in the file icon in the project view, then what you have is a combination of two problems, the refresh problem, and the fact that VS.NET does not seem to paint its icons correctly. SOS appears to be sending the correct status flag to VS.NET, but the correct icon does not appear.

Once you see the "Retrieving File List: $/..." message, if you view the source control properties of a checked out file within VS.NET, you'll notice that SOS correctly reports the status as checked out, but the icon is not getting updated by VS.NET.

alexey · Post by **alexey** » Tue Aug 31, 2004 10:50 am

I am very sorry if I start sounding irritating, but I am sure this is not about painting the icons in VS.NET.

In fact, that's how I found that problem - some guys from other PCs checkouted files while I was working in VS.NET, then I pressed Refresh button and tried to check out same files I got an error saying about unability to lock the file, so I only could see that those files had been already checkouted when I restarted the whole VS.NET.

Same problem if I force SOS to refresh file list every minute as you suggested: checkout option keeps enabled, and when I press it, I get an error about "Unable to lock file: ..." from SOS and "Checkout error or user cancelation" from VS.NET itself.

Please just tell me if you need to know anything more about my configuration or steps I do?

alexey · Post by **alexey** » Tue Aug 31, 2004 11:26 am

Well, yes, if I press "SourceOffSite Properties" button, I see right Check Out Status.

But I think that this "SourceOffSite Properties" action directly requests SOS server for statuses as I can see "Operation started at time ..." and "Operation completed successfully at time ..." messages in the Output window.

Still I get errors when trying to checkout the files.

corey · Post by **corey** » Tue Aug 31, 2004 12:26 pm

If you are seeing the "Retrieving File List: $/..." message in the VS.NET output pane, then SOS is refreshing its file list and knows at that point what files are checked out by other users. However, the only way that VS.NET displays that information to the user is via the file icon in its project view, and that icon is not being set correctly even though SOS is telling VS.NET the correct info once the refresh occurs.