How can I use a dll with several programs?

[HKSHK]

Hello,

I have this problem:
I wrote some DLLs with VB.Net 2003 which I use with my programs. But I
want to avoid that I have to go down to "DLL hell" and to copy all used
dlls into each program directory.

Does anyone have an idea how I can avoid that?

Thanks in advance!

Best Regards,

HKSHK

 

[Scott M.]

Prepare your assembly with a strong name and register it into the Global
Assembly Cache (GAC). Then you can have several applications use it but
only maintain one copy that is in a central location.

 

[Michel Posseth [MCP]]

Pleas investigate the true meanings of the term Dll hell , people who
programmed and deployed Vb6 , Delphi etc etc applications on win32 will
know what i mean

..Net is the solution for the Dll hell

In the past when programmers dumped there dll`s in system32 we had lots of
problems with versioning of dll`s ( we needed to write intelligent setup`s
and even then it sometimes broke another or your own app )
With .Net we can just put the required dll`s in the assembly directory ( or
if you prefer and add a config entry in a sub directory below the assembly
dir )
however we talk about Xcopy deployment if you call that Dll hell well then
praise the lord you started ( probably ) with .Net

http://en.wikipedia.org/wiki/DLL_hell

The solution for your problem ?? ,,, is in my opinion to create a setup
project for your proggy

In my opinion the GAC is only to be used with BL objects in corporate
environments , in all other situations it is a ticking time bomb ( stay
away of it as it were the plague )


regards

Michel Posseth [MCP]

 

[Scott M.]

In my opinion the GAC is only to be used with BL objects in corporate

environments , in all other situations it is a ticking time bomb ( stay
away of it as it were the plague )

LOL - I think you just need to do some investigating about the GAC. It's
not the best solution all the time, but in many situations (like commonly
used assemblies), it may be just the ticket to simpler deployment and
version control.

 

[HKSHK]

Dear Scott,

Thanks a lot! That's exactly what I was looking for.

Best Regards,

HKSHK

 

[HKSHK]

Dear Mr. Posseth, > Pleas investigate the true meanings of the term Dll
hell , people who

programmed and deployed Vb6 , Delphi etc etc applications on win32 will
know what i mean

I wrote software in VB6...

In the past when programmers dumped there dll`s in system32 we had lots of
problems with versioning of dll`s ( we needed to write intelligent setup`s
and even then it sometimes broke another or your own app )
With .Net we can just put the required dll`s in the assembly directory ( or
if you prefer and add a config entry in a sub directory below the assembly
dir )

To me "DLL hell" means that I have several versions of DLLs in various
directories. One thing is that it consumes unnecessary disk space, the
other thing is that it is more difficult to support your software.

Having one copy of a DLL in system32 is better than having 20 spread all
over your hard drive. By definition, a higher version number has to be
backward compatible. If you keep that in mind when updating your DLL,
there is no "DLL hell".

however we talk about Xcopy deployment if you call that Dll hell well then
praise the lord you started ( probably ) with .Net

http://en.wikipedia.org/wiki/DLL_hell

Wikipedia says: "These difficulties include ... and having many
unnecessary DLL copies." (same what I say)

The solution for your problem ?? ,,, is in my opinion to create a setup
project for your proggy

That's what I always do.

In my opinion the GAC is only to be used with BL objects in corporate
environments , in all other situations it is a ticking time bomb ( stay
away of it as it were the plague )

Why do you think it's a ticking time bomb?

Best Regards,

HKSHK

 

[Cor Ligthert [MVP]]

HKSHK,

If there was no DLL hell, a term that comes AFAIK from the VB classic area,
than the term would not exist. In my idea it can as well not be seen without
thinking too about the different classic VB runtimes.

Just my thought,

Cor

 

[Michel Posseth [MCP]]

LOL - I think you just need to do some investigating about the GAC. It's

not the best solution all the time, but in many situations (like commonly
used assemblies), it may be just the ticket to simpler deployment and
version control.

The .NET Global Assembly Cache (GAC) is a misunderstood and misused beast.
For all intents and purposes, it provides what COM and windows\system32 do,
i.e. a machine-wide place to drop shared DLLs. Of course, the problems with
sharing DLLs in a machine-wide spot is that it leads to a set of well-known
problems collectively called "DLL Hell." There are many problems, but the
biggest is that when a shared DLL is updated, you're really updating an
unknown set of applications. If the set of applications is unknown, how can
you possible test them before making this change? And if you can't test
them, you're likely to break them. What this boils down to is that any of
the shared spots for updates, whether it's a COM CLSID, windows\system32 or
the GAC, are dangerous and should be avoided. And this is why the preferred
..NET deployment scenario is "xcopy deployment," i.e. having your own private
copy of each DLL that you test and deploy with the rest of your application.

Aha!" you say. "The GAC supports multiple version of an assembly! When a
foo.dll is updated to v1.1, v1.0 sits right along side of it so that your
app *doesn't* break!" Of course, that's absolutely true. But if that's the
case, why do you care? I mean, if there's a new assembly available but your
app isn't picking it up, what difference does it make?
"Aha again!, you say. "I can put a publisher policy into the GAC along with
my assembly so that apps *are* updated automatically!" That's true, too, but
now, like any of the machine-wide code replacement strategies of old, you're
on the hook for an awesome responsibility: making sure that as close to 0%
of apps, known to you or not, don't break. This is an awesome responsibility
and one that takes MS hundreds of man-years at each new release of the .NET
Framework


So using the GAC is bringing back the Dll hell that is my statement ( also
in my previous post ) i do not see anything funny about it i am bloody
serious about it
as i said there are situations were the GAC might be a good solution ,
however in these scenario`s you have a big responsability that is why i
said use it only in a managed environment ( that`s just my opinion ) .


regards

Michel Posseth [MCP]

 

[Michel Posseth [MCP]]

Hello mr hkshk , ( ?? )

To me "DLL hell" means that I have several versions of DLLs in various
directories. One thing is that it consumes unnecessary disk space, the
other thing is that it is more difficult to support your software.

No :

The dll hell has everything to do with versioning of dll`s stored in one
location ( system32 / GAC )

In the past i have seen much of my colegues send across europe to repair
broken programs because there setup overwrote specific dll`s that were
shared among other programs as a vb6 programmer you probaly are aware of
the famous bootstrap error that could lead to endless restarting of the
target computer because "some system files were out of date" ?

XCOPY deployment takes care of the DLL hell because it ensures that all
dependecies have been tested against the target assembly , this is even true
when creating a update package that selectively only updates certain dll`s
, cause you have tested the app with these dll`s

One thing is that it consumes unnecessary disk space

Yes : that is true however with current computers this is not a problem
( those few kb`s of overhead or let`s do though with 20 progs 10 MB ??? what
is the reliability of your program worth in harddisk space )

other thing is that it is more difficult to support your software.

No : it isn`t it makes things much harder , in your scenario you should
have to test all previously deployed apps that use the same set of dll`s
even better if you create an assembly that is used by third party`s , they
should recheck there app to for bugs or unexpected behavior .

Having one copy of a DLL in system32 is better than having 20 spread all
over your hard drive.

Well i and MS ( as they anounced that .Net is the solution for the above )
do not share this opinion

By definition, a higher version number has to be backward compatible. If
you keep that in mind when updating your DLL, there is no "DLL hell".

True however we are only humans , and as good as we are we make mistakes ,
breaking something somewhere at some point could lead to a dissaster
( murphy`s law ,, anything that can go wrong will go wrong at some point,
this is the ticking time bomb )

