Status update on fireing wmi events without administrative priviledges: I made it work.. somehow and _very_ hackish: since one cannot set permissions for fireing events (wmimgmt.msc) but one can set permissions to call a method, I decided to implement a trigger-event method on a wmi provider. The method worked fine for most tasks except when trying to fire events. Either it claimed that some System.Diagnostic(?).install dll couldn't be found or I got strange exceptions.. there was no way to get it working (I also tried with reflections..) - in the end I wrote a second app that triggers the event from args passed, since I can start apps fine from the method. Now as WMI runs as admin, the app gets administrative priviledges and the events are triggered. As I mentioned the method is very hackish and above all slow. Another approach might be to directly call the COM that fires events (probably with unmanaged code). If someone manages to get this done I'd gladly replace my method..
What remains to do is modify the log4net wmi appender to call the wmi method. Also my provider is decoupled, so the method can't be called if the provider isn't running. I think this could be resolved by writing a coupled provider (that runs inside WMI). Cheers, andreas -----Ursprüngliche Nachricht----- Von: Andreas Brauchli [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 28. Februar 2008 08:38 An: Log4NET Dev Betreff: AW: AW: WMI-Appender question That's the point, i don't know how to do it and this seems to be the consensus. Currently I'm working on a solution that provides a static WMI method that will fire the event for you.. unfortunately the method crashes in strange ways as soon as I start doing more than a simple return of the value.. anyway.. Thanks, I'll keep you updated if I find something andreas
