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.

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.

Logged

Regards,....IFICantBYTE

Nothing sucks more than that moment during an argument when you realize you're wrong.

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 -

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.

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.

Quote

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.

Logged

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight." - Dr. Tom Cade