Wikipedia says: "These difficulties include ... and having many
unnecessary DLL copies." (same what I say)

I fully comply with that however i do not see this as a true problem as i
said before how much harddisk space is the ensured stability of your program
worth ?
( in most of the scenario`s probaly a few hundred kb`s , but if it were mb`s
i wouldn`t even care )

Also another thing to consider is the following :

The GAC does facilitate side-by-side storage of DLLs based on the assembly's
strong identity (something that did not exist with system32),
so what does this mean ?

Lets say you have 10 applications that use the same foo.dll you do ten
seperate upgrades for foo.dll when you release one of your projects
well you now end up with ten versions of foo.dll in your GAC ? so were is
your disk space saving now ??
even better now i deinstall one of the proggy`s in my scenario this is no
problem cause i know what the deps are ,,, you might now have a problem
as you can`t remove foo.dll unless you documented the exact usage and never
missed one, so most safe is to leave the dll in the GAC so in the end you
leave rubish on the computer while the XCOPY deployed app dissapears without
a trace

That's what I always do.

Well then i don`t see your problem at all

However :

Google on "when to use GAC" and see what other developers say about this
subject , you will see that lots of them will tell you that GAC =
reintroducing Dll hell
there was even a rumour that the GAC will eventually dissapear because of
this in future versions of the framework .

If you are a corporate developer , and fit the "use the GAC scenario" or jou
just think you are on the right track well then use the GAC my statements
above and my previous posts are reflecting my opinion regarding this mather
based on my knowledge and experience i know that in my situation deploying
apps to thousands of users throughout Europe using the GAC is not a good
idea .

ps.

I always thought that a fellow VB6 developer would love the Xcopy capability
of VB.Net , as a VB6 developer i have written lots of complex setup`s and
because of this fact i inmediatly loved the .Net ease of deployment .


