Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would log to isolated storage and provide a way for users to submit the log back to the server using either a simple PUT/POST with HttpWebRequest or, if you're feeling frisky, via a WCF service.</p> <p>Keep in mind an XBAP only gets 512k of isolated storage so you may actually want to push those event logs back to the server automatically. Also remember that the XBAP can only speak back to it's origin server, so the service that accepts the log files must run under the same domain.</p> <p>Here's some quick sample code that shows how to setup a <a href="http://msdn.microsoft.com/en-us/library/system.diagnostics.textwritertracelistener.aspx" rel="nofollow noreferrer"><code>TextWriterTraceListener</code></a> on top of an <a href="http://msdn.microsoft.com/en-us/library/system.io.isolatedstorage.isolatedstoragefilestream.aspx" rel="nofollow noreferrer"><code>IsolatedStorageFileStream</code></a> at which point you can can just use the standard <a href="http://msdn.microsoft.com/en-us/library/system.diagnostics.trace_methods.aspx" rel="nofollow noreferrer"><code>Trace.Write[XXX]</code> methods</a> to do your logging.</p> <pre><code>IsolatedStorageFileStream traceFileStream = new IsolatedStorageFileStream("Trace.log", FileMode.OpenOrCreate, FileAccess.Write); TraceListener traceListener = new TextWriterTraceListener(traceFileStream); Trace.Listeners.Add(traceListener); </code></pre> <hr> <h2>UPDATE</h2> <p>Here is a revised answer due to the revision you've made to your question with more details.</p> <p>Since you mention you're using log4net in your desktop app we can build upon that dependency you are already comfortable working with as it is entirely possible to continue to use log4net in the XBAP version as well. Log4net does not come with an implementation that will solve this problem out of the box, but it is possible to write an implementation of a log4net <a href="http://logging.apache.org/log4net/release/sdk/log4net.Appender.IAppender.html" rel="nofollow noreferrer"><code>IAppender</code></a> which communicates with WCF. </p> <p>I took a look at <a href="http://blog.joachim.at/?p=31" rel="nofollow noreferrer">the implementation the other answerer linked to</a> by Joachim Kerschbaumer (all credit due) and it looks like a solid implementation. My first concern was that, in a sample, someone might be logging back to the service on every event and perhaps synchronously, but the implementation actually has support for queuing up a certain number of events and sending them back to the server in batch form. Also, when it does send to the service, it does so using an <a href="http://msdn.microsoft.com/en-us/library/018hxwa8.aspx" rel="nofollow noreferrer">async invocation of an Action delegate</a> which means it will execute on a thread pool thread and not block the UI. Therefore I would say that implementation is quite solid.</p> <p>Here's the steps I would take from here:</p> <ol> <li><a href="http://blog.joachim.at/?p=31" rel="nofollow noreferrer">Download Joachim's WCF appender implementation</a></li> <li>Add his project's to your solution.</li> <li>Reference the WCFAppender project from your XBAP</li> <li>Configure log4net to use the WCF appender. Now, there are several settings for this logger so I suggest checking out his sample app's config. The most important ones however are QueueSize and FlushLevel. You should set QueueSize high enough so that, based on how much you actually are logging, you won't be chattering with the WCF service too much. If you're just configuring warnings/errors then you can probably set this to something low. If you're configuring with informational then you want to set this a little higher. As far as FlushLevel you should probably just set this to ERROR as this will just guarantee that no matter how big the queue is at the time an error occurs everything will be flushed at the moment an error is logged.</li> <li>The sample appears to use LINQ2SQL to log to a custom DB inside of the WCF service. You will need to replace this implementation to log to whatever data source best suits your needs.</li> </ol> <p>Now, Joachim's sample is written in a way that's intended to be very easy for someone to download, run and understand very quickly. I would definitely change a couple things about it if I were putting it into a production solution:</p> <ol> <li>Separate the WCF contracts into a separate library which you can share between the client and the server. This would allow you to stop using a Visual Studio service reference in the WCFAppender library and just reference the same contract library for the data types. Likewise, since the contracts would no longer be in the service itself, you would reference the contract library from the service.</li> <li>I don't know that wsHttpBinding is really necessary here. It comes with a couple more knobs and switches than one probably needs for something as simple as this. I would probably go with the simpler basicHttpBinding and if you wanted to make sure the log data was encrypted over the wire I would just make sure to use HTTPS.</li> </ol>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload