strong name and versions

  • Thread starter Thread starter z f
  • Start date Start date
Z

z f

Hi,

I have a dot-net product that is composed from several project that have
references to few of the projects.
when i make strong name (in order to use enterprise services), i have to
build all the projects again.
and if the version of the strong named project is changed, i get run-time
error telling me that the "The located assembly's manifest definition with
name 'CoreEng' does not match the assembly reference."

so what's the idea of strong name if the version is important as the strong
name itself?

the strong named reference does not check the binary DLL to be the same as
the DLL that was referenced, i checked this by changing the code, recompile
the DLL, and the reference did not cause any runtime errors.

what is actually the idea behind strong name?

TIA, z.
 
The idea behind this is to avoid dll hell. If you create a new version of an
assembly, then you can specify as well how compatible this is with your
previous version, as well as you can run 2 diff versions of the "same"
assembly. You can change everithing, but the version, if you want to, but
then you are missing the point.

Note: I worte Assembly instead dll, as you can have exe as well, even abc if
you like to.

Regards,

Tiberiu Covaci
 
so what's the idea of strong name if the version is important as the
strong
name itself?
Click to expand...
Suppose you create MyDll_A v1.0
Later you create another MyDll_B that uses MyDll_A v1.0.
Suppose you change functionality in MyDll_A v1.1 but introduce a bug.
Later I create anothe dll MyDll_C that uses MyDll_A v1.1.
Suppose I create now a program that Applic.exe uses both MyDll_B and
MyDll_C , we are in big shit when MyDll_B relies on a feature in MyDll_A
that is buggy in v1.1 but was working correctly in v1.0.

The strong name makes sure that both version sof MyDll_A could be available,
v1.0 for MyDll_B and v1.1 for MyDll_C.
This is done by making subfolders in the Applic folder that are named
MyDll_B and MyDll_C. But in folder MyDll_B you have MyDll_A v1.0 and in
folder MyDll_C you have MyDll_A v1.1.

You see each dll (actually called assembly) can have it's own version of the
dll that it was tested on, and guaranteed to work correctly for that
assembly.

But there is an override, you could tell MyDll_B which expects MyDll_A v1.0
that it must use MyDll_A v1.1 instead. This is done in the
MyDll_B.dll.config file.

What happens is, that when Applic.exe is executed, the .NET assembly loader
will search for MyDll_B.dll in the current directory, if not found search
for folder that happens to have the same names: MyDll_B and look in that
folder for the MyDll_B.dll. And I guess if not found there then look into
the GAC??? Again, Applic.exe.config can contain override directions.

I hope this makes sense?
 
Ah yes, and another thing, by putting the version in the strong name, you
can tell the .NET framework to thrust Applic.exe v1.0 but maybe not Applic
v1.1 to access the Internet. It is a security thing for administrators od
the computer the software runs on.
 
z said:
so what's the idea of strong name if the version is important as the
strong name itself?
Click to expand...

..NET versioning does not work unless your assembly has a strong name.
The reason is that the public key that is used to sign the assembly
gives it a unique name, and only when an assembly has a unique name can
the runtime be assured that the assembly that is being checked for
version is the one requested.
what is actually the idea behind strong name?
Click to expand...

Read through my Fusion tutorial, it will answer all of your questions.

Richard
 
Back
Top