kind regards

Michel Posseth [MCP]

 

[Michel Posseth [MCP]]

Another solution would be to install all the applications to one
subdirectory that holds all dependecies

mark all the deps in your setup as shared the MSI will then create a usage
count and will not remove the dll`s unless the last application was
deinstalled


regards

Michel Posseth [MCP]

 

[Herfried K. Wagner [MVP]]

No :

The dll hell has everything to do with versioning of dll`s stored in one
location ( system32 / GAC )

I don't think the DLL applies to the GAC or the Win32 Side-by-Side cache
because both support assembly versioning to prevent the versioning issues
typically referred to as DLL Hell. Note that assemblies installed into the
GAC must have a strong name which makes sure that no other vendor can
publish a fix of an assembly.

In the past i have seen much of my colegues send across europe to repair
broken programs because there setup overwrote specific dll`s that were
shared among other programs as a vb6 programmer you probaly are aware of
the famous bootstrap error that could lead to endless restarting of the
target computer because "some system files were out of date" ?

Yep, that's the problem in Windows versions prior to Windows 2000 (which
came with Windows File Protection). Windows XP/Server 2003 even provide a
mechanism for Win32 assemblies (Side-by-Side cache).

XCOPY deployment takes care of the DLL hell because it ensures that all
dependecies have been tested against the target assembly , this is even
true when creating a update package that selectively only updates certain
dll`s , cause you have tested the app with these dll`s

Updates in contrast to new versions of an assembly don't break the
compatibility. If they do, that's due to a mistake by the developer, which
should not occur. The problem with installing each assembly used by an
application into its application directory is that fixes for the assembly
cannot be rolled out easily because it's not clear which application uses
the DLL. Rememver the JPEG security hole in the GDI+ assembly. Microsoft
had to release a separate tool that searches for this DLL on the system and
patches installed versions.

Well i and MS ( as they anounced that .Net is the solution for the
above ) do not share this opinion

I believe Microsoft does only share the opinion for Win32 assemblies prior
to Windows XP/Server 2003. However, Windows XP/Server 2003 both come with
the Side-by-Side cache ("%WINDIR%\WinSxS") which is an unmanaged counterpart
to the GAC.

Google on "when to use GAC" and see what other developers say about this
subject , you will see that lots of them will tell you that GAC =
reintroducing Dll hell
there was even a rumour that the GAC will eventually dissapear because of
this in future versions of the framework .

I would not consider multiple versions of the same DLL on the system as DLL
Hell. DLL Hell describes versioning problems, not DLL redundancy on a
system.

 

[Michel Posseth [MCP]]

I don't think the DLL applies to the GAC or the Win32 Side-by-Side cache
because both support assembly versioning to prevent the versioning issues
typically referred to as DLL Hell. Note that assemblies installed into
the GAC must have a strong name which makes sure that no other vendor can
publish a fix of an assembly.

When i pressed the submit button and reread the posting i was already afraid
that this was unclear
in my response you will see a few paragraphs below that i am aware of the
versioning mechanism

My aversion against the GAC is due to the fact that you are depending in the
end on a reference count for every version to make sure that it is there and
won`t break apps, my personal opinion is that it introduces unnecesay
deployment complexity ( write an installer that delivers a file to the GAC
to call one, need of administrator interference due to system ACL )
Most people use Gacutil.exe or Xcopy to deploy there assembly to the GAC
while they should use a installer to do so because these do not provide
assembly reference counting .

