Common Files...vs GAC

  • Thread starter Thread starter VJ
  • Start date Start date
V

VJ

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
 
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.
 
Thanks David , that was really helpful

VJ
David Levine said:
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.
Click to expand...
 
Back
Top