MySQL Bugs: #69760: Connector 6.7.4 does not register as dataprovider in machine.config

Bug #69760	Connector 6.7.4 does not register as dataprovider in machine.config
Submitted:	17 Jul 2013 0:10	Modified:	28 May 2014 5:49
Reporter:	David Ferguson	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / NET	Severity:	S3 (Non-critical)
Version:	6.7.4	OS:	Windows (Windows Server 2008 R2 Enterprise 64-bit)
Assigned to:	Gabriela Martinez Sanchez	CPU Architecture:	Any
Tags:	c6.6.7 c6.7.5 c6.8.0, t1.0.3 t1.1.0

Description:
the previous MySQL Connector/Net installer (version 6.6.5) registers MySQL in the machine.config as DbProviderFactories provider. however, the 6.7.4 MySQL Connector/Net installer no longer adds MySQL to machine.config DbProviderFactories.  

i see Bug #69698 which talks about needing to install MySql for Visual Studio.  however, Visual Studio is not installed on my machine, nor do i have the option to install it.  what i need is to have a third party application (which uses the .NET Framework data provider factories) be able to see (via machine.config) that MySQL Connector/Net is available as a provider.  how do i install MySQL Connector/Net to do this?

How to repeat:
install MySQL Connector/Net installer version 6.7.4 with any option
check Windows\Microsoft.NET\Framework\vx.x.x\Config\machine.confg, <DbProviderFactories> section.  MySQL is not included.

fixed category to MySQL Connector/Net

I am having the same problem w/C-net 6.7.4 with VS2012 installed and MySQL for Visual Studio 1.0.2 installed. The only MySql entries in Machine.config are in the system.web section: Membership, Profile and Role providers registered with MySql.Web.... assemblies. Nothing in DbProviderFactories.

I also note that the only 6.7.4 assembly installed into the GAC is MySql.Dat.CF. Not MySql.Data or MySql.Data.Entity. Even if I add either of these as DbProviderFactories in my App.Config, I can't get VS to find the provider when I try to add a datasource.

I did have all this working last week, but have been struggling with the installs since then, getting other pieces to fit together. I suspect that the order of installing Connector/Net 6.7.4 and MySql for VS, and whether MySQL Installer is used vs the standalone connector msi package is used may play a role. I'm still experimenting.

I did have success getting MySql.Data.MySqlClient registered as a DbProviderFactory in machine.config after uninstalling both Connector/Net 6.7.4 and MySQL for Visual Studio 1.0.2 and then reinstalling them both in one pass with the MySql installer. 

I now seem to have the access to create Data Connections in VS without problem. I note that nothing changed in the GAC (only MySql.Data.CF 6.7.4.0 registered) but that may be a whole different story. I'm back and functional.

yes, when i tried installing *both* 
   MySQL Connector/Net 6.7.4 
   MySQL for Visual Studio 1.0.2
on a machine that has Visual Studio, everything worked; MySQL was registered as a DbProviderFactories provider in machine.config.

however, my problem is that i have a machine that does not and will not have Visual Studio installed.  this prevents me from installing 
   MySQL for Visual Studio 1.0.2
in this case, how would i get MySQL to be registered as a DbProviderFactories provider in machine.config?

Alistair,

If the machine doesn't have Visual Studio installed, is it a deployment machine? If so, have you tried adding the following to the App.config file
  <system.data>
    <DbProviderFactories>
      <add name="MySQL Data Provider"
      invariant="MySql.Data.MySqlClient"
      description=".Net Framework Data Provider for MySQL"
      type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.7.4.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
    </DbProviderFactories>
  </system.data>

and then including MySql.Data.dll with your app install?

Hugh

thanks for the suggestion Hugh.  

yes this is a deployment scenario.  with the previous Connector/NET release 6.6.5, the user simply installs MySQL Connector/NET on their machine, and they're ready to use our app.  

before resorting to having the user modify an App.config, or modifying our app/install to bundle the mysql dll, i'd like to know if there's anyway to achieve the clean deployment described above, using the new 6.7.4 release.

Thanks for your bug report,

As stated above the workaround is to adding to the *.config file of your app this line inside 

<system.data>
  <DbProviderFactories>
      <add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient" description=".Net Framework Data Provider for MySQL" type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.7.4.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" 
  </system.data>
</DbProviderFactories>

Removing the provider from DbProviderFactories was intentional for 6.7 (6.6 & 6.5 still have it). This due to the Visual Studio plugin now being responsible of adding DbProviderFactories setting.

Since then we have realized that this leads to inconsistencies (like user code invoking factory = DbProviderFactories.GetFactory("MySql.Data.MySqlClient");)
may return another version than the last installed with Connector/NET 6.7.x

We are working on a fix (but we also need to provide a complementary fix for "MySql for Visual Studio" plugin so is not broken with this fix).

ok, thanks for the confirmation Fernando.

This breaks our deployment scenario for our customers that have MySQL databases. Our application can use any registered data provider so having to bundle and register MySQL ourselves isn't something we want to do. To avoid issues we've recommended our users to install an older version of the MySQL data provider.

Now, round about 14 days later we've still no fix?

Sorry guys, I know how hard it can be to develop and search for incompatibilities but 14 days????

Serious question to whom it concern:  Was he (the one who's removing the DBFactory registration from connector installer to visual studio plugin) thinking a litte bit out of his dish? What about the web-Servers without Visual Studio installed? What about the testing environments? Sorry, but that was a shot in his knee. 

After reporting and has knowledge about that problem it tooks more than 14 days to fix it?

All I can say here is: great job ;-)
Let you customers and/or community alone whit that problem.