Yep, that's the problem in Windows versions prior to Windows 2000 (which
came with Windows File Protection). Windows XP/Server 2003 even provide a
mechanism for Win32 assemblies (Side-by-Side cache).


Updates in contrast to new versions of an assembly don't break the
compatibility. If they do, that's due to a mistake by the developer,
which should not occur. The problem with installing each assembly used by
an application into its application directory is that fixes for the
assembly cannot be rolled out easily because it's not clear which
application uses the DLL. Rememver the JPEG security hole in the GDI+
assembly. Microsoft had to release a separate tool that searches for this
DLL on the system and patches installed versions.

Well you are right , however in the company`s i have worked for i wouldn`t
bet my life on the fact that my collegues did not break the compatibility
so i choose to be on the safe side .

But to rephrase this, every advantage has a dissadvantage

I believe Microsoft does only share the opinion for Win32 assemblies prior
to Windows XP/Server 2003. However, Windows XP/Server 2003 both come with
the Side-by-Side cache ("%WINDIR%\WinSxS") which is an unmanaged
counterpart to the GAC.

well
< snip from MSDN developers guide >
You should share assemblies by installing them into the global assembly
cache only when you need to. As a general guideline, keep assembly
dependencies private, and locate assemblies in the application directory
unless sharing an assembly is explicitly required. In addition, it is not
necessary to install assemblies into the global assembly cache to make them
accessible to COM interop or unmanaged code.
< snip from MSDN developers guide >

i read this as : Xcopy deployment is the prefered way

the mono dev group has it stated like this
What Should Be Installed to the GAC
Not all assemblies should be installed to the GAC. In fact apart from system
assemblies very few assemblies should be installed to the GAC.

Installing an assembly on the GAC involves a commitment to keep the API
backwards compatible. If you are to break compatibility, you will have to
change the version and ship and maintain as many copies as you have versions
to avoid breaking existing applications.

Here are the criteria an assembly should meet to be installed into the GAC:

a.. Useful to more then one application - There is no point to sharing a
assembly if only one application is going to use it. If a assembly is only
used by one application or is very tightly coupled to an application
side-by-side deployment is a better solution then the GAC
b.. Only loads assemblies that are in the GAC - If your assembly loads or
references assemblies that are not in the GAC it should not be installed to
the GAC.
c.. Commitment to maintain a backwards-compatible library, commitment to
use different versions on API breakage - Unless your API is mature you
really want to avoid using the GAC because you will make breaking changes or
need to refactor your library. If you have existing users, the burden is on
the user to install multiple versions of your library.
If your library does not match the above criteria, or you are not in a
position to guarantee backwards compatibility of the libraries at this time,
you should encourage your users to link and develop against a particular
version and to ship the library bundled with their software.

