compiled dll reuse version issue

  • Thread starter Thread starter mmartin
  • Start date Start date
M

mmartin

I'm using Visual Studio 2002:
Development Environment version: 7.0.9466
..NET Framework version: 1.0.3705
(versions are kind of important usually... and yeah, yeah "upgrade" --
sheesh -- I've still got c++ v4 floating around for support issues...
<grin>)

I downloaded a data access DLL for MySQL that implements the Connector,
Adapter, etc... classes. It was done in C# from VS 2003 version (source
files included) -- MySQLDriverCS is it's name.

Well, when I started to create a VB app to use the DLL, I got "type cast"
errors with actions like MyAdapter.fill(DataSet) functions -- anything that
tried to manipulate/use data.

With the source available (though the project files are unusable to me), I
simply created a blank C# app, pulled in the source code files, grabbed the
settings from the source project files (via notepad) and compiled the DLL to
my version -- well, this works.

The part that gets to me is, whereas the development versions are different,
the .NET framework versions match but, once I did the recompile, I can now
use the DLL without any problems...

This gives me flash backs of 10+ years ago as far as programming goes.
Hell, I can write a DLL in my current c++ and use that DLL from older
compilers without any real problems as long as it isn't using any managed
code type stuff...

Just wondering if this is what I'll be looking at for any "managed code"
libs that are built. Will they at least be useable "forward" style? (I
haven't tried yet but I will when I get 2003 version -- if so, perhaps I'm
better off sticking with the oldest version available for building
libs...)

Thanks in advance for any info.
 
It sounds much more like a .NET framework issue than a compiler issue. Keep
in mind that in C and C++ your stdlibs didn't really have versions.
Implementations of the stdlibs fixed bugs, but didn't add features or change
parameter types. They were standards. The .NET framework class library, on
the other hand, goes through a lot of changes. If you didn't get any
problems loading the assembly into your domain or compiling its functions,
I'd say that the problem was likely due to the framework class library
changes, and that, unfortunately, is something we'll probably be seeing far
into the future.

Chris
 
Back
Top