Just wondering... Space complexity?
I know I can do workarounds with #defined DEBUG, but
Debug must be replaced wit Trace
The original rationale was that Silverlight didn't have it. However, now that we're rebasing our Base Class Libraries atop 4.5 instead of Silverlight....
That's a very good question. We'll discuss adding the Trace class to our profile for the beta releases.
We will be adding System.Diagnostics.Trace in a future release.
Note: This does not include System.Configuration.dll support, .config file parsing, System.Diagnostics.Switch, Trace.CorrelationManager, and anything depending on those. (So no configuring your Trace switches from a config file.) The reason for this is that we explicitly exclude System.Configuration.dll because including it would pull in most of System.Xml.dll, significantly increasing the minimum app size.
OK I thought original rationale was - Silverlight did not have it, but there is a lot stuff (like sync methods) in Mono Mobile profile added.
This is no criticism - just need to know why where and when You did draw a line to do it or not. For example I use sync methods a lot to do proof-of-concept in hours/days. Today/tomorrow with async rewrite will be quite easy.
When porting libs and apps, we hit a lot problems like this one with Trace. And I think it is quite fundamental to write some kind of log. OK Silverlight does not allows it, but this is kind subject to discussion too right? OK where to write/dump and how... But in OutOfBrowser this makes a lot of sense - OOB is for me "desktop" app.
Regarding porting - I try to make original code intact as long as it goes. That is the reason I asked about trace.
Configuration is one opened question too. Yes I was afraid System.Xml.dll would be pulled in, but why not leaving that as an option for enterprise apps. You (Xamarin) and rest of us have bad luck to port mostly from desktop to mobile, where it is all about reduction and not exstension. And the first one is PIA. Even worse if one has to work with server side assemblies like log4net (I needed whole day just to split netfx client profile and asp.net). Besides there is "no .config movement", but that is hype like everything. We need to store config and settings xml, json, ini does not matter, I dump my objects into files (that is the reason for SharpSerializer port) and I'm OK, but for fast-time-to-market config stuf would not hurt as optional reference.
In this case I think there is no need to dicslaim that something will not be included (.config parsing).
BTW what is so big in System.Xml? Parser? Would it be possible do parse .configs with Linq2Xml?
Just to retain API? I don't know never looked at it, needs work for sure.
So this is almost decided to add Trace? You are really fast.
"Adding Trace" is perhaps an oversimplification. I added the System.Diagnostics.Trace type.
However, adding the Trace type does not mean adding the entire "Trace-related" infrastructure. These are the files compiled into the MOBILE profile. What's missing from that list? Switches: there's no Switch, SourceSwitch, or anything related to Switches.
Also missing? System.Configuration.dll.
So let's step back a bit.
Historically we started with the Silverlight profile and added stuff that we required or that early customers requested (e.g. the non-XLinq System.Xml stack). Then we slowly added some bits and pieces back, but not lots.
With the beta release, e.g. Xamarin.Android 4.7.x, we're flipping things around: instead of starting with Silverlight and adding stuff, we're starting with .NET 4.5 and removing stuff.
What are we removing? Anything that would dramatically increase our minimum application size. We may slightly regress our minimum app sizes, but we want to make any such regressions as small as possible.
Chief item on this list? System.Configuration.dll. The problem with System.Configuration is that once it's in the door, the entire XML stack comes along for the ride, and the linker can't remove it because it's used from ~everywhere. System.Xml.dll is 1.2MB, so that would be at least a 1.2MB increase to minimum app sizes.
We're not going to do that.
So System.Configuration.dll is out the window, which means anything that depends on System.Configuration is out the window. Which means no .exe.config support, no DiagnosticsConfigurationHandler, and no configuration-based Trace information via .exe.config files. (Among lots of other things.)
That said... It is possible to add Switches while avoiding the System.Configuration.dll dependency (patch). The question is, would this be at all useful or desirable? The only way to set switch levels would be through e.g. the SourceSwitch(string, string) constructor or the SourceSwitch.Level property.
If you think System.Configuration-less Switches would be useful, we can certainly add them, as it should be linker-friendly and not add anything to your app unless you actually use them.
System.Diagnostics.Switch/etc. have been added to the Mobile profile, again with the provision that there is no .exe.config file support, so you'll need to manually provide the Switch values to use.
Sorry I don't understand all the intricacies of this.
I'm sure you are correct in your approach etc.
But all I can see is that System.Diagnostics.Trace does not exist in Xamarin Android.
My current thought to work around this is to create my own trace class...
since at least then my existing code that expects it to be there won't break.
Something like this (not tested) ...
public static class Trace
public static void WriteLineIf(bool condition, string message, string category)
if (condition) Android.Util.Log.Info(category, message);
Otherwise I have to put in #if !ANDROID next to every Trace.WriteLineIf()
(100s of lines of code)
Is System.Diagnostics.Trace only available on an alpha/beta build right now? I cannot find it in the Xamarin Android API.
Sorry for delay, but I'm on vacation with my kids, so I'll try to be short:
it is available on alpha channel (here on my laptop I have alpha), for beta I need to return back home and this will be in a week.
I have started to write my own Trace implementation, but before diving in I wanted to ask why was it removed and Jon gave excellent explanation and I don't need config stuff (xml)
Xamarin Inc., as a wholly-owned Microsoft subsidiary acting as a separate legal entity, adheres to the Microsoft Privacy Statement: Privacy & cookies