I would not consider multiple versions of the same DLL on the system as
DLL Hell. DLL Hell describes versioning problems, not DLL redundancy on a
system.

I think the term is often misused because the end result is the same , an
application that will not run because of a missing dependancy or doesn`t
have the required interface or version

The difference in thoughts we have is because you are probably a wishfull
thinker ( positive aproach ) i am in contradiction a true pessimist if i
have to forsee a problem in 2 scenario`s and one is postive and the other is
negative i go for the negative version ( coder will commit himself to
maintain compatibility is read by me as "Coder will in a point of time
forget his commitment" and so break my app , solution i ship the required
dll with my app )


JMO

Michel Posseth [MCP]

 

[Scott M.]

Thanks for that unsolicited dissertation. It seems that your biggest beef
with the GAC is the possibility of a new version of a .dll unintentionally
breaking the applications that are using it. This really boils down to a
single point. Maintaining backwards compatibility of a .dll by keeping its
interface the same during updates.

This has absolutely ZERO to do with the GAC and everything to do with
competence in OOP by the programmer. The introduction of the GAC is what
largely removed DLL Hell from the Windows programming radar. DLL Hell was
50% based on incorrect registry entries and since .NET assemblies don't
utilize the Windows registry, we can eliminate those problems. The other
50% of DLL Hell problems came from versioning. But since the GAC was
designed to allow for multiple version registration (strong naming being the
key to unique identification not the actual .dll name), multiple versions
and policies make this a snap as well.

Your statement was:

Which is ridiculous! It is neither informative nor does it show any real
understanding of what the GAC is and when and why it is VERY useful.

LOL - I think you just need to do some investigating about the GAC. It's
not the best solution all the time, but in many situations (like commonly
used assemblies), it may be just the ticket to simpler deployment and
version control.

The .NET Global Assembly Cache (GAC) is a misunderstood and misused beast.
For all intents and purposes, it provides what COM and windows\system32
do, i.e. a machine-wide place to drop shared DLLs. Of course, the problems
with sharing DLLs in a machine-wide spot is that it leads to a set of
well-known problems collectively called "DLL Hell." There are many
problems, but the biggest is that when a shared DLL is updated, you're
really updating an unknown set of applications. If the set of applications
is unknown, how can you possible test them before making this change? And
if you can't test them, you're likely to break them. What this boils down
to is that any of the shared spots for updates, whether it's a COM CLSID,
windows\system32 or the GAC, are dangerous and should be avoided. And this
is why the preferred .NET deployment scenario is "xcopy deployment," i.e.
having your own private copy of each DLL that you test and deploy with the
rest of your application.

Aha!" you say. "The GAC supports multiple version of an assembly! When a
foo.dll is updated to v1.1, v1.0 sits right along side of it so that your
app *doesn't* break!" Of course, that's absolutely true. But if that's the
case, why do you care? I mean, if there's a new assembly available but
your app isn't picking it up, what difference does it make?
"Aha again!, you say. "I can put a publisher policy into the GAC along
with my assembly so that apps *are* updated automatically!" That's true,
too, but now, like any of the machine-wide code replacement strategies of
old, you're on the hook for an awesome responsibility: making sure that as
close to 0% of apps, known to you or not, don't break. This is an awesome
responsibility and one that takes MS hundreds of man-years at each new
release of the .NET Framework


So using the GAC is bringing back the Dll hell that is my statement ( also
in my previous post ) i do not see anything funny about it i am bloody
serious about it
as i said there are situations were the GAC might be a good solution ,
however in these scenario`s you have a big responsability that is why i
said use it only in a managed environment ( that`s just my opinion ) .


regards

Michel Posseth [MCP]

LOL - I think you just need to do some investigating about the GAC. It's
not the best solution all the time, but in many situations (like commonly
used assemblies), it may be just the ticket to simpler deployment and
version control.

 

