Perpetual rebuilds

[xwb]

I can't understand why C# decides to go through the entire build process whenever I click on run in the debugger.On a small project, it takes half a minute to go through all the assemblies before it even starts. This happens regardless of whether the program has been built or not. It is just so annoying and a total waste of time.

Is there a way of saying "Just run, do not rebuild".

 

[macleod1021]

I haven't noticed that problem. When I'm working on a solution and hit F5, it only does a rebuild if I've changed sourcecode. If you've changed source code then you WANT the build to occur.

im in ur stakz, overflowin ur heapz!

 

[monkhandle]

C# doesn't have classic intermediate files, so all sources (in same project) must be compiled each time, even if only one of them was changed. For entire solution (when more dependant projects) only projects that are dependant on changes, are rebuilt. However, VS and C# Express are notoriously slow at checking whether project needs to be rebuilt... classic unix makefile ftw !

 

[xwb]

The problem is when none of them has changed.

Say I changed some code. Hit F5, it goes through every single DLL in the solution, copying files to and fro and then runs. I've found a problem but not the cause so I set a breakpoint somewhere, stop the program, hit F5, it goes through every single DLL in the solution, copying files to and fro and then runs. This copying process will be repeated whenever you hit F5, even if it is immediately after a ctrl-shift B (build solution). I'm running a solution with about 30 DLLs and it is taking at least 30s to even get started.

I've switched off the file copying but it still attempts a relink of some sort. I'm just wondering why this is necessary. No other language has this problem.

 

[jmeckley]

the 30 ddls are probably to blame. why so many assembly references?.

I know the frustration of manually debugging only to find an unexpected error. You may want to look into unit/integration testing frameworks like MbUnit or nUnit. I prefer this method as I can run hundreds of tests in only a fews seconds/minutes.

another option to compiling solutions is nant. similar to msbuild which is what VS uses when you press F5 or SHFIT CTRL B. nant isn't for the uninitiated though. I still am not comfortable with it and default to SHIFT CTRL B.


Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[JurkMonkey]

Are the 30 dlls created from projects in your solution or are they external dlls?

You can turn off the "Copy Local" property on each reference if they are external - and you can turn the option to build the dll off for each project if you don't ever touch some of them.

http://www.ubuntu.com/

 

[xwb]

I'll give nant a try. Anything is worth a try when you're working with the frustrating combination of Vista and VS2005 in C#.

30 are from the projects in the solution. It is something I've inherited. Why so many DLLs? I've got no idea. This is only a small project. Builds in about 5 minutes.

I've seen large projects with over 100 DLLs where the local copy goes absolutely crazy. If you do a search for DLLs in the solution which hasn't switched off the local copy, it is a few thousand. The space used in a full system build is in the region of 7Gb (sources and objects). That had 50 to 100 copies of every DLL.

I've turned off local copy but I wouldn't be surprised if someone else in the team or Visual Studio turned them on again.

We do use nUnit for the graphics testing but when there is some underlying flaw in the logic it is just so painful working on it.

I spend half my time fighting the system. If it isn't builds, it is code being wiped out by visual studio. If it isn't that, it is visual studio holding on to a DLL, and then telling me it is in use. If it isn't that, it is VS just taking 5 minutes to write out a report to MS before it crashes, taking all my changes with it. I am actually very unproductive and spend very little time writing code or debugging it.

 

[jmeckley]

I would either begin by combining projects to reduce the number of assemblies. you can also do this with nant. have multiple projects but compile into 1 dll, or just a few.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[xwb]

It reduces the problem but how do I get it to just run without it rerunning the build mechanism and postbuild events?

On C++ and VB6 (I haven't tried VB.net), it just goes: no messing about. With VC# it seems to go through some make of some sort. If I make the mistake of doing a build before pressing F5, it goes through the same thing again. It is like watching to someone with Altzeimers. They can't remember what they've just done and do it all over again.

 

[jmeckley]

yes, that's the way it works.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[litton1]

Pressing CTR + F6 will build just the project that you are working on, it does on mine anyway?

Age is a consequence of experience

 

[litton1]

Apologies for my last post, you was discussing running not building.

We actually had the same problem a while ago. Our solution was to have the projects that we work on daily in one solution and a separate one for the projects that are rarely worked on. It now runs in a microsecond. Don’t know if this would work for you?

Age is a consequence of experience

 

[xwb]

Sounds like it will work. Only problem now is refactoring so that I have less DLLs and and making up the solutions.

It was one of those RAD designs which may have been quick, a bit difficult on the first set on enhancements and badly in need of refactoring on the second set of enhancements. It may have been rapid the first time round but by the time it gets to the third generation, you really wonder at the decisions that were made.

 

[litton1]

Something sounds familiar . . . <( ~ _ ~)>

Age is a consequence of experience