Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 334927 - dev-dotnet/mysql-connector-net-6.2.3 doesn't change /etc/mono/2.0/machine.config
Summary: dev-dotnet/mysql-connector-net-6.2.3 doesn't change /etc/mono/2.0/machine.config
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard: Pending Removal: 2012-04-06
Keywords: PMASKED
Depends on:
Blocks: 337491 337751 343259
  Show dependency tree
 
Reported: 2010-08-28 03:57 UTC by Arsen Shnurkov
Modified: 2012-04-06 19:33 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arsen Shnurkov 2010-08-28 03:57:33 UTC
The following string should be addded during install and removed during uninstall:

<configuration>
	<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.2.3.0,Culture=neutral,PublicKeyToken=2f3544035097bf97"/> 
	  </DbProviderFactories>
	</system.data>

</configuration>
Comment 1 Pacho Ramos gentoo-dev 2010-09-07 21:42:24 UTC
Why do you think it should change that file? I have reviewed other distributions and they don't seem to touch it, also none ebuild in the tree looks to do that...
Comment 2 Arsen Shnurkov 2010-09-08 12:33:48 UTC
(In reply to comment #1)
> Why do you think it should change that file? 

Because it is convenient for users.

If I merge connector, I expect, that I will be able to use it.
In windows I don't need to edit machine config to start work with MS SQL.

Why I should do this in Linux with default database?
All other connectors are added to machine.config,
and the set of connectors is already different from windows.
Why not to add MySQL, which is used frequently on linux ?

> other distributions and they don't seem to touch it

gentoo should be the best and most convenient distributive! :)
Comment 3 Pacho Ramos gentoo-dev 2010-09-08 13:40:52 UTC
Alistair, can you please help me on this? I am not sure about how to solve this problem since, looking at other ebuilds, looks like none of them modifies /etc/mono/2.0/machine.config "directly"
Comment 4 Pacho Ramos gentoo-dev 2010-09-08 14:52:33 UTC
Reporter, have you tried to keep machine.config untouched and put that on a file under /usr/lib/mono/2.0? (I got this idea from http://lists.ximian.com/pipermail/mono-devel-list/2008-April/027578.html )
Comment 5 Pacho Ramos gentoo-dev 2010-09-08 14:54:47 UTC
(In reply to comment #4)
> Reporter, have you tried to keep machine.config untouched and put that on a
> file under /usr/lib/mono/2.0? (I got this idea from
> http://lists.ximian.com/pipermail/mono-devel-list/2008-April/027578.html )
> 

It should be called mysql-connector-net.exe.config probably
Comment 6 Alistair Bush (RETIRED) gentoo-dev 2010-09-09 10:08:34 UTC
(In reply to comment #3)
> Alistair, can you please help me on this? I am not sure about how to solve this
> problem since, looking at other ebuilds, looks like none of them modifies
> /etc/mono/2.0/machine.config "directly"
> 

There is one way.

The mysql package currently has an Config "Installer" which doesn't compile for mono,  but we could change that.

If would do that following if we ran it:

1) update machine.config
2) Create an *.installstate file

There is also an uninstall function which would remove the entries in machine.config

Now,  from what I understand we would need to run this in postinst (and have a file created "outside of portage")
and then run the uninstall from prerm and remove that file.


I will investigate this a little and see what I come up with :)


For further reading....
[1] http://msdn.microsoft.com/en-us/library/50614e95(v=VS.80).aspx
[2] http://msdn.microsoft.com/en-us/library/system.configuration.install.installer.aspx
Comment 7 Pacho Ramos gentoo-dev 2010-09-09 13:28:55 UTC
OK, thanks. Maybe other (probably better) option would be to make it work with .exe.config files, that looks to be the way used by other mono apps (like banshee, tomboy...), but I would need reporter to test it when possible :-)
Comment 8 Alistair Bush (RETIRED) gentoo-dev 2010-09-15 08:44:04 UTC
(In reply to comment #7)
> OK, thanks. Maybe other (probably better) option would be to make it work with
> .exe.config files, that looks to be the way used by other mono apps (like
> banshee, tomboy...), but I would need reporter to test it when possible :-)
> 

