Dotnetfx does an incomplete install?

sobriquet

I think I'm missing something here, but I've installed the .Net redistributable 1.1 (dotnetfx.exe) on a test machine (Win98), and I can run plenty of (trivial) test programs, but I can't run my test ADO code.

Looking into C:\windows\assembly\ tells me that there is no ADODB assembly installed in the Global Cache, whereas it is on my dev box (where VS.Net is installed). Now, for obvious reasons, this is pretty useless to me, but I can't see what I've done wrong. Is it that I need to package the code to install the relevant assemblies? I'm stumped.

Any help appreciated.

Chris.

Kernel32

Are you using the oledb data provider or the sqlclient? If its oledb data provider then verify you have the lasted version of MDAC installed, or simply download and install the latest version for Windows 98.

sobriquet

I have MDAC 2.7 installed. I'm using vanilla ADO code through a Reference to the ADODB assembly. Works fine on the Dev machine.

Kernel32

Well my first question is why use ADODB in the first place, you are simply adding more layers than you need, use System.Data.OleDb namespace instead.

Secondly if you are using a reference to ADODB you most likely created a Runtime Callable Wrapper around the ADODB COM Library, this happens fairly transperently when you reference a COM object. If this is the case then you need to copy that assembly with the one you created.

Thirdly, why are you using ADODB anyway??

-A

Spunj

I had this problem myself, you have to copy adodb.dll (i think thats its name) to the target folder on the machine with only the redistributable on it. Seems like DotnetFx doesnt include ADO.NET dlls.

sobriquet

I copied over the ADODB.dll into the Global Assembly Cache on the test box, but to no avail. Seems unlikely, but do they need to registered or something?

why use ADODB in the first place

Because the VB6 code I've worked on uses ADO. So going to ADO.Net seems to make sense, to me anyway.

Secondly[...]

Unless Visual Studio does that, because I didn't knowingly (bear in mind I don't know .Net very well yet).

why are you using ADODB anyway??

That's the first question.

Evil Phil

Originally posted by Kernel32
Secondly if you are using a reference to ADODB you most likely created a Runtime Callable Wrapper around the ADODB COM Library, this happens fairly transperently when you reference a COM object. If this is the case then you need to copy that assembly with the one you created.

I think he's refering to ADO.Net.

... but do they need to registered or something?

Could you use GACUTIL.EXE that come with the .NET SDK to add the ado.net assemblies to the GAC after you've copied them over?

I don't know if that will work but keep us posted as it looks like I'm about to run into the same problem.

<additional/>
There are service packs available for MDAC 2.7 here.

Kernel32

Ok, there seems to be some confusion here, and I may look like an idiot (not the first time) but here is my 2 cents on this, but I could be wrong.

If you are using the ADODB.dll then you are not using ADO.NET, you are using the runtime callable wrapper to ADO. On my dev machine it is located in C:\Program Files\Microsoft.NET\Primary Interop Assemblies\adodb.dll

Notice the word Interop, Interop is the name of the layer used to bridge the gap between .Net assemblies and COM. The ADO.Net libraries are contained in the System.Data assembly, in my case that is in C:\WINNT\Microsoft.NET\Framework\v1.0.3705\System.Data.dll . The System.Data assembly has the Oledb classes which uses oledb providers to connect to databases and requires MDAC, it also contains the sqlclient classes which talk with sql server natively and bypass oledb and are much faster than oledb, there is also an Oracle one available from MS and Oracle, and if I am correct they don't require MDAC. All of the classees and namespaces under System.Data fall into ADO.NET umbrella as they are use a similar structure, plus they all return and manipulate data using Datasets, Datatables, Dataviews, DataAdapters, DataCommands etc.

I am fairly sure the System.Data assembly is installed with the redist and shouldn't require anything else.

sobriquet

Yeah, now we're on the same wavelength. Apologies for any misleading info, btw. I've been thrown in the deep end with this .Net stuff, so you'll have to excuse my ignorance.

I've done some tests with both ADO.Net and the older ADO via the DLL, and the older ADO screams past the .Net method on test times, doing the same thing - though I haven't tried using the SQL Server specific method (SqlConnection etc), and I'm not using 'optimized' queries or anything.

On my dev box, there's a copy of ADODB.dll in the GAC, and I tried using GACUTIL to install it on the test box. It installed, but no joy. I'll try putting it in the Interop Assemblies.

Spunj

Have a look at this :
Using the Primary Interop Assembly for ADO (ADODB) in Visual Studio .NET

sobriquet

It makes me feel dumb, but I appreciate the link.

Slightly related - is it just me, or is microsoft.com search feature just utter crap?

Evil Phil

Dunno about microsoft but I've actually learned quite a bit from this thread, now that I'm not getting my ado's crossed anymore

Kernel32

sobriquet

personally I love MSDN, it has fantastic technical doc's

Also fire up the help file that come withs Visual Studio .Net, it has everything you need for .Net development.