PDA

View Full Version : Re: Deploy Debugger



Stephen W. Meeley
18-Oct-2005, 08:09 AM
David,

I understand. I'm not sure how that would work out, on a couple of
levels. First there may be support DLLs, registry or other system goo
that is automatically there with the Studio installation and would mean
that you couldn't just copy the debugger onto a client system (we'd have
to check into that). But the bigger issue may be what happens in the
future as the debugger itself is less of a stand-alone entity and more
integrated into the Studio.

I think the main thing is to stay focused on the need (being able to
debug at a customer site if behaviors seem to be site specific) and not
a specific solution. It's something for us to discuss.

Also just to be clear... some of my responses are purely to clarify what
is or isn't allowed under the licensing agreements - they are not meant
to express an up or down opinion on the need itself (which I can
certainly appreciate).

Best regards,

-SWM-


-----Original Message-----
From: David Martinko [mailto:RedeemedSoftware@Hotmail.com]
Posted At: Monday, October 17, 2005 6:02 PM
Posted To: product-direction
Conversation: Deploy Debugger
Subject: Re: Deploy Debugger

Just to be clear... I am not asking for the ability to install the
studio. I
merely asking that as part of the client install, the VDFBug.exe can be
included.... the developer can then run the VDFBug.exe with the source
located in a specified directory.

Without the source, the debugger is useless... Unless you want to
re-engineer the program, you don't need the debugger and source... so it
is
only useful to the developer and dangerous if the developer were to
leave
these on the client machine... so why not let us be dangerous?

--
David Martinko
Redeemed Software
248-535-7495
RedeemedSoftware(SHIFT+2)Hotmail(PERIOD)com
www.redeemedsoftware.com

"David Martinko" <RedeemedSoftware@Hotmail.com> wrote in message
news:7jeNwS10FHA.2056@dacmail.dataaccess.com...
> OK, so I asked if we can deploy the debugger... and the answer is
NO... it
> wasn't meant to work that way. So now I would like to ask... Can you
make
> it that way?
>
> Now, I am not sure how a debugger really works and how it reads the
source
> files and all... But here's my thought:
>
> Add a cfg file for the debugger so it can be deployed with the
compiled
> packages. The cfg will allow the developer to point to a directory
> containing the compiled source (i.e. *.prn). On the client end, I
would
> deploy VDF as C:\Program Files\Common Files\Visual Dataflex 11.1\Bin
> The debugger would exist in the .\Bin directory... but it won't work
> without the source. So if I found myself needing to debug the program,
I
> could send the compiled source and place it in the .\Bin\Source. My
> VDFBug.cfg would contain a path of "Path= .\Source" so it would know
where
> to locate the source. I open the VDFBug.exe and attach it to the
> program.... the rest is history.
>
> Why? you ask. Because sometimes the client results are not the same as
the
> developer's. It would help to see what was happening on the client end

> causing the problem.
>
> Obviously, you wouldn't want to leave the compiled source on the
client
> machine... but it would be one more tool available to developers. For
> those who do a lot of version control, perhaps they could send the
source
> with their program in a password protected zip file so it was there
when
> they need it... at any rate, I would like to know who thinks they
would
> use this feature if it was made available.
>
> comments?
>
> --
> David Martinko
> Redeemed Software
> 248-535-7495
> RedeemedSoftware(SHIFT+2)Hotmail(PERIOD)com
> www.redeemedsoftware.com
>
>

David Martinko
18-Oct-2005, 08:25 AM
Stephen,

Quick answer. I just copied the debugger to a machine that has only the
client runtime installed for VDF11.0 and I placed the debugger in the same
Bin directory. I am able to run it and attach it to the VDF program. I also
placed the DBG file in the programs directory. I saw a list of pkgs but no
actual source... but there was no source on this machine. I didn't want to
guess at the internal pathing used to locate packages.

--
David Martinko
Redeemed Software
248-535-7495
RedeemedSoftware(SHIFT+2)Hotmail(PERIOD)com
www.redeemedsoftware.com

"Stephen Meeley" <stephen-m@dataaccess.com> wrote in message
news:1IrBpU%230FHA.3380@dacmail.dataaccess.com...
David,

I understand. I'm not sure how that would work out, on a couple of
levels. First there may be support DLLs, registry or other system goo
that is automatically there with the Studio installation and would mean
that you couldn't just copy the debugger onto a client system (we'd have
to check into that). But the bigger issue may be what happens in the
future as the debugger itself is less of a stand-alone entity and more
integrated into the Studio.

I think the main thing is to stay focused on the need (being able to
debug at a customer site if behaviors seem to be site specific) and not
a specific solution. It's something for us to discuss.

Also just to be clear... some of my responses are purely to clarify what
is or isn't allowed under the licensing agreements - they are not meant
to express an up or down opinion on the need itself (which I can
certainly appreciate).

Best regards,

-SWM-


-----Original Message-----
From: David Martinko [mailto:RedeemedSoftware@Hotmail.com]
Posted At: Monday, October 17, 2005 6:02 PM
Posted To: product-direction
Conversation: Deploy Debugger
Subject: Re: Deploy Debugger

Just to be clear... I am not asking for the ability to install the
studio. I
merely asking that as part of the client install, the VDFBug.exe can be
included.... the developer can then run the VDFBug.exe with the source
located in a specified directory.

Without the source, the debugger is useless... Unless you want to
re-engineer the program, you don't need the debugger and source... so it
is
only useful to the developer and dangerous if the developer were to
leave
these on the client machine... so why not let us be dangerous?

--
David Martinko
Redeemed Software
248-535-7495
RedeemedSoftware(SHIFT+2)Hotmail(PERIOD)com
www.redeemedsoftware.com

"David Martinko" <RedeemedSoftware@Hotmail.com> wrote in message
news:7jeNwS10FHA.2056@dacmail.dataaccess.com...
> OK, so I asked if we can deploy the debugger... and the answer is
NO... it
> wasn't meant to work that way. So now I would like to ask... Can you
make
> it that way?
>
> Now, I am not sure how a debugger really works and how it reads the
source
> files and all... But here's my thought:
>
> Add a cfg file for the debugger so it can be deployed with the
compiled
> packages. The cfg will allow the developer to point to a directory
> containing the compiled source (i.e. *.prn). On the client end, I
would
> deploy VDF as C:\Program Files\Common Files\Visual Dataflex 11.1\Bin
> The debugger would exist in the .\Bin directory... but it won't work
> without the source. So if I found myself needing to debug the program,
I
> could send the compiled source and place it in the .\Bin\Source. My
> VDFBug.cfg would contain a path of "Path= .\Source" so it would know
where
> to locate the source. I open the VDFBug.exe and attach it to the
> program.... the rest is history.
>
> Why? you ask. Because sometimes the client results are not the same as
the
> developer's. It would help to see what was happening on the client end

> causing the problem.
>
> Obviously, you wouldn't want to leave the compiled source on the
client
> machine... but it would be one more tool available to developers. For
> those who do a lot of version control, perhaps they could send the
source
> with their program in a password protected zip file so it was there
when
> they need it... at any rate, I would like to know who thinks they
would
> use this feature if it was made available.
>
> comments?
>
> --
> David Martinko
> Redeemed Software
> 248-535-7495
> RedeemedSoftware(SHIFT+2)Hotmail(PERIOD)com
> www.redeemedsoftware.com
>
>