Do we know what .net packages use (can use) mysql currently?
Comment 9 Pacho Ramos gentoo-dev 2010-09-15 11:23:20 UTC
(In reply to comment #8)
> Do we know what .net packages use (can use) mysql currently?
> 

Me not :-(
Comment 10 Pacho Ramos gentoo-dev 2010-09-15 17:03:25 UTC
Arsen, I have seen that you have opened a bug requesting inclusion of an app requiring this. 

Great :-), but, have you tried what I suggested in comment #4 and #5 ? Would be nice to know how to generate a exe.config file instead of editing machine.config directly

Thanks a lot
Comment 11 Arsen Shnurkov 2010-09-16 11:01:41 UTC
> have you tried what I suggested in comment #4 and #5 ?

No, I don't because according to my knowledge that will not work.
#4 because the standart way of sharing dll is registring in the GAC
#5 because mysql-connector is a library, not the application.

> Would be nice to know how to generate a exe.config file 
> instead of editing machine.config directly

This is possible, but should be done for each and every application.

I think that it is mach easy to modify in one place.
Comment 12 Pacho Ramos gentoo-dev 2010-09-16 21:18:02 UTC
(In reply to comment #11)
> > have you tried what I suggested in comment #4 and #5 ?
> 
> No, I don't because according to my knowledge that will not work.
> #4 because the standart way of sharing dll is registring in the GAC

Reading ebuild looks like it's already registering it:
        # Install dll into the GAC
        ebegin "Installing dlls into the GAC"
        gacutil -i MySql.Data/Provider/bin/Release/MySql.Data.dll -root "${D}/usr/$(get_libdir)" \
                -gacdir /usr/$(get_libdir) -package ${PN} > /dev/null
        gacutil -i MySql.Web/Providers/bin/Release/MySql.Web.dll -root "${D}/usr/$(get_libdir)" \
                -gacdir /usr/$(get_libdir) -package ${PN} > /dev/null
        eend

Or is any dll missing?

> #5 because mysql-connector is a library, not the application.
>

OK :-)
 
> > Would be nice to know how to generate a exe.config file 
> > instead of editing machine.config directly
> 
> This is possible, but should be done for each and every application.
> 
> I think that it is mach easy to modify in one place.
> 

The problem is that the staff you want us to add to machine.config is not "static" between versions, at least Version and probably PublicKeyToken will change on every version bump, and looks really strange to me that this is the only package on the tree requiring to manually edit machine.config for installing properly :-/
Comment 13 Arsen Shnurkov 2010-09-17 00:27:12 UTC
>> #4 because the standart way of sharing dll is registring in the GAC

> Reading ebuild looks like it's already registering it:
It is correct.
> Or is any dll missing?
there is only one dll there

but registring in GAC is not enough for using as data provider

> Version and probably PublicKeyToken will change on every version bump

So, the idea is to write the generic ebuild which will remain unchanged between versions. Then there should be the code, which extracts the PublicKeyToken from the dll and put it into machine config during install.

> and looks really strange to me that this is the only package on the tree requiring to manually edit machine.config for installing properly :-/

There are not so many packages for mono yet. If you wish another one - look at postgres ( http://npgsql.projects.postgresql.org/ )
Comment 14 Alistair Bush (RETIRED) gentoo-dev 2010-09-17 07:45:56 UTC
> 
> but registring in GAC is not enough for using as data provider
> 

Currently lets agree that editing a web/app .config file is enough to get the data provider working.

> > Version and probably PublicKeyToken will change on every version bump
> 
> So, the idea is to write the generic ebuild which will remain unchanged between
> versions. Then there should be the code, which extracts the PublicKeyToken from
> the dll and put it into machine config during install.

Not possible.  I would have thought that the assembly version should always match upstream.  We can't start forcing packages to all have 1.0.0.0  we should be slotting for different assembly versions instead.

> 
> > and looks really strange to me that this is the only package on the tree requiring to manually edit machine.config for installing properly :-/
> 
> There are not so many packages for mono yet. If you wish another one - look at
> postgres ( http://npgsql.projects.postgresql.org/ )
> 


This is something of interest to note...

Beginning in the .NET Framework version 4, data providers such as System.Data.Odbc, System.Data.OleDb, System.Data.SqlClient, and System.Data.OracleClient are no longer listed in machine.config file, but custom providers will continue to be listed there.
Comment 15 Arsen Shnurkov 2010-09-17 08:01:09 UTC
>>> Version and probably PublicKeyToken will change on every version bump
>>> So, the idea is to write the generic ebuild which will remain unchanged between
>>> versions. Then there should be the code, which extracts the PublicKeyToken from
>>> the dll and put it into machine config during install.

> Not possible.  I would have thought that the assembly version should always
> match upstream.  We can't start forcing packages to all have 1.0.0.0  we should
> be slotting for different assembly versions instead.

Why not possible? There is no need to force all packages to have 1.0.0.0 version. One can add several lines to machine.config, one line per one slot (where one slot equals to one version). So, we can use slotting for different assembly versions (see side-by-side deployment feature of .net)
 
> This is something of interest to note...
> Beginning in the .NET Framework version 4,
> data providers such are no longer listed in machine.config file

Can you provide a link to explaination of the reasons of this change?
Comment 16 Arsen Shnurkov 2010-09-18 03:51:44 UTC
> Beginning in the .NET Framework version 4, data providers such as
> System.Data.Odbc, System.Data.OleDb, System.Data.SqlClient, and
> System.Data.OracleClient are no longer listed in machine.config file, but
> custom providers will continue to be listed there.

http://msdn.microsoft.com/en-us/library/dd0w4a2z.aspx

http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataproviders/thread/d79129c4-ae05-4c45-8997-bd90f5765a3a

(q) "DbProviderFactories.GetFactoryClasses() will determine the framework providers dynamically at runtime."

So I don't understand, how it should work:
- In the App.config there is a connection string, which is refers to Provider's Invariant Name.
- There is magically build list with providers
- How it selects the correct version of assembly?
Comment 17 Pacho Ramos gentoo-dev 2010-10-07 19:51:18 UTC
Is this a 6.2.3 version regression or are all versions in the tree affected?
Comment 18 Arsen Shnurkov 2010-10-08 06:03:16 UTC
> Is this a 6.2.3 version regression or are all versions in the tree affected?

In some sense it is not a bug - it is nonimplemented functionality.
All versions of ebuild in tree doesn't modify the machine.config file
Comment 19 Arsen Shnurkov 2010-11-14 04:54:02 UTC
> I would have thought that the assembly version should always
match upstream.

I have the following idea:
1) we need to create a separate utility program , which looks at provider assembly and extracts assembly version, then modifies machine.config  (or should it be included in gacutil?)
2) separate utility  should have separate ebuild (modification of gacutil requires coordination with mono team)
3) mysql-connector-net ebuild should depend from that ebuild for compile time, but not for run time (in order to reduce total setup size)
4) there should be eclass, which wraps two calls to that utility (to register and to unregister)
5) eclass should be used from any ebuild for data provider (mysql, postgres and other ~20 databases)
Comment 20 Arsen Shnurkov 2010-11-21 13:05:45 UTC
https://bugzilla.novell.com/show_bug.cgi?id=655154
Comment 21 Pacho Ramos gentoo-dev 2011-02-01 17:47:43 UTC
Until this is implemented by upstream (or somebody wants to develop and eselect module for this), the way to go would be to provide an app.exe.config file providing that information... the problem is how to do that. Alistair, do you have any idea about how to do it? I have tried to search how other distributions are packaging mysql-connector-net but they are simply neither registering it :-(

Maybe creating a file in /usr/lib64/mono/mysql-connector-net named "MySql.Data.dll.config" and with the following contents could help:


<configuration>
        <system.data>
          <DbProviderFactories>

    <add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient"
description=".Net Framework Data Provider for MySQL"
type="MySql.Data.MySqlClient.MySqlClientFactory"/> 
          </DbProviderFactories>
        </system.data>

</configuration>
Comment 22 Arsen Shnurkov 2011-07-31 10:21:34 UTC
(In reply to comment #21)
> do you have any idea about how to do it?

I have a new idea :)

1) Vesion of assembly is known from ebuild, Publik Key Token can be extracted from assembly with "sn" utility:

