Setting source code location in pdb files

MathiasR

Hi,

Is it possible to add a source code location to a pdb-file

Now when our development platform is being built on a separate build machine Visual Studio 2005 always looks for the source code in a local path on the build machine.

What I would like to do is have the build script set the pdb-files' source code location point to \\server\sourcecode\buildnumber\ and then the build script would copy all source code files to this directory (all files would be in the same directory without folder hierarchy).

Then the developers that use the development platform could copy the dlls and pdb files locally and then when stepping into platform code visual studio would look in this directory.

Is this possible or does anyone have any other idea I've read some about symbol servers but we don't have autoincremented version numbers on the binaries but change the version only when there is a larger change. Therefore I assume that the symbols (is source code accessible through a symbol server ) produced on night 2 would overwrite the ones from night 1 since the version number hasn't changed event though source code might have.

TaylorMichaelL

No it is not possible but it shouldn't cause you a problem any way. When a source file is needed VS will attempt to load it from the PDB-provided path. If it doesn't find it then it'll starting looking locally in your source file directories. If it doesn't find it then it'll prompt the user for a copy.

A symbol server won't really help here. Symbol servers serve up PDB files, not source files. They are used to distribute PDB files. BTW your nightly builds should always generate new build #s otherwise you don't know what day's build you're running. Personally the automated builds we run increment the build # (the last number) every night before compilation. We also drop a label into CM so we can track the build back to the source that produced it without having to do messy date/time comparisons.

Michael Taylor - 3/8/07
http://p3net.mvps.org

MathiasR

Thanks for the reply.

The problem is that I don't want the developers to have to choose the source code location. The way I figured it was for the build and usage to go like this.

Every night we build out platform and the Team build DropLocation is \\server\Builds\OurPlatform which makes the actual drop directory \\server\Builds\OurPlatform\BuildNumber. If the unit tests succeed the binaries are copied to the directory \\server\Builds\OurPlatform\LatestSuccessful.

When developing a project on the platform the platform binaries are stored per project, e.g. the projects use the following directories: $/Customer Projects/Project1/PlatformAssemblies and $/Customer Projects/Project1/TheProject. The "TheProject"-project then uses the platform assemblies are file references. We also store the PlatformAssemblies in version control so all developers on a project use the same platform version. When appropriate a developer gets the newest release from the LatestSuccessful-directory and copies the files to the PlatformAssemblies-directory. This means that different projects can use different versions of the platform.

I could tell all developers to put e.g. \\server\Builds\OurPlatform\SourceCode in the Solution's Debug Source Files -location but that would always then contain the newest source files and the developer doesn't necessarily have the newest binaries. I was planning on putting the source code used to make the build in a directory beneath the drop location, e.g. \\server\Builds\OurPlatform\BuildNumber\SourceCode. Then the pdb-files could point to their own source code location so that the binaries would always point to the correct source code. Now if a developer hasn't updated the platform build in a while and the source code changes he would get weird results then stepping through the platform code.

Any suggestions on how to do this

TaylorMichaelL

The paths you gave are CM paths (unless you were just using symbolic names) so they are irrelevant. The file paths are used in the PDB. So if you were to (on your build server) have the following directory layout:

c:\projects\customer projects\project1\platformassemblies
c:\projects\customer projects\project1\TheProject

Then the PDBs would refer to this path. Now, if a developer happens to have this same directory layout then the source files would be picked up automatically. If not then they will have to go point to the correct source. I believe this is a necessary evil in your case because how does a developer know what source goes with what assembly

I, in general, do not believe in putting built binaries into CM as I believe it complicates things. The only exception is third-party components which I don't build. In that case the source code is irrelevant. When I do use third-party components I tend to isolate them outside the scope of any project to: a) make it easier to update, and b) keep the size of the repository down. Here is how I'd lay out the CM system:

$/projects/Assemblies/PlatformAssemblies/v1.0.0.0/Bin
$/projects/Assemblies/PlatformAssemblies/v1.0.0.0/Source
$/projects/Assemblies/PlatformAssemblies/v1.1.0.0/Bin
$/projects/Assemblies/PlatformAssemblies/v1.1.0.0/Source
...
$/projects/Customer projects/project1/TheProject

Now the platform assemblies are isolated and a project can use the appropriate version. To ensure that all developers use the correct version, assuming you are using SourceSafe or SourceVault, then you can share the appropriate version directory with the project like so:

$/projects/Customer projects/project1/PlatformAssemblies -> Shared to $/projects/Assemblies/PlatformAssemblies/vw.x.y.z/Bin

The advantage is that if you update the version binaries the project will automatically get the update. Furthermore if you build the binaries then the path on the build server would be: c:/projects/assemblies/platformassemblies/v1.0.0.0/source so your devs just need to mimic this layout in order to get the PDBs to line up without a dialog. Finally a developer could be working on multiple projects (and versions) simultaneously without conflict.

Just my opinion. Maybe somebody else can provide a better solution.

Michael Taylor - 3/15/07
http://p3net.mvps.org

Mike Stall - MSFT

It sounds like you want a Source Server in addition to the Symbol Server. Check out http://msdn2.microsoft.com/en-us/library/ms680641.aspx, our search for "Source Server" for more details. Both Windbg and VS2005 support both Source + Symbol servers.

MathiasR

Thanks Mike for the info. This is just what I need.

Regards,

Mathias

Setting source code location in pdb files

Re: Common Language Runtime Setting source code location in pdb files

Re: Common Language Runtime Setting source code location in pdb files

Re: Common Language Runtime Setting source code location in pdb files

Re: Common Language Runtime Setting source code location in pdb files

Re: Common Language Runtime Setting source code location in pdb files