You can use security to restrict callers into your assembly - I don't recall
the details but I believe there is an attribute you can decorate the classes
and methods with that require the caller to be signed with a specific strong
name.
As to the GAC, I prefer to avoid putting application specific files in the
GAC. I believe that over time the GAC will get as overused and lead to as
many problems as we have had with the registry. I prefer to create a Common
folder in a directory below the application base and ensure that references
to assemblies in that folder can be resolved by the fusion layer.
One of the reasons is that this is compatible with xcopy deployment. Using
the GAC requires an installation program to add/remove assemblies. If the
DLLs are kept private then installing the files is done simply by copying
them along with the application, and uninstalling is merely a matter of
deleting the files.
Another advantage is that it makes it easier to configure a clean build
machine. All references to those assemblies can be made relative to the
directory on disk, and nothing needs to be installed onto that machine for
the build to succeed.
There are some advantages to using the GAC, but IMO these are of benefit
mainly for components that are expected to be shared amongst unrelated
applications.
My two cents worth.
"VJ" <vi********@yahoo.com> wrote in message
news:uW****************@TK2MSFTNGP15.phx.gbl...
We have a bunch of dll's that are shared among our 5 applications. We are
still debating between putting it in CommonFiles vs GAC. I still see a
problem with putting in GAC that it will be available in any any
development enviroment by default. It can also be from Commonfiles, but
mostly that would be a manual browsing and add reference. Is there a way
to Secure deployment possible in GAC, other than issuing a LIC key for
each dll, that only our applications can read.. Oh all our commong DLL's
are in .NET and are in managed code.
Thanks
VJ