The new features or changes in this release are:

• Visual Studio 2010 RTM support
• New sql editor.  Create a new file with a .mysql extension to see it in action
• Please check the changelog and release notes for more information

What we know may be broken
Documentation is not yet integrated into VS 2010.

Please let us know what else we broke and how we can make it better!

It is now available in source and binary form from [http://dev.mysql.com/downloads/connector/net/6.1.html] and mirror sites (note that not all mirror sites may be up to date at this point of time – if you can’t find this version on some mirror, please try again later or choose another download site.)

This is a maintenance release and includes many bug fixes.  Please review the change log for details.

Thank you for using our product!

It is now available in source and binary form from [http://dev.mysql.com/downloads/connector/net/6.0.html] and mirror sites (note that not all mirror sites may be up to date at this point of time - if you can’t find this version on some mirror, please try again later or choose another download site.)

There are lots of bug fixes in this release so please review the changelog.

Thank you!

It is now available in source and binary form from
[http://dev.mysql.com/downloads/connector/net/6.3.html] and mirror sites
(note that not all mirror sites may be up to date at this point of time
- if you can’t find this version on some mirror, please try again later
or choose another download site.)

The new features or changes in this release are:

• Visual Studio 2010 RC support
• Nested transaction scope support

What we know may be broken
—————————-

• Documentation is not updated yet and is not integrated into VS 2010
• Some users are having trouble installing.  We are working hard to determine what is causing this problem.  These users may continue having trouble with 6.3.1.  Please be patient as we work through this.

Please let us know what else we broke and how we can make it better!

It is now available in source and binary form from
[http://dev.mysql.com/downloads/connector/net/6.3.html] and mirror sites
(note that not all mirror sites may be up to date at this point of time
- if you can’t find this version on some mirror, please try again later
or choose another download site.)

New features or changes:

• Visual Studio 2010 RC support
• Nested transaction scope support

What we know may be broken

• Documentation is not updated yet and is not integrated into VS 2010
• Data editing view (in VS) does not function in this build

Please let us know what else we broke and how we can make it better!

Inheritance security rules violated by type: ‘Class’. Derived types must either match the security accessibility of the base type or be less accessible.

After a little googling, I found this post that helped me solve part of the issue.  The other thing you need to do is go to your installer class and add the following attributes to it.  These will demand full trust for the installer class.

[PermissionSetAttribute(SecurityAction.InheritanceDemand, Name = "FullTrust")]
[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]

That’s it!  Your installer class should work with .NET 2 and .NET 4 now.

Understanding the plumbing

The first thing we need to understand is a little about how the trace messages are routed.  The main method we are interested in is TraceSource.TraceEvent.  Here is the signature.

public void TraceEvent(
    TraceEventType eventType,
    int id,
    string format,
    params Object[] args)

All the other TraceSource methods like TraceInformation eventually boil down to a call to TraceEvent.  TraceEvent will run through all the attached listeners and call the TraceEvent method on each.

The default behavior of listeners is to eventually call String.Format using the format given.  It plugs the parameters in and comes out with a string that can be sent to the console, to a file, or some other output.  Thankfully Microsoft saw fit to make TraceEvent virtual allowing derivative listeners to override and do interesting things.

How we use TraceEvent

Here is the signature for TraceListener.TraceEvent.

public virtual void TraceEvent(
    TraceEventCache eventCache,
    string source,
    TraceEventType eventType,
    int id,
    string format,
    params Object[] args)

eventCache is provided by the framework and contains information such as process id, thread id, timestamp, etc.

source  is the name of the TraceSource that provided the event

eventType is the .NET defined type of this event.  This can have values such as Information, Warning, Error, etc.

id  is the application provided event id.  This value is application defined and we’ll explain how we use it later in this post.

format is the parameters string message that listeners such as ConsoleTraceListener would use for output

args is the array of arguments available to plug into the format string.  This is the actual data for the event.

The key to using the data provided in TraceEvent is simply to know that the data always comes in a specific order and format.  The following information only applies to events coming from the mysql source.  The eventCache, source, eventType, and format parameters are self explanatory so we’ll start with id.

The id parameter is our MySql-centric event id.  We wanted to give very specific information about the type of event.  We have a public enum available in the 6.2 assembly called MySqlTraceEventType.  Here is the definition.

public enum MySqlTraceEventType : int
{
    ConnectionOpened = 1,
    ConnectionClosed,
    QueryOpened,
    ResultOpened,
    ResultClosed,
    QueryClosed,
    StatementPrepared,
    StatementExecuted,
    StatementClosed,
    NonQuery,
    UsageAdvisorWarning,
    Warning,
    Error
}

Before we talk about the event-specific data points, let me mention about a small problem we needed to solve.  We wanted to have a numeric id attached to each event that would allow all the events belonging to a given query to be gathered together.  The only way we could accomplish that was to use a counter that gets incremented each time a driver is opened.  (remember we needed a value that is unique on the same thread so we can’t use process id, thread id, or event MySQL server thread id). We’ll call this the driver id and every event that comes from the mysql source has this driver id as the first member in the args array.

Here’s a table that lists each mysql event and what the arguments array looks like.  Please keep in mind that these arguments start in the second element (index == 1)

Here’s the definition of the publicly available UsageAdvisorWarningFlags enum.

public enum UsageAdvisorWarningFlags
{
    NoIndex = 1,
    BadIndex,
    SkippedRows,
    SkippedColumns,
    FieldConversion
}

So that’s it.  This information will be documented and may change slightly as we find problems.  In fact we’ve already identified a small issue and may add a “current database” parameter to the connection opened event since the current database can be different than what is set on the connection string.  Be sure, when we make these changes they’ll be documented and by checking the version of the assemblies involved you can do the right thing.

Armed with this information you should be able to go forth and make very interesting trace sniffing apps for MySQL.  If you accept such a challenge, drop me a line.  I would love to know what you think!

This first post is a review of .NET tracing systems and how we changed our trace output.  The second post will cover how developers can use the new tracing format to develop new applications.

Tracing in .NET 1.x

.NET shipped with a very simple tracing system.  You have a static class named Trace that has static methods such as Write and WriteLine.  An application can use code like the following to output a message to the trace log.

Now that we have output our message, how do we direct it somewhere?  You do that with listeners.  There are a few standard listeners included in the framework (ConsoleTraceListener, XmlTraceListener, EventLogTraceListener) but you are free to create your own.  You can attach a listener at runtime or via an application configuration file.  There’s no need to show you how that is done.  You can easily find it on the web.  What we really want to talk about are changes in .NET 2 tracing and how Connector/Net makes use of it.

Tracing in .NET 2.x

Developers usually want to just trace a particular part of an application.  They may just want to get the network tracing or maybe just the file I/O.  To accommodate this, Microsoft created a new class named TraceSource.  You can really think of it as just a Trace class with a name.  Now when you add listeners via the config file you have to add them to a source with a particular name.  Here’s what it might look like.

<configuration>
  <system.diagnostics>
    <sources>
      <source name="TraceTest" switchName="SourceSwitch"
              switchType="System.Diagnostics.SourceSwitch" >
        <listeners>
          <add name="console" />
          <remove name ="Default" />
        </listeners>
      </source>
    </sources>
    <switches>
      <!-- You can set the level at which tracing is to occur -->
      <add name="SourceSwitch" value="Warning" />
      <!-- You can turn tracing off -->
      <!--add name="SourceSwitch" value="Off" -->
   </switches>
   <sharedListeners>
      <add name="console"
           type="System.Diagnostics.ConsoleTraceListener"
           initializeData="false"/>
   </sharedListeners>
 </system.diagnostics>
</configuration>

You can also specify a switch level, a filter level, and trace options (like should the output include process id, thread id, timestamp, etc).

Starting with Connector/Net 6.2, we have started using TraceSource to output our trace data.  Our source is named, cleverly enough, mysql.

Using the mysql trace source

Using our new tracing is very simple. Just use a configuration block similar to what I have above except use “mysql” as the name of the source instead of “TraceTest”.  One question you may have, though, is how to add listeners to our source at runtime.  You do that with the new MySqlTrace class.  Here’s how.

MySqlTrace.Listeners.Add(new ConsoleTraceListener());

Difference is in the details

We’ve also increased the level of detail included in our trace messages.  Each trace message includes a counter value that attaches it to other trace messages belong to the same connection.  We did this to enable the development of applications such as a powerful log viewer that will also serve as a visual trace listener.  With this app, a developer would be able to query the log output for various scenarios.  Examples would be “show me all queries where all the rows were not read

So where to from here?

There’s much more to say about our new trace output and, in my next post, I’ll go into the exact format of the data, and we (and you) can use that data to create new and exciting trace listeners.

It is now available in source and binary here and mirror sites (note that not all mirror sites may be up to date at this point of time – if you can’t find this version on some mirror, please try again later or choose another download site.)

The new features or changes in this release are:

• Connection pool cleanup timer.  We now utilize a timer that cleans idle connections that are no longer connected every 3 minutes
• We are now using stream and TCP-based timeouts to handle command timeouts.  This is more inline with what SqlClient does and should be more reliable than our old timer based approach
• Completely refactored MySqlConnectionStringBuilder
• We now support the TableDirect query type
• Completely refactored our logging system.  Our trace data is now published using TraceSource and has a specific format so to allow third party listeners to be created.
• Lots of bug fixes

Please let us know what else we broke and how we can make it better!