How can I use a dll with several programs?

[Michel Posseth [MCP]]

Scott

Using the GAC has it`s advantages however my statement is that i would not
trade these advantages for the dissadvanages that i get in return

My main problem with the GAC is that it increases the complexity of
installing and uninstalling your application

<snip from answer to Herfried >
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 .
</snip from answer to Herfried >

About the security and perfomance

perfomance :

Wich perfomance you mean the nanosecond it takes to locate the assembly ??
( i know GAC is the first place it looks however second is the app dir )
for the rest i can`t find anny perfomance benefit in the documentation i
have ( an i do own a impressive library )

security :
That is just how you look at it , Installers are designed to work in a non
administrative modus , however when i do a installation to the GAC i must be
an administrator due to the fact of system ACL ( you do not want to grant
write permissions for your users on the system directory`s ) so in the end
it costs more complexity again to even deploy your app or it costs essential
security .


again : every advantage has a dissadvantage it is just what is more
worth to you ( it is obvious that i choose a different path as you )

PS.

For me this was a apreciated discussion , until you decided to imitate a one
party democratic structure i was and am just telling my arguments why
i would not use the GAC in my situation ( deployable app ) if you would ask
me the same thing in a managed corporate environment well in this situation
i have another opinion ( although i recently started working in such an
environment and i use a global application directory , as this is easier
with Kix scripting for our system administrator )


regards

Michel Posseth [MCP]

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]

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.

 

[Cor Ligthert [MVP]]

Scott,

But you wrote in your previous sentence

you would never make an application more complex or degrade the performance
just so my colleagues code will work.

Is that not what Michel is in a way is doing, by protecting things he makes
it easier for his colleagues to do things without to worry about not needed
things. Therefore my analogy (maybe should I have written that by my
sentence) to private and public scope of members.

Cor

 

[Cor Ligthert [MVP]]

Michel,

again : every advantage has a dissadvantage

I thought Scott is an American, do you think he knows Johan Cruyff

Cor

 

[Michel Posseth [MCP]]

I just knew you would react on this

But i just hope he gets the point

Groeten

Michel

 

[Scott M.]

It is a discussion Michel. And so, I have the right to respond as I see fit
(are you disagreeing with that?). If you took personal offense at my
remark, I apologize, perhaps the American term "rant" would have been more
appropriate.

You originally wrote: "in all other situations it is a ticking time bomb
( stay away of it as it were the plague )".

Which is an absurd statement, based on no fact whatsoever. Since then, you
have loosened your original stance a bit, but you still haven't written
anything that indicates to me that you truly (and more importantly)
understand the function of the GAC. One example would be that on
performance, you simply talk about the "nanosecond" quicker an application
may start. Well, I haven't measured myself, but I believe it can be more
than that and if you now multiply that time by the amount of assemblies your
application may need, we are talking about more than that. But, that isn't
even the performance benefit that I was referring to. If several programs
use copies of the same assembly, EACH assembly will be loaded into memory.
If those same programs were to use a GAC assembly, the assembly is loaded
ONE time.

Having to be an admin to install a program is nothing new and a benefit
IMHO.

 

[Scott M.]

I think Michel is saying that sacraficing the security and performance
benefits offered (in some situations) by the GAC so that his collgue's don't
have to write code correctly or understand versioning properly is
acceptable, I disagree.

 

[Michel Posseth [MCP]]

It is a discussion Michel. And so, I have the right to respond as I see
fit
(are you disagreeing with that?).

No i do not , as i said i have the feeling that you were giving me no room
to ventilate my opinion

If you took personal offense at my remark, I apologize, perhaps the
American term "rant" would have been more appropriate.

Yes i did , and i accept your apolygee .

You originally wrote: "in all other situations it is a ticking time bomb
( stay away of it as it were the plague )".

This is my opinion still , in a perfect world it would not happen however
the world isn`t perfect

Which is an absurd statement, based on no fact whatsoever. Since then,
you have loosened your original stance a bit, but you still haven't
written anything that indicates to me that you truly (and more
importantly) understand the function of the GAC. One example would be
that on performance, you simply talk about the "nanosecond" quicker an
application may start. Well, I haven't measured myself, but I believe it
can be more than that and if you now multiply that time by the amount of
assemblies your application may need, we are talking about more than that.
But, that isn't even the performance benefit that I was referring to. If
several programs use copies of the same assembly, EACH assembly will be
loaded into memory. If those same programs were to use a GAC assembly, the
assembly is loaded ONE time.

Well i did not find anny proof yet for your claimed performance benefit but
i will investigate this ( thought that this was happening with all signed
assembly`s )
i might have learned something new

Having to be an admin to install a program is nothing new and a benefit
IMHO.

Well having written programs for large organizations ( like the euromaster
group ) that have a policy installed that my software can be installed
without a administrator i know it is sometimes necesary



Well i have to go to work now

regards

Michel Posseth [MCP]

 

[Scott M.]

You may want to take a look at the following articles that discuss pro's &
con's of the GAC, but do talk about GAC performance gains:

http://msdn.microsoft.com/msdnmag/issues/06/05/CLRInsideOut/
(Look at the "Assemblies and the GAC" section, which discusses NGen, the GAC
and start up time).

http://blogs.msdn.com/kevin_ransom/archive/2004/05/28/143731.aspx

http://www.gotdotnet.com/team/clr/when_to_use_the_gac.aspx

It is a discussion Michel. And so, I have the right to respond as I see
fit
(are you disagreeing with that?).

No i do not , as i said i have the feeling that you were giving me no room
to ventilate my opinion

If you took personal offense at my remark, I apologize, perhaps the
American term "rant" would have been more appropriate.

Yes i did , and i accept your apolygee .

You originally wrote: "in all other situations it is a ticking time bomb
( stay away of it as it were the plague )".

This is my opinion still , in a perfect world it would not happen however
the world isn`t perfect

Which is an absurd statement, based on no fact whatsoever. Since then,
you have loosened your original stance a bit, but you still haven't
written anything that indicates to me that you truly (and more
importantly) understand the function of the GAC. One example would be
that on performance, you simply talk about the "nanosecond" quicker an
application may start. Well, I haven't measured myself, but I believe it
can be more than that and if you now multiply that time by the amount of
assemblies your application may need, we are talking about more than
that. But, that isn't even the performance benefit that I was referring
to. If several programs use copies of the same assembly, EACH assembly
will be loaded into memory. If those same programs were to use a GAC
assembly, the assembly is loaded ONE time.

Well i did not find anny proof yet for your claimed performance benefit
but i will investigate this ( thought that this was happening with all
signed assembly`s )
i might have learned something new

Having to be an admin to install a program is nothing new and a benefit
IMHO.

Well having written programs for large organizations ( like the euromaster
group ) that have a policy installed that my software can be installed
without a administrator i know it is sometimes necesary



Well i have to go to work now

regards

Michel Posseth [MCP]

It is a discussion Michel. And so, I have the right to respond as I see
fit (are you disagreeing with that?). If you took personal offense at my
remark, I apologize, perhaps the American term "rant" would have been
more appropriate.

You originally wrote: "in all other situations it is a ticking time bomb
( stay away of it as it were the plague )".

Which is an absurd statement, based on no fact whatsoever. Since then,
you have loosened your original stance a bit, but you still haven't
written anything that indicates to me that you truly (and more
importantly) understand the function of the GAC. One example would be
that on performance, you simply talk about the "nanosecond" quicker an
application may start. Well, I haven't measured myself, but I believe it
can be more than that and if you now multiply that time by the amount of
assemblies your application may need, we are talking about more than
that. But, that isn't even the performance benefit that I was referring
to. If several programs use copies of the same assembly, EACH assembly
will be loaded into memory. If those same programs were to use a GAC
assembly, the assembly is loaded ONE time.

Having to be an admin to install a program is nothing new and a benefit
IMHO.