jwcolby
jwcolby at colbyconsulting.com
Sat Jun 12 08:14:23 CDT 2010
Shamil, > So you keep all your source code on server side and that makes your debugging sessions on workstations very slow? I must say I have never tried to do that - I'm keeping all my code locally, and if worked in a team I'd have kept code repository on the server under SCC (Mercurial or others), and I'd have had debugging sessions running using current local copy of sources... I did not (intend to) say that the location of the source code had anything to do with the debug stepping slowness (or the compile slowness for that matter). I have not determined what causes the slowness so I am not assigning responsibility. I merely said that the problem never occurred when I ran everything through a remote desktop directly on the server, and started to occur when I started actually trying to develop on the workstation. I am using source control - VisualSVN over Tortoise. The source repository is on the server but the workstations check out to a local directory in the normal Visual Studio Project path under each user on the workstation. So the actual code being compiled is on the local workstation. None the less the compile time is probably 10 times as long. What causes that? Who knows. The server is the last gen AMD quad core, running windows 2003 X64, 16Gigs ram and raid6 array disks. The workstations are 2 generation old AMD quad core running Windows XP X32 or Vista X32, with 4 gigs of ram and a normal hard drive. Something in there could explain it. I imagine that compile time and debug step time are pretty much separate issues however. And I haven't found a fix for the debug step time so I do not have the answer as to why it occurs. John W. Colby www.ColbyConsulting.com Shamil Salakhetdinov wrote: > Hi John - > > So you keep all your source code on server side and that makes your > debugging sessions on workstations very slow? > > I must say I have never tried to do that - I'm keeping all my code locally, > and if worked in a team I'd have kept code repository on the server under > SCC (Mercurial or others), and I'd have had debugging sessions running using > current local copy of sources... > > When debugging multi-projects solutions locally I have not seen any > significant slow downs - and compiling multi-project solutions takes a bit > more time when code edits are done on the common level classlib projects... > > As I have heard VS2010 should provide a more powerful edit & continue > debugging mode than VS2008 do, and then even if code changes will be done > while debugging on low level classlibs you should be able to continue > debugging without recompiling. Please "try before you buy VS2010" - I > haven't yet tried how advanced this new feature is - I have just heard about > it. And VS2010 does also have (I have heard) "step/play back" debugging > feature - when you can set/move current breakpoint several code lines back > (/several call stack levels up) and all the in-memory debugging context will > be reset back properly... > > Thank you. > > -- Shamil > > -----Original Message----- > From: dba-vb-bounces at databaseadvisors.com > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Saturday, June 12, 2010 7:16 AM > To: Discussion concerning Visual Basic and related programming issues. > Subject: Re: [dba-VB] Multi-project solution > > Michael, > > It's not so much the using / references as having a copy of all of the > properties in each project. > > I originally developed the code directly on the server. I used remote > desktop to log in, it was > just me, everything is "fine". Then I hired a fine fella to help me, and > started trying to get > organized. Set up a workstation for him, started getting the whole thing > running from the > workstation. > > Now the code running from either workstation takes about 10 times as long to > compile ( a couple of > seconds directly on the server... that long for EACH PROJECT on either > workstation. You can > actually watch it compile project by project. That isn't huge, it just > takes 15 or 20 seconds to do > a compile now instead of 2 or 3. However... > > Debug takes about a second or two PER STEP on the workstations. No se por > que. However when I > Google that I get a TON of hits. With a TON of DIFFERENT "go into the > project / properties / > somespecifictab and look for...". Well guess what, I now have a half dozen > projects to do this with. > > That SUCKS! I haven't found the fix, but I have spent a TON of time going > in time after time, > project after project searching through the properties stuff to see if I > have the specific fix that > worked for developer XYZ. > > It is waaaay more than just a reference and a using... > > I can see how projects would be cool if they are going to be pieces of many > different solutions, > however mine aren't, they are just an organizational tool for my single > solution. And yes, they > make organization neat however there is a rather large price IMHO. > > John W. Colby > www.ColbyConsulting.com > > > Michael Maddison wrote: >> Hi John, >> >> I think it's you bud :-) >> I think most people quite like compartmentalising their code using >> projects and NameSpaces. >> Adding a ref or Using is a small price to pay IMO. >> >> If your project is an internal project for your DBFH then 1 solution and >> 1 project is probably fine for you. >> However, I'd still break it down using namespaces, something like... >> Colby.DBFH.Forms >> Colby.DBFH.Data >> Colby.DBFH.Data.Services >> Colby.DBFH.Data.Entities >> Colby.DBFH.Data.Providers >> Colby.DBFH.Tools >> Colby.DBFH.Settings >> >> >> Each namespace can be it's own project or all mixed together any way you >> like. Put your classes in the appropriate namespaces and >> as the solution grows you will be able to keep organised. (and it looks >> nice in object explorer) >> >> >> HTH >> >> Michael M >> >> >> >> I launched in to building a C# application where I divided the solution >> into projects. >> >> It certainly seems to make sense, a solution can have multiple >> solutions, and each solution becomes >> an arm in a tree structure inside of the solution. >> >> OTOH each project has an entire set of properties all it's own. They >> are not inherited from parent >> (solution) properties. I don't claim to be any guru but it sure seems >> that many of the properties >> in the project really should apply to the entire solution. For example >> each project has a >> properties.Settings. However there is no Solution.properties object at >> all AFAICT, never mind a >> Solution.Properties.Settings. Thus (for example) I have a server name, >> a bunch of paths on the >> server etc. All of those things have to be declared over and over in >> each project's >> Properties.Setting or... have to be declared in one specific project and >> then that project >> referenced in every other project. >> >> Is it just me or is this project thing a lot of extra effort for what >> you get? What specifically DO >> you get? >> > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > >