[p4] Perforce integration with VS .NET 2003

[Silgi, Nir]

Thanks everybody for the great answers, I learned some useful stuff.
About my specific problem I had, I think it's a path case inconsistency
problem, I will check tomorrow in the office.

I still have one question. I have a solution with 20 projects,
everything is bound at one developer, I check everything in, except the
mssscc.vss file (I'm offline now, I don't remember the exact name), then
I'm going to another developer, syncing the files are open the solution.
I get many errors but the main issue is that 4 out of the 20 project
seem to be bound (with the first developer's workspace and username),
and the rest of the 16 not. I checked in the exact files for each
project so I really don't know where does the scc plugin store this
info. 
If anyone can tell me where is all this info stored and why I have this
problem, it'll be greatly appreciated.

Thanks a lot,
NirS

-----Original Message-----
From: Matthew Janulewicz [mailto:MJanulewicz at greendotcorp.com] 
Sent: Monday, January 08, 2007 9:41 PM
To: Silgi, Nir; perforce-user at perforce.com
Subject: RE: [p4] Perforce integration with VS .NET 2003

This is a huge pain in the rump because there are so many things that
can go wrong, and VS does not give good feedback.

The first thing I would do is enable logging in the SCC plugin. Become
familiar with the location of this file as you will need to refer to it
often.

Here are some of the common things that can go wrong when binding to
VS2003. Note that often times when I bind a solution on my computer, the
same solution/bindings won't work on a dev's machine. There's usually
some sort of configuration/path issue. These are the 'hit list' things I
check straight away when someone is having trouble with the binding:

- If you're on a case-sensitive filesystem (either locally or on the
server, especially if you have a Linux server in a Windows shop) check
the local path of the folders containing the problem projects. Double
check that the local path, the path in VS, and the path in P4 all match
exactly, including the case of all folders and subfolders.

- Check the workspace definition in use and be sure that the Root
matches the local filesystem, again being sure that the case matches.
While you're at it, check the actual client definition part vs the local
filesystem to be sure all the paths/sub-paths match case.

- (This one can be tedious...) Check all projects for multiple
references to the same file. I come across this one all the time. A user
will need a binary (say a bitmap or icon) in an installer, so they will
add it by dragging it to the installer project. Now you have two binary
files that refer back to the same path. Perforce does not like this. The
proper way to add files to an installer is to mark the files as
'Content' in the project that provides the file, then include 'content
from ...' in the installer. Rule of thumb: only one reference to any
file in an entire solution.

- Look at the paths of any Solution Items. As before, be sure the case
of the paths to these files match exactly between the solution, Perforce
and the local filesystem.

If I don't find something obvious, here's what I do:

1. Delete all solution items, try to re-bind.

2. If one project in particular is a problem, delete it from the
solution and try to rebind. This is usually an installer. (plug: use Wix
instead!)

3. Throughout the whole process, consult the SCC log. One point of
contention that usually indicates a case-sensitivity problem is that the
SCC plugin runs multiple 'p4 where' commands during the binding process.
You will see error results at the bottom of your log file when this
happens. Cut and paste the 'p4 where' command it is trying to execute
into a commandline (set to the proper user and client, of course) and
see what the results are.

*4. If you are not running the latest version of the Perforce server and
client, there is a bug that was fixed regarding the case of the drive
letter in your workspace definition. The case sensitivity issue extended
to the drive letter. This is fixed, but if you're running an older
version of Perforce, be sure any references to any drive letters in your
paths in VS match what's defined in your perforce client root. It's
maddening, but sometimes the only problem is that a 'C:' should be a
'c:'.

In rare cases, there seems to be nothing wrong with any of the things I
mentioned above and I'll get a failure in the SCC log that looks like
this:

P4 where //my_client/localdev/* - files not in client view.

The client will look something like this:

//Source/main/...	//my_client/localdev/Source/...
//Installation/main/...	//my_client/localdev/Installation/...

In this case I think it is trying to resolve an upper, common directory
for these two items, and it can't because there is no explicit, or
implicit, reference to it. I haven't looked too deeply into it, but it
looks like during the binding process the SCC plugin tries to figure out
what the Perforce path is by working *backward* up the path of a project
file, until it finds a common (intersecting) path relative to the
Solution. Our arrangement is such that our solution files are in our
//Source/... depot, and the installers in //Installation/... . In the
case of VS2003, you also have to work with the fact that your web
projects have to be in a specific paths, so there may not be a 'common'
upper-level path that encompasses all your projects within your
workspace definition.

To solve this I'll temporarily change my client to look something like
this:

//Source/main/*	//my_client/localdev/*
+//Source/main/...	//my_client/localdev/Source/...
//Installation/main/...	//my_client/localdev/Installation/...

Re-do the binding, then change the client back. Then it seems to just
'kick in' and work from there on out. My main concern is to take the
failed 'p4 where' command from the SCC log and make it successful.

I hope this helps. If you try all this stuff and it still doesn't seem
to work, feel free to post snippets of your log file to the list. I'll
probably see them. :)

The SCC integration is a must-have for my dev group, so believe me, I've
spent hours and hours troubleshooting this stuff, and for the past month
or two I haven't been beaten. :)


-Matt


-----Original Message-----
From: Silgi, Nir [mailto:nsilgi at shopping.com] 
Sent: Monday, January 08, 2007 7:44 AM
To: perforce-user at perforce.com
Subject: [p4] Perforce integration with VS .NET 2003

Hi,

 

I wanted to ask if it's only me who is eating so much c#$% making
Perforce integrate with .NET 2003 IDE or is it something that is
commonly known.

Adding a solution with 20 projects is half hour work per developer, with
errors, crashes and whatnot. I still have projects which I try to bind
but simply nothing happens!! It really drives me crazy. I don't know if
I should blame Perforce, Visual Studio or the SCC plugin, I lean towards
VS because the integration with Eclipse works like a charm.

 

If anyone has experience with this, I will be more that happy to hear
about it, at least so I won't feel I'm alone in this :-)

 

Thanks,

 

NirS

 

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user