Debug Exe File under C# application

Question

0.00/5 (No votes)

See more:

Hi,

I have two applications which are communciating with each other thorugh Windows message.

From "Application1" I am launching "Application2" with some command line argument.
I am using Process class to start Application2 from application1.
Both applications are written in C# language.

My requirement are as follows:
1.When I start application1 on perticular condiction I am launching application2 by button click, when I press this button I want to start debug of applciation2.
2. As I am lanching application2 fromapplication1 , my debuging should start from main() methode.

If any body has done this before , please explain me steps.

Regards,
Somnath.

Posted 9-May-12 23:59pm

Somnath T Avhad

Add a Solution

Comments

BobJanova 10-May-12 7:09am

What do you mean by 'debug'? If you mean 'walk through source code', that's essentially impossible (I know it's not actually, but it's a hard problem).

Ed Nutting 10-May-12 7:39am

Try researching the Visual Studio "Attach to Process" option under the debug menu - it will let you debug processes for which you have the source code. Research it in Google before trying it but I think it's what you want.

Hope this helps,
Ed

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2012-05-10T08:25:00

Debugging communicating applications is not really a problem, but needs attention and accurate method. In particular, you can simply load two applications with two different instances of Visual Studio and operate separate debuggers with break points. The clownery with pressing buttons is totally redundant.

Also, I don't know the purpose of your application and suggested application-level protocol, but in real-life Windows application one part usually should be a Windows Service, not a Window application. If this is a case, you can do most of debugging with interactive applications (which is much simpler), and make a Windows Service when nearly everything is working. This is not a rule, though; you might want to create something purely peer-to-peer.

And finally, listen to a good friendly advice: give up communication using Windows message and never do it again. It cannot be reliable. Honestly. This type of communication is an artifact of old Windows legacy, is only specific to Windows and goes completely across the modern OS concepts, including Windows. By getting into this legacy mess, you immediately loose compatibility with everything, including future Microsoft OS versions. For your information, .NET applications, if written accurately and according to some standards, work without recompilation on many OS these days, not just on Windows. By using Windows messages, you loose all that. Even if you work on one machine only, don't do it. From the very beginning, use socket networking, named pipes based IPC, WCF (self-hosted, in your case) or even classical remoting. Note that both remoting and WCF internally use the same socket or named pipe channel, unless you choose to use anything else. All those methods are fully compatible with other OS and CLR implementations and have future. Windows messages do not. Don't waste your life on sorting out garbage.

—SA