Well said. Only use the GAC if you're planning on releasing libraries
that will be used by other clients besides your own applications (like
a graphics library or custom controls) and you're planning on releasing
several iterations of the libraries as development progresses.
That being said, If you were making assemblies that exhibit
commandline-like behaviour and satisfied the above requirement, then it
could be done sensible. My approach would be to make a single
command-line app that takes an assembly-reference as an argument and
then fetches that assembly out of the GAC, checks to see if it
satisfies the command-line interface, and then passes the remaining
command-line arguments on to the assembly.... but I can't see that
being a very common situation unless you're (for example) implementing
the GNU tools for DotNet.
..... in that case, why not make them as EXEs? They'd never actually be
executed from the command-line, just done as EXEs since that is pretty
much the standard way to implement a command-line app.
Either way, this is all academic - I doubt any posters in this thread
are working on anything that justifies command-line stuff in the GAC.
Anybody porting Sed to dotnet?
Bruce Wood wrote:
D wrote:
I was toying around with assemblies, signing and adding them to the GAC. I
was mistakenly thinking that if I added a console app to the GAC it could be
run from anywhere (anywhere meaning as if the path to the exe was added to
your environment variables).
It then occurred to me that in order to utilize that I would need to write
another app that references the class (from the GAC). However the program
added to the GAC was a simple console hello world type so if I referenced it
from another app it would have to be like
using FirstTest;
Program p = new Program();
p.Main();
which should invoke the console app. I haven't tried it to figure out if it
would even work but then I was questioing whether you would ever need to add
an exe to the GAC.
I would never add an exe to the GAC.
If you want to put an executable on a network drive, for example, and
run it from any client machine, then I believe that the correct
solution is to sign it, and then use .NET security on all client
machines to indicate that applications with the signature in question
are fully trusted.
You could also fully trust the machine / folder where the application
is stored, but that leaves a potential security hole. (Anyone can place
any app in that folder and it will immediately become fully trusted.)
You _can_ sign EXEs and other things that you never intend to put in
the GAC, and security can be based on signatures, not just on presence
in the GAC.
The only thing the GAC is really good for (to my mind) is dealing with
side-by-side multiple versions of libraries. Where I work we don't
bother with the GAC because for us it adds no value. We are looking
into signing, however, for exactly the reason you outlined.
