Determine is .NET MySQL Drivers Installed

[stanl]

I am writing a script that will query a MYSQL table, but I'm throwing in a little Powershell code via the CLR in order to get a Window's Grid output.  I want to use the .NET drivers "MySQL.Data".  The compiled exe will be used by up to 240 persons, so I first want to check if the drivers are installed.

RegKeyExist()  doesn't quite do it. Not sure of a quick way to search the GAC.

Open to suggestions.

[JTaylor]

Hmmmmmm...not sure I can help on the GAC front.  I know you trap and process errors.  Is the error when they aren't installed clear enough it can be used?

Jim

[JTaylor]

Haven't tried it but will the Tech Database article found by searching for:

"Get Assembly Properties dotnet"

help?   Not sure what happens if you try to pull properties using this code for an assembly that doesn't exist but thought that might be something to try.

Jim

[stanl]

Jim;

I don't really want to go through that many bells and whistles. What is frustrating is that it is in my registry in REGCLAASES under Global as

Code (WINBATCH) Select Expand

rData='MySql.Data,version="6.8.3.0",culture="neutral",publicKeyToken="C5687FC88969C44D",processorArchitecture="MSIL"'


But when I search it with RegKeyExist, it returns not found. Using the registry is also unstable as the version changes frequently.

It would be nice if RegKeyExist accepted stuff like "~MySQL.Data"

[EDIT] It does not appear in the GAC. The larger issue is that if WB spawns into PS code via the CLR and there is any failure then the WB exe process stays in the task manager (I hide the WB window).

[....IFICantBYTE]

What about distributing a local copy of the MySQL.Data.dll with your script (compiled exe) and have it referenced explicitly by your Powershell or WinBatch code instead of using a GAC reference that may or may not be installed on that PC?
That way you know it is there and what version it is.
In powershell it seems to be something like: [void][system.reflection.Assembly]::LoadFrom("C:\YourPath\MySQL.Data.dll")

I don't know much about PS, but it seems like it works fine this way.

[stanl]

What about distributing a local copy of the MySQL.Data.dll with your script

Not sure just copying the file and referencing it is the ticket. Assembly has to be registered (key and version info in C:\windows\assembly).

Reflection offers LoadWithPartialFileName, so just MySQL.Data would suffice.  I am looking at a remote situation where users will attach or vpn to a network folder where the exe is located. Detecting the assembly is more a CYA as if the script fails, then all I have to do is contact remote IT and ask if the .NET drivers were installed.

The exe is actually quite dull. It recognizes the user by their login and allows them to pull up their entered sales for a given day. The script uses PS to output as a Windows Grid - looks good, in keeping with other Windows apps -

[td]

Assuming you mean 'LoadWithPartialName', it is tagged as obsolete by MSFT. They recommend using the 'Load' static member instead. Although several overloads of 'Load' are considered obsolete too.

[stanl]

Assuming you mean 'LoadWithPartialName', it is tagged as obsolete by MSFT. They recommend using the 'Load' static member instead. Although several overloads of 'Load' are considered obsolete too.

I guess someone is going to have to tell MSFT that this isn't North Korea. From what I read the Powershell Community (and code) disagrees.

[td]

It matters not a jot or tittle to me but read it for yourself:

https://msdn.microsoft.com/en-us/library/12xc5368%28v=vs.110%29.aspx

Obsolete methods work great until they don't.

[stanl]

It matters not a jot or tittle to me

Understood - but you realize posts on a support board like this can fairly easily be broken down by 2 path: the technical nature of the question and the environment the question arises from.

Consider how many posts here have boiled down to "Which Version of WB are you using?", or relate to moving from XP to Win7. And on the technical side how many posts are answered with code or a udf from yourself, Jim, Snow, IfICantByte et al.

Since I have been with WB, I have been in control of the environment as well as appreciative of technical support. The former is no longer true.

So, I posted a technical question about the existence of a .NET assembly where I have neither knowledge or control on the environment.

'LoadWithPartialName' - (from some test results I received back, from Colorado) seems to work and therefore the original question is a moot point.

If I had control in the end user environment - packaging the .NET MySQL dll, adding it to the GAC would be easy.

I suspect the deprecation of that method will not affect the exe I built until WIN19 is released.

But my real question:

Is not giving a jot or tilttle like not giving a S____ or F___?

[td]

Understood - but you realize posts on a support board like this can fairly easily be broken down by 2 path: the technical nature of the question and the environment the question arises from.

Consider how many posts here have boiled down to "Which Version of WB are you using?", or relate to moving from XP to Win7. And on the technical side how many posts are answered with code or a udf from yourself, Jim, Snow, IfICantByte et al.

Since I have been with WB, I have been in control of the environment as well as appreciative of technical support. The former is no longer true.

So, I posted a technical question about the existence of a .NET assembly where I have neither knowledge or control on the environment.

'LoadWithPartialName' - (from some test results I received back, from Colorado) seems to work and therefore the original question is a moot point.

If I had control in the end user environment - packaging the .NET MySQL dll, adding it to the GAC would be easy.

I suspect the deprecation of that method will not affect the exe I built until WIN19 is released.

There is absolutely no way to predict the reliability of obsolete APIs.  Sometimes they work for 20 years and sometimes they become bulky after the next update of product xyz.   My impression is that MSFT doesn't necessarily intentionally break obsolete APIs.  The APIs just fall victim to changes in some underlying functionality that is shared with fully supported APIs.  The obsolete methods don't disappear they just start to become unreliable. 

When it comes to dotNet the potential demise of an obsolete method will have very little to do with the OS version unless you are restricted exclusively to XP.  The FCL is updated on an almost a monthly basis so  it can happen any time.      MSFT's new rapid development/release cycle and their refactoring of CLR base APIs will make this an even more likely occurrence.

But my real question:

Is not giving a jot or tilttle like not giving a S____ or F___?

A 'jot' is the smallest letter of the Hebrew alphabet and a 'tittle' is a smallest distinguishing marks of an alphabet. The phrase is a literary allusion. 

A better interpretation might be, "I have no horses in the race but as a professional courtesy I brought this to your attention."  Many if not most software shops including WWW make it a policy to avoid using deprecated or obsolete APIs in any new project.  The policy is in place at WWW as part of an effort to produce the highest quality and most reliable product possible. 

[stanl]

Thanks;

My vocabulary has increased. I guess I should have made it clear that I am willing to accept the risk of a deprecated [something] and not point the fingers back at WB.

[td]

Didn't think you were pointing a finger but thought you might be underestimating the risk.  But if you find the risk acceptable, I can't say otherwise either.