Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Interop / March 2008

Tip: Looking for answers? Try searching our database.

How to capture "printfs" from unmanaged C++

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
barker7@yahoo.com - 07 Mar 2008 17:43 GMT
In my managed C# app we capture trace statements and direct them to a
log file using trace listeners. Part of the ap puses unmanaged C++
dlls, and unfortunately, the C++ printfs don't get picked up and are
simply printed to the console window.

Is there any way I can capture the output of the printfs and then
redirect them to the same file that the trace listener is writing to?

I do have access to the unmanaged C++ code if the solution involves
not using printfs. The important thing is that the C++ printfs and the
C# trace messages end up in the same file.

Thanks

Mitch
Jeroen Mostert - 07 Mar 2008 21:03 GMT
> In my managed C# app we capture trace statements and direct them to a
> log file using trace listeners. Part of the ap puses unmanaged C++
[quoted text clipped - 7 lines]
> not using printfs. The important thing is that the C++ printfs and the
> C# trace messages end up in the same file.

If the C++ DLL can be modified, you might consider making it a C++/CLI DLL
(in other words, a managed DLL itself) by compiling it with /clr. This will
make it trivial for the DLL to use TraceListeners itself, while still
keeping the ability to use unmanaged code.

If making it a CLR DLL is not an option, you could set a logging facility of
your choosing to be used instead of printf() calls (which is not good design
for a library in any case). The simplest way to do this is to pass a
delegate to C++ to be called whenever logging is necessary. This can be a
little tricky, since passing delegates to be used as function pointers
requires that you be careful about garbage collection. The alternative is to
expose a COM object that will handle logging, and invoke that from C++. This
can be simpler or harder than the delegate solution, depending on how good
you are with COM.

Signature

J.

barker7@yahoo.com - 07 Mar 2008 21:18 GMT
> If the C++ DLL can be modified, you might consider making it a C++/CLI DLL
> (in other words, a managed DLL itself) by compiling it with /clr. This will
> make it trivial for the DLL to use TraceListeners itself, while still
> keeping the ability to use unmanaged code.

Are you saying that if I make it a managed dll, then the output of the
printfs would get picked up by the existing trace listeners in the C#
code? Or would I need to change the printfs to Trace.WriteLine(...)
statements?

Thanks

Mitch
Jeroen Mostert - 08 Mar 2008 01:13 GMT
>> If the C++ DLL can be modified, you might consider making it a C++/CLI DLL
>> (in other words, a managed DLL itself) by compiling it with /clr. This will
[quoted text clipped - 4 lines]
> printfs would get picked up by the existing trace listeners in the C#
> code?

No. Unmanaged code (including printf() calls) would continue to work the same.

> Or would I need to change the printfs to Trace.WriteLine(...) statements?

Yes.

Signature

J.


Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.