[Scott M.]

Well you are right , however in the company`s i have worked for i wouldn`t

bet my life on the fact that my collegues did not break the compatibility
so i choose to be on the safe side .

I would never make an application more complex or degrade the performance
just so my collegue's code will work.

 

[Scott M.]

I also think you have also been looking at this from only 1 side of the
fence. Using the GAC has many other benefits (security and performance)
that you do not get with private assemblies. To simply say "don't use the
GAC" because someone else may write bad code is, IMHO, absurd.

LOL - I think you just need to do some investigating about the GAC. It's
not the best solution all the time, but in many situations (like commonly
used assemblies), it may be just the ticket to simpler deployment and
version control.

The .NET Global Assembly Cache (GAC) is a misunderstood and misused beast.
For all intents and purposes, it provides what COM and windows\system32
do, i.e. a machine-wide place to drop shared DLLs. Of course, the problems
with sharing DLLs in a machine-wide spot is that it leads to a set of
well-known problems collectively called "DLL Hell." There are many
problems, but the biggest is that when a shared DLL is updated, you're
really updating an unknown set of applications. If the set of applications
is unknown, how can you possible test them before making this change? And
if you can't test them, you're likely to break them. What this boils down
to is that any of the shared spots for updates, whether it's a COM CLSID,
windows\system32 or the GAC, are dangerous and should be avoided. And this
is why the preferred .NET deployment scenario is "xcopy deployment," i.e.
having your own private copy of each DLL that you test and deploy with the
rest of your application.

Aha!" you say. "The GAC supports multiple version of an assembly! When a
foo.dll is updated to v1.1, v1.0 sits right along side of it so that your
app *doesn't* break!" Of course, that's absolutely true. But if that's the
case, why do you care? I mean, if there's a new assembly available but
your app isn't picking it up, what difference does it make?
"Aha again!, you say. "I can put a publisher policy into the GAC along
with my assembly so that apps *are* updated automatically!" That's true,
too, but now, like any of the machine-wide code replacement strategies of
old, you're on the hook for an awesome responsibility: making sure that as
close to 0% of apps, known to you or not, don't break. This is an awesome
responsibility and one that takes MS hundreds of man-years at each new
release of the .NET Framework


So using the GAC is bringing back the Dll hell that is my statement ( also
in my previous post ) i do not see anything funny about it i am bloody
serious about it
as i said there are situations were the GAC might be a good solution ,
however in these scenario`s you have a big responsability that is why i
said use it only in a managed environment ( that`s just my opinion ) .


regards

Michel Posseth [MCP]

LOL - I think you just need to do some investigating about the GAC. It's
not the best solution all the time, but in many situations (like commonly
used assemblies), it may be just the ticket to simpler deployment and
version control.

 

[Cor Ligthert [MVP]]

Scott,

I found it a nice discussion, why bring it in this way, as "unsolicited
dissertation" .

All what we, in my opinion including you, write or do in this newsgroup is
unsolicited. It is a gift to others trying to deal them in our knowledge
hoping the other will do the same to bring ourselves to the best
conclusions.

Just my thought reading your message.

Cor

 

[Cor Ligthert [MVP]]

Scott,

I would never make an application more complex or degrade the performance
just so my collegue's code will work.

That is in my idea the base for the private and public scope of members.

Cor

 

[Michel Posseth [MCP]]

Well if i translate this to my native tongue ( ongevraagde verhandeling )
it is a bit offensive to me

Sorry but if this is the way you discuss with people i stop responding right
away , maybe i misunderstood the word discussion group wrong when i started
participating .

However it is clear to me that you are a Russian democrat , however a lot
of people think different and this has nothing to do with not understanding
but other points of view .

And in this case i have another point of view wich is perfectly valid but
aparently not for you , you do not even hear my arguments in the discussion
it is good for a person to talk but i respect a person more as he also can
listen .