# sn -Tp /usr/lib64/mono/gac/Npgsql/4.0.0.0__5d8b90d52f46fda7/Npgsql.dll

Mono StrongName - version 2.10.2.0
StrongName utility for signing assemblies
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD license
d.

Public Key:
00240000048000009400000006020000002400005253413100040000010001002b3c590b2a4e3d
347e6878dc0ff4d21eb056a50420250c6617044330701d35c98078a5df97a62d83c9a2db2d0725
23a8fc491398254c6b89329b8c1dcef43a1e7aa16153bcea2ae9a471145624826f60d7c8e71cd0
25b554a0177bd935a7809629f0a7afc778ebb4ad033e1bf512c1a9c6ceea26b077bc46cac93800
435e77ee

Public Key Token: 5d8b90d52f46fda7

2) There is dev-libs/libxslt package, it contains xsltproc command line tool for applying XSLT stylesheets to XML documents.


3) So, It is possible to dynamically create xslt from ebuild (add constants) and then apply it to machine.config.

4) ...

5) Profit

I can't do point 4 yet, because I don't know XSLT
Comment 23 damage 2011-10-27 14:44:41 UTC
Hi,
just a note: The DbProviderFactories config which is needed to use mysql in mono may differ from the DbProviderFactories which is needed by .NET Windows. Thus we need a machine specific configuration?!

LOOOOOOOONG time ago I was using XSLT. What should the XSLT exactly do? I think it should "just" add/change (for version 6.2.3):

> <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.2.3.0, Culture=neutral, PublicKeyToken=2f3544035097bf97" />

To the config section system.data in /etc/mono/2.0/machine.config and /etc/mono/4.0/machine.config .

Am I right?

cheers
Daniel
Comment 24 Pacho Ramos gentoo-dev 2012-02-28 12:30:51 UTC
Our package is too old, not used by anything in the tree and nobody is willing to maintain neither update it -> I think we should just treeclean it if nobody wants to even proxy-maintain it
Comment 25 Pacho Ramos gentoo-dev 2012-04-06 19:33:43 UTC
dropped