I remember the old time ... but ok... 

Sorry I'm a litte bt pissed about the situation, 'cause some of our customers are shooting my weekend into the wind due to installing this xyz Connector...

I am also desperately waiting for a fix to this problem as our customers are not using Visual Studio so this is crippling to our product. As a temporary fix to this issue, is there anyway to detect on the system if this version is installed? That way we can point our customers to install a previous version that doesn't have this issue.

Hi guys, right now there is a good workaround, sorry for the inconvenience if I didn't explained myself clear enough.

As already mentioned in the comments here, you can always add a custom entry in maching.config.

Now, what can go in maching.config, can also go in web.config and app.config for a .NET app.

So for an ASP.NET app, you can change your web.config to add the entry like this:

<system.data> 
<DbProviderFactories> 
<clear/> 
<add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient" description=".Net Framework Data Provider for MySQL" type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.7.4.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" /> 
</DbProviderFactories> 
</system.data> 
<connectionStrings> 

Then when the app (or web app) has loaded, it will have access to the provider to DbFactory calls, Entity Framework code first, etc.

As for the fix, the delay is due to the fact that in only affects 6.7.4 (not 6.5 & 6.6) and that it must be at the same time than a corresponding fix for MySql for Visual Studio (so that product is not broken with the fix) and finally because the workaround seems rather simple.

If the workaround is not acceptable, please elaborate.

In our case, this work around would be perfect if we had some way of detecting whether the user has this version or not. Is there some way we can determine that information?

That's very nice (and I know that - I'm using MySQL since ...a very Long time 2004 or so)

But that's not a very helpful solution for web-sites. I don't know which Connector get's installed or used from a user. 'til 6.5.4 it's ok but then we run into trouble. 

Maybe you'll explain how (and why) difficult it is to reinsert code into the MySQL installer which installs the neccessary Information into GAC and machine.config (without a Visual Studio in front).

;-)

Best regards
Christian

You can programatically change the config with this

      DataSet dataSet = ConfigurationManager.GetSection("system.data") as      System.Data.DataSet;

      DataView vi = dataSet.Tables[0].DefaultView;
      vi.Sort = "Name";
      if (vi.Find("MySql") == -1)
      {
        dataSet.Tables[0].Rows.Add("MySql"
          , "MySql.Data.MySqlClient"
          , "MySql.Data.MySqlClient"
          ,
          typeof(MySql.Data.MySqlClient.MySqlClientFactory).AssemblyQualifiedName);
      }

We have used that chunk in code first unit tests.

The fix in the installer (wix) is rather simple (I have already discussed the other dependencies of this fix in this bug), we don't plan to make a 6.7.5 release soon (next weeks), but if you prefer I can give you the patch code for Wix.

As for checking the current Connector/NET version installed, you can see this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MySQL AB\MySQL Connector/Net
which has the data:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MySQL AB\MySQL Connector/Net]
"Version"="6.7.4"
"Location"="C:\\Program Files (x86)\\MySQL\\MySQL Connector Net 6.7.4\\"

I just ran into this and I find it extremely annoying and ridiculous that the GAC entries are not included, nor the machine.config entries in this installer! Doesn't matter if there is a new Visual Studio installer, some people are familiar with getting the Connector downloaded and installed with this installer and EXPECT it to install itself into the GAC and machine.config.

Yes, I know about the workaround and we do that already for our ASP.NET web sites, since on our production servers we ALWAYS bin deploy MySQL and never install it into the GAC anyway (much safer to avoid having to run installers if we upgrade it, and some web site can run back level versions if they have not been tested with the latest).

However that does not work for situations where you need to develop on the machine and the code requires it to be in the GAC. The two bits of code I require this for, is when I am running unit tests that use MySQL, or when we are running custom T4 templates in Visual Studio to read the MySQL schema from the database.

At this point I am uninstalling the connector and will be off to install the latest MySQL server, which stupidly now includes the Visual Studio plugin!?

Well I installed the latest installer for MySQL Enterprise and it installed Connector/Net along with the Visual Studio tools. Guess what? Nothing was modified in the machine.config and the assemblies were NOT installed in the GAC?

I had to manually install them into the GAC as well as manually modify the machine.config file.

Seriously, this should have been fixed a LONG TIME AGO!

Hi thanks for your feedback,

As mentioned above neither Connector/NET 6.7.4 nor MySql for Visual Studio 1.0.2 add nothing to the GAC currently (Cnet just add registry keys to list its assemblies in "Add reference" dialog in VS and Plugin copies all assemmblies to PrivateAssemblies folder at Visual Studio install path).

And Only MySql for Visual Studio registers its Cnet at machine.config.

While you can install at GAC the Cnet 6.7.4, this will break MySql for Visual Studio plugin (similarly installing at GAC the Connector/NET shipped with plugin (6.6.5) will break Cnet 6.7.4 in several scenarios).

The reason Cnet 6.6.5 was included in plugin was because plugin (M4VS) was released first and cnet 6.7.4 was not GA ready yet.

Of course this had many implications, in future releases (likely cnet 6.7.5 and M4VS 1.0.3) this will be fixed.

I just mention this, because just installing in GAC will break other things until both products are fix properly.

Thanks.

Posted by developer:
 
Along with the registration of the DbProviderFactory an assembly binding redirection should be added to the machine.config so Visual Studio registration works well with Connector/Net.

Fixed as of the upcoming Connector/Net 6.7.5 release, and here's the changelog entry:

The Installer did not register MySQL in the "machine.config" as a
"DbProviderFactories" provider.

Thank you for the bug report.