The Old Joel on Software Forum: Part 3 (of 5) - HowTo: transportable development environment?

HowTo: transportable development environment?

The project I currently work on involves some hardware
related components. Debugging offline is often not
possible - we have to go straight to the computer
(Win2000 boxes) where the problem occurs and start
searching.

Problem: these computers have no development tools
installed on (no VC7, etc.), so "debugging" often
means guessing and being lucky.

Hence, we recently had the idea of a "transportable
develoment environment", i.e. an external hard disc where
all the tools we need (VC7, Eclipse, InnoSetup, etc.)
are installed on. The plan was that, in case of a bug,
we would go to the afflicted PC, plug in our HD, fire
up the tools we need and find the trouble in no time.

It works - ALMOST. First, registry settings are lost
when working on another computer. While this turned out
to be a manageable problem, Visual.NET spoiled our concept.
It requires so many additional components - IE Explorer 6,
Service Pack XY, ADO whatever - that it virtually can't be
started on any other computer than the one it was originally
installed to.

Should we change to another C++ IDE (such as Dev-C++ ?)
Accept reality as such and give up?

Ideas anyone?

- Roland
Wednesday, November 19, 2003

Hi ya Roland,

I haven't used .net at all, but both codewarrior and realbasic provide remote debugging options...point the debugger at a remote machine by ip and debug from your own machine.
(so a portable hd wouldn't work, but a laptop would)

<g> my point is _not_ to use codewarrior or realbasic, just that I would be astonished if .net doesn't have _something_ of a similar nature.

how hard have you looked?

FullNameRequired
Wednesday, November 19, 2003

We have similar issues and we do the following:

We generate process dumps in error conditions. These you can copy to a normal dev machine and open in the debugger. Some types of problems easy to debug in this way.

If we need to debug a running machine we use windbg. This is MS's low level debugger. It requires no installation. You can drag copy it, or even run it across the network. It's not as not as pretty as MSdev but it's quite serviceable and a good tool to know:
http://www.microsoft.com/whdc/ddk/debugging/default.mspx

Mark Zeren
Wednesday, November 19, 2003

You might want to consider this:

http://www.identify.com/solutions/appsight-console-win.html

Used to be known as BugTrapper. It'll let you log pretty much everything on the misbehaving client, ship the log back to your dev box, then let you step through the state of the software and find out what's going on.

Chris Tavares
Wednesday, November 19, 2003

I guess you tried Remote Debugging with DevStudio (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/html/vxoriremotedebuggingsetup.asp)...

Usually it's the best way to debug paint/focus issues with applications. Should probably work fine for hardware unless it's network devices, then WinDbg would be the right choice.

WildTiger
Wednesday, November 19, 2003

Thanks. The WinDbg link was really valueable, and I'll also give AppSight a second look.

Funnily enough, just today I read something about AskIgor [http://www.st.cs.uni-sb.de/askigor/], a web service which claims to be an automated debugging server. Just enter a few infos, press the "Debug it!" button, and there you are.

Whoa! Sounds really cool. Unfortunately, this works for Linux executables only, so perhaps we should change the platform instead of the IDE ... ;-)

- Roland
Thursday, November 20, 2003