To be clear, The same dsw file would then contain at least two other projects named "Win32Wrapper" and "PersistantData", but in no particular order.
The regexs I used were:
    /^Project "(.+)=(.+) - Package/
    /Project_Dep_Name (.+)$/
Where the first one yeilds $1 as the project name and $2 as the relative path from the dsw file to the dsp file. The second yeilds $1 as the name of the project on which this project depends.

Some words of caution. My script ran across several dsw files (that was the point) and some dsw files share projects. Meaning that a project can be in multiple dsw files. But for some reason I have yet to figure out, different dependancies (if any at all) are listed for the same project in different workspace files. Weird. So one .dsw will claim a project to have a set of dependancies, while another won't know about any dependancies. I think this has to do with some workspaces being out of date (no one edited the workspace recently) but the code in it is still relevant.

This runs on a win32 system (DevStudio) so I use a shell dir command to do the work of finding my .dsw files like this:

$root = 'D:\projects\\';
@workspacefiles = split/\n/, `dir *.dsw /s /B`;
s/\Q$root\E(.+)/$1/ for (@workspacefiles);
[download]

The root is separated like that because I don't want it in the output that I generate. I figured it would be faster to remove it first, but it could just as easily be removed at the end. Taking it out early meant that I had to keep putting it back later. Oh well. And the path to the dsw file is easily gotten thusly:

foreach $dswfile ( @workspacefiles )
{
    $pathtodsw = "$root$dswfile";
    $pathtodsw =~ s/(.*)\\.+?\.dsw/$1/;

    # Then I open the file and read the relevant data.
}
[download]

Thanks.