Support/Recommendations for PCL/Xamarin.Forms?

[Mike-E-angelo]

I apologize if this is the wrong place for this. Please let me know if so.

I am converting my framework over to Xamarin.Forms. This of course uses PCLs and is outside of the scope of ETW. For service-side applications this is not a problem... I can continue to use ESP just as I have. However, for the client-side applications this is not the case. I am curious if you have any recommendations for this or if there is perhaps something clever that can be done to mimic ETW somehow. I would be most interested in doing this.

As sad as it is to say, I just went through the wiki for the first time and there is a lot to this project that I am not utilizing... so it would be awesome to leverage that somehow in the "new land" of PCLs/Xamarin.

Thanks for any assistance! Michael

[jonwagner]

Hm... ESP is built on top of the EventSource class, which depends on ETW, which is a Windows system feature. I don't think there's a way to make that portable.

However, at the core of ESP is generated IL to call a logging method on a base class. It might be possible to plug in a provider model to do the actual logging for other environments.

I'd love for ESP to be the preferred front-end for all of the awesome backend loggers like Log4Net, etc.

[Mike-E-angelo]

Well, to add to the complexity, Xamarin.Forms does not support dynamic code generation. Well, to be more specific, the iOS implementation doesn't (as Apple does not allow it). So, I'm investigating workarounds with that and AOT (ahead-of-time) compilation with Cecil.

It turns out that I've actually been using ESP totally wrong up to this point. A huge lightbulb went off yesterday while reading the fantastic documentation in the wiki. THIS is the way to log, and I too would like to see an ultimate logging solution based around this. :)

[jonwagner]

I've been planning the iOS version of Insight for a while. The way I'd approach AOT:

1. Mark interfaces with an attribute like [LoggingInterface]
2. Make a tool to parse Foo.dll and create Foo.Loggers.dll with the IL pre-generated.
3. Update the .As method to load from the alternate assembly.

[Mike-E-angelo]

Ah, that sounds great... although I am not familiar with .As ... is that something in Apple's runtime?

As for attribute, my vote would be for [EnableLogging] or [Tracer/Tracing/TracingProxy], since the interface is already the "Interface". :D

[Mike-E-angelo]

I should also mention that the "THIS" I mentioned earlier is in reference to the TracingProxy. Pure genius.

[jonwagner]

Ah, yes. TracingProxy is fun. My belief is that you should log everything and it should have an end-to-end correlation id.

Sorry, I meant .GetEventSourceAs (or TracingProxy) should load from the alternate assembly on iOS.

Maybe I need a Kickstarter to fund me to do this. :)

[Mike-E-angelo]

NICE!!! There you go. :)

If you mean correlation id as in ActivityId, then I am 100% with you. That was part of my lightbulb yesterday. As in... for example, every session that occurs is written to a FlatFile should be saved as the activity/correlation id for that session. That is one of the items I will be looking into.

[Mike-E-angelo]

As for Kickstarter... what really needs to happen is GitHub teaming up with Flattr or some other micro-donation site, and developers throwing down the love for other developers! I'd totally get you a virtual beer or two for this project, and donate for others. Good projects do save time, after all!

[Mike-E-angelo]

Another thought I just had around this is that Xamarin offers a pretty awesome Insights solution:

https://xamarin.com/insights

So maybe create a provider-based solution, one for services (ETW) and one for clients (Xamarin.Insights). The trick for the client proxies is working around the dynamic code generation, which can be done using a tool like you suggest or with Mono.Cecil (what the Xamarin engineers suggested when I was @ the Evolve conference earlier this year)... or maybe a combination of the two.

Of course, going down this route no longer makes it an proxy for EventSources... :P

[Mike-E-angelo]

More thoughts. :)

I'm thinking that it would be cool to create a new project based off of this one, called Insight.Diagnostics, and abstract ESP into it as a PCL. Insight.Diagnostics would have a new interface called something like ITraceDispatcher that would be used to dispatch messages to implementations. The two initial primary implementations would be EtwTraceDispatcher and XamarinTraceDispatcher. This solution would also involve the Foo.Logging.dll (or maybe Foo.Diagnostics.dll?) assembly creation discussed earlier in this thread. In fact, there might be a VSIX component that does this, and you can enable/disable Diagnostics Assembly Creation by right/clicking a project.

Logging is so fundamental and has been continually elusive with a good solution. ESP is the closest I've seen to it, and deserves to be done right IMO. :)