Re: How can I use a dll with several programs?

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:

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 )

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.


"Michel Posseth [MCP]" <MSDN@xxxxxxxxxxx> wrote in message
news:ubwOSEcyGHA.5048@xxxxxxxxxxxxxxxxxxxxxxx
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]


"Scott M." <s-mar@xxxxxxxxxxxxx> schreef in bericht
news:eAy2eFTyGHA.3568@xxxxxxxxxxxxxxxxxxxxxxx
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.





.

Relevant Pages

  • Re: .NET versioning
    ... >> If this isn't dll hell then it's awfully close. ... > xcopy deployment, which thus means avoid the GAC if possible. ... > 2) if required, and if you really have to, copy the files to the GAC. ... If you overwrite assemblies in the GAC ...
    (microsoft.public.dotnet.framework)
  • Re: How can I use a dll with several programs?
    ... The dll hell has everything to do with versioning of dll`s stored in one ... I don't think the DLL applies to the GAC or the Win32 Side-by-Side cache ... mechanism for Win32 assemblies. ... You should share assemblies by installing them into the global assembly ...
    (microsoft.public.dotnet.languages.vb)
  • Re: .NET versioning
    ... >> not* do this yourself because it is a return to Win32 DLL Hell. ... >> The GAC recognises only the .NET version, ... > No install processes, you copy the files. ... For assemblies in the GAC use publisher policy or recompile...this does not ...
    (microsoft.public.dotnet.framework)
  • Re: Assembly Versioning for Multiple Frameworks and Platforms
    ... Does anyone happent to know if the 64-bit GAC is also ... version number for each framework build. ... what tool do you use to make your 1.0 assemblies? ... We use a naming scheme in the dll for the versions. ...
    (microsoft.public.dotnet.framework)
  • Re: How can I use a dll with several programs?
    ... with the GAC is the possibility of a new version of a .dll unintentionally ... Maintaining backwards compatibility of a .dll by keeping ... largely removed DLL Hell from the Windows programming radar. ... 50% based on incorrect registry entries and since .NET assemblies don't ...
    (microsoft.public.dotnet.languages.vb)
Loading