So i will now move on maybe i can make someone else happy with my
"unsolicited dissertation`s" ,,,

Kind regards,

Michel Posseth [MCP]

Thanks for that unsolicited dissertation. It seems that your biggest beef
with the GAC is the possibility of a new version of a .dll unintentionally
breaking the applications that are using it. This really boils down to a
single point. Maintaining backwards compatibility of a .dll by keeping
its interface the same during updates.

This has absolutely ZERO to do with the GAC and everything to do with
competence in OOP by the programmer. The introduction of the GAC is what
largely removed DLL Hell from the Windows programming radar. DLL Hell was
50% based on incorrect registry entries and since .NET assemblies don't
utilize the Windows registry, we can eliminate those problems. The other
50% of DLL Hell problems came from versioning. But since the GAC was
designed to allow for multiple version registration (strong naming being
the key to unique identification not the actual .dll name), multiple
versions and policies make this a snap as well.

Your statement was:

Which is ridiculous! It is neither informative nor does it show any real
understanding of what the GAC is and when and why it is VERY useful.

LOL - I think you just need to do some investigating about the GAC.
It's not the best solution all the time, but in many situations (like
commonly used assemblies), it may be just the ticket to simpler
deployment and version control.

The .NET Global Assembly Cache (GAC) is a misunderstood and misused
beast. For all intents and purposes, it provides what COM and
windows\system32 do, i.e. a machine-wide place to drop shared DLLs. Of
course, the problems with sharing DLLs in a machine-wide spot is that it
leads to a set of well-known problems collectively called "DLL Hell."
There are many problems, but the biggest is that when a shared DLL is
updated, you're really updating an unknown set of applications. If the
set of applications is unknown, how can you possible test them before
making this change? And if you can't test them, you're likely to break
them. What this boils down to is that any of the shared spots for
updates, whether it's a COM CLSID, windows\system32 or the GAC, are
dangerous and should be avoided. And this is why the preferred .NET
deployment scenario is "xcopy deployment," i.e. having your own private
copy of each DLL that you test and deploy with the rest of your
application.

Aha!" you say. "The GAC supports multiple version of an assembly! When a
foo.dll is updated to v1.1, v1.0 sits right along side of it so that your
app *doesn't* break!" Of course, that's absolutely true. But if that's
the case, why do you care? I mean, if there's a new assembly available
but your app isn't picking it up, what difference does it make?
"Aha again!, you say. "I can put a publisher policy into the GAC along
with my assembly so that apps *are* updated automatically!" That's true,
too, but now, like any of the machine-wide code replacement strategies of
old, you're on the hook for an awesome responsibility: making sure that
as close to 0% of apps, known to you or not, don't break. This is an
awesome responsibility and one that takes MS hundreds of man-years at
each new release of the .NET Framework


So using the GAC is bringing back the Dll hell that is my statement (
also in my previous post ) i do not see anything funny about it i am
bloody serious about it
as i said there are situations were the GAC might be a good solution ,
however in these scenario`s you have a big responsability that is why i
said use it only in a managed environment ( that`s just my opinion ) .


regards

Michel Posseth [MCP]

In my opinion the GAC is only to be used with BL objects in corporate
environments , in all other situations it is a ticking time bomb (
stay away of it as it were the plague )


LOL - I think you just need to do some investigating about the GAC.
It's not the best solution all the time, but in many situations (like
commonly used assemblies), it may be just the ticket to simpler
deployment and version control.

 

[Scott M.]

I used those terms because Michel was trying to back up a ridiculous
statement with what seemed to me as a dissertaion that was not requested,
needed or even accurate. He followed one bogus statement with another.

 

[Scott M.]

Not sure what you mean here Cor. What I meant was that I wouldn't go the
private assembly route just because other collegue's will have an easier
time with this, when I know that it would make my application messier and
perhaps slower. I'm not referring to members of a class (internal code)
here.