The dependency .... could not be found. DLL Hell in .NET?

[rm]

What is the difference between now and the VB 6.0 days? I have a
project with several dependencies. When I attempt to execute the
application from the IDE several error messages are displayed related
to "missing" dependencies. The files that "cannot be found" do in fact
exist in the exact location recorded in the IDE. What am I missing?

[David Browne]

"rm" <gr****@rlmoore.net> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

What is the difference between now and the VB 6.0 days? I have a
project with several dependencies. When I attempt to execute the
application from the IDE several error messages are displayed related
to "missing" dependencies. The files that "cannot be found" do in fact
exist in the exact location recorded in the IDE. What am I missing?

A .NET assembly is loaded not just by name, but by the combination of name
and version.

In your class libraries do you have AssemblyVersion set to automatically
increment? If so, don't. You should never auto increment AssemblyVersion,
and it's a Visual Studio bug that it does this by default.

Also you should use project referneces to the required libraries. This will
help Visual Studio coordinate builds among the dependant projects.

David

[Mythran]

In your class libraries do you have AssemblyVersion set to automatically
increment? If so, don't. You should never auto increment
AssemblyVersion, and it's a Visual Studio bug that it does this by
default.

Never auto-increment AssemblyVersion? Where'd you get that idea? We
auto-increment the Assembly version because when you do any kind of build,
the actual binary file is re-written...even if it is exactly the same binary
data that gets written. It isn't "copying" the old binary data, it's
re-building the data. Because of this, it really is a new build/revision.
Therefore, incrementing the build and revision numbers automatically makes
sense. Why would you NOT auto-increment for most projects?

Using project references is only applicable when you are developing the
dependencies yourself. If you have a control you wrote and you want to
include it in different projects that are in different solutions, would you
re-build the control every time you want to place it on one of your forms?
If you wrote many controls, the solution would become much larger than it
would need to be, not only that, for every project that uses the control,
you would have a different build (not build #, but binary build) of the
control. Even if you kept the build/revision numbers the same in all of the
binaries, the date created would change, and it would be a different binary.

Now, for the original poster, try removing the references from the project
and re-adding them in the IDE (if you are developing in a .Net IDE). If
that doesn't work, let us know :)

Mythran

[david]

On 2005-09-23, Mythran <ki********@hotmail.comREMOVETRAIL> wrote:

In your class libraries do you have AssemblyVersion set to automatically
increment? If so, don't. You should never auto increment
AssemblyVersion, and it's a Visual Studio bug that it does this by
default.
Never auto-increment AssemblyVersion? Where'd you get that idea? We
auto-increment the Assembly version because when you do any kind of
build, the actual binary file is re-written...even if it is exactly
the same binary data that gets written. It isn't "copying" the old
binary data, it's re-building the data. Because of this, it really is
a new build/revision. Therefore, incrementing the build and revision
numbers automatically makes sense. Why would you NOT auto-increment
for most projects?

Because if the version number of a component changes, you also need to
rebuild all projects that use that component (or do a redirect in
the .config file).

Mind you, I'm not agreeing with the idea of *never* autoincrementing,
but it's often a useful practice to turn it off, especially for
class libraries.
Using project references is only applicable when you are developing
the dependencies yourself. If you have a control you wrote and you
want to include it in different projects that are in different
solutions, would you re-build the control every time you want to place
it on one of your forms?
Good example. Now you've used this control in x number of websites, and
you want to fix a typo in an error message. Do you change the version
number and rebuild the world, or keep the version number and just drop
in the new component into the various bin directories on the release
servers?

If you wrote many controls, the solution
would become much larger than it would need to be, not only that, for
every project that uses the control, you would have a different build
(not build #, but binary build) of the control. Even if you kept the
build/revision numbers the same in all of the binaries, the date
created would change, and it would be a different binary.
This actually isn't such a bad idea in certain situations if you have a
source control system that handles linking projects correctly and a good
automated build system. Eventually, though, I agree you'd want to
lock down the components.

To be honest, I think the whole VS.Net versioning system is incredibly
poorly thought out. What I really want is a way to identify different
builds without breaking compatibility; File version could be useful for
this, but VS won't autoincrement it. Also, true autoincrementing would
be nice, not the weird format VS.Net uses. If they must use a date, why
not a simple epoch time in the revision part? And it should be updated
on every build. I just don't understand the point of an autoincrement
system that doesn't update on every build, that makes no sense to me.

I often think that it would be nice if the CLR would ignore the revision
part when checking for compatibility, but that might be a performance
problem if you get a lot of builds in the cache.


Now, for the original poster, try removing the references from the
project and re-adding them in the IDE (if you are developing in a .Net
IDE). If that doesn't work, let us know :)

I'd add that deleting the obj and bin directories often helps as well.

[Mythran]

"david" <da***@woofix.local.dom> wrote in message
news:sl******************@localhost.localdomain...

On 2005-09-23, Mythran <ki********@hotmail.comREMOVETRAIL> wrote:

In your class libraries do you have AssemblyVersion set to automatically
increment? If so, don't. You should never auto increment
AssemblyVersion, and it's a Visual Studio bug that it does this by
default.
Never auto-increment AssemblyVersion? Where'd you get that idea? We
auto-increment the Assembly version because when you do any kind of
build, the actual binary file is re-written...even if it is exactly
the same binary data that gets written. It isn't "copying" the old
binary data, it's re-building the data. Because of this, it really is
a new build/revision. Therefore, incrementing the build and revision
numbers automatically makes sense. Why would you NOT auto-increment
for most projects?

Because if the version number of a component changes, you also need to
rebuild all projects that use that component (or do a redirect in
the .config file).

Not always. If you (not saying you should) put the assembly into the GAC,
you would not have to rebuild. Just use a policy file (which I have never
done).
Mind you, I'm not agreeing with the idea of *never* autoincrementing,
but it's often a useful practice to turn it off, especially for
class libraries.

Using project references is only applicable when you are developing
the dependencies yourself. If you have a control you wrote and you
want to include it in different projects that are in different
solutions, would you re-build the control every time you want to place
it on one of your forms?

Good example. Now you've used this control in x number of websites, and
you want to fix a typo in an error message. Do you change the version
number and rebuild the world, or keep the version number and just drop
in the new component into the various bin directories on the release
servers?

Oh, come on. You don't write perfect code the first time ??? :P

If you wrote many controls, the solution
would become much larger than it would need to be, not only that, for
every project that uses the control, you would have a different build
(not build #, but binary build) of the control. Even if you kept the
build/revision numbers the same in all of the binaries, the date
created would change, and it would be a different binary.

This actually isn't such a bad idea in certain situations if you have a
source control system that handles linking projects correctly and a good
automated build system. Eventually, though, I agree you'd want to
lock down the components.

Now, for the original poster, try removing the references from the
project and re-adding them in the IDE (if you are developing in a .Net
IDE). If that doesn't work, let us know :)

I'd add that deleting the obj and bin directories often helps as well.

Yeah, but if that helps, then you'd probably want to find why deleting the
obj and bin directory helps, and see if there is another reason/problem that
exists...

Mythran