Solved

COM+ Logging Services

Posted on 2003-12-11
4
715 Views
Last Modified: 2013-11-25
COM+ Logging Services

We're building a COM 1.0+ application using VC++ .NET.  The app has a database that will allows us to view most activity on the system, but we still would like to have a discreet logging mechanism to help us keep track of a few things that we won't store in our database (e.g. errors in communicating with the database).  What we're looking for are recommendations on simplifying our logging needs.

I know COM+ has its own logging mechanisms built in, though I'm not sure if we can (or should) expand on this to add our custom logging.

We have used the EventLog Class in a separate C# windows service application and really appreciated the ease with which we could handle logging.  Is there a similiar set of classes accessible via C++ that can be utilized in a COM+ application?  Should we create a "from scratch" mechanism that is specific to our needs and store that in a regular COM dll that can be accessed from both managed and unmanaged code applications?  I'd like to use the windows event log to make life simpler for our support staff to troubleshoot.  However, the real goal is to find the right balance of reusability and simplicity.

Any recommendations are greatly appreciated.

Regards,
Matt
0
Comment
Question by:MattWare
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
4 Comments
 

Accepted Solution

by:
nt_colonel earned 250 total points
ID: 9928529
I'd just use the NT Event log facility.  If you're using ATL for your component, the includes that expose these Win32 API functions should already be available to you.  If you're using MFC, then I'm not positive this will work.

void LogErr(BSTR strErrMsg)
{
      //Go ahead and use the Widechar versions of OpenEventLog(), etc. since everything
      //in COM is wide char anyway.
      HANDLE hEventLog = OpenEventLogW(NULL, OLESTR("Your app/dll name goes here"));
      ReportEventW(hEventLog, EVENTLOG_ERROR_TYPE, NULL, NULL, NULL, 1, NULL, (LPCWSTR*)&strErrMsg, NULL);
      CloseEventLog(hEventLog);
}

Now, with this, the Event Log subsystem will more than likely print something at the beginning of your events about you not using a registered event source, but it doesn't really hurt anything.

There is a way around it doing that by using some resource-only dll that came with the .NET runtime, but I don't remember exactly how I did it last time.  Look at RegisterEventSource() in the MSDN library, if you want to expend effort on having a bona-fide registered event source.
0
 
LVL 2

Author Comment

by:MattWare
ID: 9952145
Thanks so much for your feedback.  I followed up on your recommendation to research the RegisterEventSource Method.  I created the following function within my main COM component:

int MyCOMObj::LogEvent(LPCSTR*pErrorMessage, MyCOMObj::eEventType eEventType)
{
    long lEventID = 0;
    CERBEvent::eLogType eLType;
    CString sServerName;

    //I'll implement this later to handle different
    if(eEventType == CERBEvent::eEventType::EVENT_TYPE_INFORMATION)
        eLType = CERBEvent::eLogType::LOG_TYPE_INFORMATION;
   
    HANDLE hEventLog = RegisterEventSource(NULL, "MyCOMApp");  
    ReportEvent(hEventLog, EVENTLOG_ERROR_TYPE, 0, 0, 0, 1, 0, pErrorMessage, 0);
    return 0;
}

As you had said, indeed it still doesn't like the fact that my event isn't registered, but the message can still be seen as follows:

The description for Event ID ( 0 ) in Source ( ERBCOM ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: Test Error Message.

This meets my immediate need, but if you've also got a handy way (minimal coding) to get that event registered, I'd feel more confident rolling this out for the support staff to use.  However, I do feel that you've sent me down the right track.  

Any further ideas on registering events in a simple manner is greatly appreciated.  

Thanks,
Matt
0
 

Expert Comment

by:nt_colonel
ID: 9953768
Ok, I found my notes on creating an event source.  Its somewhat of a hack, because technically, you're supposed to make you own resource-only dll, but why bother when the .NET runtime has one for you already?  This is the same DLL that VB.NET uses for its event-sourcing needs in every VB.NET program, so it can't be all that bad to use it.

Create the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\MyAppOrDLLName

In this key, you will place a <right-click context menu>->New->"String Value" called "EventMessageFile".  It should show in regedit as a type REG_SZ.  The value should be set to the path of your (borrowed) resource-only dll.  On my system, it looks like this:

C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705\EventLogMessages.dll

You may be able to copy that EventLogMessages.dll file to somewhere else if you want.    I don't see why you couldn't.  At any rate, that should be about all there is to it.

I think that if you use this dll you may have to use an event type of 1 or an event ID of 1 or something like that.  I had it working when I was playing with it once and it seems to me that might have been the case.

Also, you want to make sure you close the HANDLE hEventLog in you code.  I think MSDN suggests using DeregisterEventSource().

If you don't, you may end up with a handle leak situation, and from what I've read elsewhere, handles are one of those "scarce resources".

I'm guessing that since they're kind of an OS-intrinsic thing, it might make the OS grind to a halt if you leaked enough of them over a long enough period of time.
0
 
LVL 2

Author Comment

by:MattWare
ID: 9956248
That was pretty cool.  I made the registry changes you recommended and the test messages I had created yesterday now only contained the message I had originally wanted.  I thought the registry change would affect new events, but apparently it also corrected existing ones.  I had used an ID of 0 on those messages and I'm pretty sure an event id of 1 would have no effect, but I'll try it out.

Anyway, that was exactly the kind of solution I was looking for.  Thanks for your help and as far as it being a hack - I won't tell if you don't.

Matt
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

If you’re thinking to yourself “That description sounds a lot like two people doing the work that one could accomplish,” you’re not alone.
In this post we will learn different types of Android Layout and some basics of an Android App.
The viewer will learn additional member functions of the vector class. Specifically, the capacity and swap member functions will be introduced.
In this fourth video of the Xpdf series, we discuss and demonstrate the PDFinfo utility, which retrieves the contents of a PDF's Info Dictionary, as well as some other information, including the page count. We show how to isolate the page count in a…

749 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question