OK, following log4net’s versioning scheme in NuGet package wasn’t a good idea. In version 1.2.11 the new keys were used and I used this as a fresh start. I didn’t realized that thanks to semantic versioning everybody will be updated to latest version and dependencies will be broken. My fault.
If you read my previous log4net post there’s a solution with modifying
package.config file, but… So to fix it package owners were forced to repack the dependencies to be
=. Not good.
So today I pushed version 2.0.0, which is actually 1.2.11 with new keys, and 1.2.11 was removed. So there’s now on NuGet the new major version and dependencies need to be explicitly stated to be compatible with it (again, it’s 1.2.11 with new keys).
Fire is quenched, hopefully.
It turned out, that the previous maintainer of log4net NuGet package @dotnetjunky was assigned mistakenly. So nobody was actually maintaining that package. After few messages with him, we decided, I’ll take over the ownership and maintain it.
I still use NLog in my projects, as I like it a little bit more. But I know, there’s big community around log4net, with my coworker Ales included.
Today I uploaded package with new version 1.2.11 , and I’ll try my best to keep the package up-to-date. Enjoy.
 I used the binaries signed with new key so any new dependencies will follow this recommended usage.
Previous version of ADO.NET provider for Firebird brought us a support for command tracing. Although it was good, it could be done better. Few interesting scenarios came back to as a valuable feedback and with the old implementation it was hard to do it.
The new one builds on top of TraceSource class allowing you to handle different sources from trace messages easily and independently. The what’s logged is same, but now every message is traced through
FirebirdSql.Data.FirebirdClient source, hence you can easily i.e. turn it of (and just these messages, without affecting other messages) or send it to i.e. console window. Just a few lines in
app.config and you’re done.
<add name="console" type="System.Diagnostics.ConsoleTraceListener"/>
The code above sends all messages (commands) from provider to (only) console window. You can use your own listener, of course or turn it off completely, using just the
I recently improved the command logging in ADO.NET provider for Firebird. Let me start with little bit of history and then you’ll see the motivation and current improvements.
Before I added simple
Debug.WriteLine to the
FbCommand class. This was mainly driven with need to easily see commands I was generating for Entity Framework. Then the Visual Studio 2010 came with the IntelliTrace (only Ultimate version) and while working with MS SQL Server I was happy to see commands without any additional effort. I wanted the same for Firebird too. Sadly the IntelliTrace right now isn’t publicly pluggable. I was still using the debugging code, but often when doing development on customer’s applications using released version of provider I lost this ability. No debug outputs, no IntelliTrace.
Because I believe it’s important to have easy way to see (and not only for Entity Framework’s generated) the command, to spot performance problems early, I added simple logging facility. This logging is enabled for all builds (not only debug) and uses Trace class from .NET Framework. Everytime you
Prepare method is called also automatically before execute if not called manually) command you’ll see the command text and current parameter names and values (if any). If you’re inside Visual Studio you see by default the output in
Output window. You can also configure it to log i.e. to file, probably usable in staging and/or production.
Hope you find this useful as I do.