GAC Alternative

[b.b]

Is the days of VB6 we used to place all of our shared dll's in one
central location on a separate server within our network domain. All
apps that needed a shared dll would have the dll registered from this
location. If a shared dll needed to be upgraded in some way then we
would just overwrite the dll (if binary compat.) and all app that used
this shared dll would benefit from the upgrade.

Now I want to mimic this in dotnet, I want to have one central location
for shared dll's and all app's would reference these shared dll from
the central location. Now as this central location is on a separate
server I cannot install all the shared dll's in the server's GAC
because I cannot access the server's GAC from another server (unless
you know different). What I can do is reference the shared dll's from
the central location but I have to set the 'copy local = true' which is
not ideal if I want to upgrade the source dll because the client app
will need to be recompiled to pick up the new version of the shared dll
and we could be talking about hundreds of app's that would need
recompiling.

So my question is how do I store all my shared dll's on a separate
server location and reference them from other servers in dotnet but do
not copy the dll local?

I suppose what I want is a Domain Level GAC or something similar to
Active Directory for shared dll's.

Any help or links on this subject would be of help.

Many thanks

Billy

[Alvin Bruney [ASP.NET MVP]]

There is no reason why this cannot work like it used to under the vb6
approach. It's a common misconception that GAC'd assemblies must be in the
GAC. Strictly speaking, a GAC'd assembly can reside anywhere in the search
path for the application. If you choose to put it outside the search path,
simply use the configuration utility to update the application search path.

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________
<b.*@ntlworld.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

Is the days of VB6 we used to place all of our shared dll's in one
central location on a separate server within our network domain. All
apps that needed a shared dll would have the dll registered from this
location. If a shared dll needed to be upgraded in some way then we
would just overwrite the dll (if binary compat.) and all app that used
this shared dll would benefit from the upgrade.

Now I want to mimic this in dotnet, I want to have one central location
for shared dll's and all app's would reference these shared dll from
the central location. Now as this central location is on a separate
server I cannot install all the shared dll's in the server's GAC
because I cannot access the server's GAC from another server (unless
you know different). What I can do is reference the shared dll's from
the central location but I have to set the 'copy local = true' which is
not ideal if I want to upgrade the source dll because the client app
will need to be recompiled to pick up the new version of the shared dll
and we could be talking about hundreds of app's that would need
recompiling.

So my question is how do I store all my shared dll's on a separate
server location and reference them from other servers in dotnet but do
not copy the dll local?

I suppose what I want is a Domain Level GAC or something similar to
Active Directory for shared dll's.

Any help or links on this subject would be of help.

Many thanks

Billy

[Billy]

Thanks for replying Alvin ....

Tell me more please, can you explain the step I need to take to achieve
this.

I have produced a demo dll to return the time or version no. of the
dll.
I have produced a strong name key and placed this in the working
directory of the demo dll and included it in the project.
I have assigned the new key to the 'AssemblyKeyFile' property and built
the demo dll.
I have referenced the demo dll from a client app.
< what do I do now?>

I want to set the copy local to false and the client be able to call
the demo dll successfully but this fails stating that the dll cannot be
located, although the demo dll's path is listed in the
'project/properties/references path' ... I presume I have to add the
location of the demo dll to another file - as you stated '...by using
the configuration utility' but I'm unsure of what this utility is.

Billy

[Billy]

Alvin, I've done some more work on my problem with your post in mind.
I'm still unsure what the Configuration Utility is but this dis lead me
to look at the configuration file (in this case the web.config) and I
read up on <codebase>. I place the required sections in my config file
and great the dll is accessed successfully and it is not copied
locally, great I'm getting there. Now I attempted to change the dll
and recompile it but the client app failed to pick up the new version
:-( ... it seems that the client web app caches all dependancies and
uses them over the original source. But if you reboot the client
machine it will then pick up the new version, so sort of sorted but
would like to get to the bottom of how to perform this without
rebooting the client machine (For info: I create the dll move it to a
new location and the client references this location, if I rebuild the
dll I then rename the old dll and move the new one to the same
location).

Greate ... so I can access a local dll without copying locally plus I
can also change the dll on the fly and if I reboot the client machine
these changes take effect without recompiling the client

Now I want to move the location from a local location to a 'remote'
location on another machine. I've move the dll to the new remote
location, I recompile the client web app to reference the new location
as well as changing the config file to point to the new remote
location. I've rebooted the client machine but the client fails when
attempting to locate the dll stating that the dll is missing but after
reading the call stack is accually searches the remote location but
alas it fails to find the dll. So I changed the client app to copy
locally and it worked, so it is finding the dll. This now leads me on
to the fact that we are cross machine boundaries and so permissions may
be a factor now. Reverted back to copy local = false and recompiled.
So, 'a little unsure what the .Net Wizards does' in the Adminstration
Tools section but I loaded it and 'Trusted the Assembly' (full trust)
.... but still it fails to work, same error.

Can you shed any light on what I should be doing to access a remote
dll?

Many thanks

Regards

Billy

[Leon Lambert]

Sorry I do not have a answer to your specific question but i do have
some other things you will need to worry about. CAS (Code Access
Security) will probably also cause you a problem. Assemblies outside the
local machine are subject to different security and get less privileges
by default. You will need to mess with policies to give them full
access. I found this out the hard way when i created a file share and
mounted it on my same computer. Even though the assemblies actually
resided on my local drive I ended up getting CAS exceptions because I
used them via the file share. I ended up needing to create a Code Group
using the .Net configuration tools to get them to work.

Just thought I'd give you a heads up on that.
Leon Lambert

Billy wrote:

Thanks for replying Alvin ....

Tell me more please, can you explain the step I need to take to achieve
this.

I have produced a demo dll to return the time or version no. of the
dll.
I have produced a strong name key and placed this in the working
directory of the demo dll and included it in the project.
I have assigned the new key to the 'AssemblyKeyFile' property and built
the demo dll.
I have referenced the demo dll from a client app.
< what do I do now?>

I want to set the copy local to false and the client be able to call
the demo dll successfully but this fails stating that the dll cannot be
located, although the demo dll's path is listed in the
'project/properties/references path' ... I presume I have to add the
location of the demo dll to another file - as you stated '...by using
the configuration utility' but I'm unsure of what this utility is.

Billy

[Billy]

Leon, if the code is already compiled and it is now a dll will I still
have problems with CAS?

Currently I am not getting any errors relating to security permissions
which isn't helpful ... meaning that I could be barking up the wrong
tree.

[Leon Lambert]

Yes using the assemblies on a file share will cause the problem. Things
like accessing the file system has less privilege. I had to add a Code
Group and give it Trusted privelege. Also i learned a trick that the
wizard supports but wasn't well documented.
Choose URL for the condition type and use the following format for the URL
file://Y:/* Where Y is the drive letter of your fileshare. This means
assign then new permission to all file on this share. I used FullTrust
as the permission set.

Hope this helps
Leon Lambert

Billy wrote:

Leon, if the code is already compiled and it is now a dll will I still
have problems with CAS?

Currently I am not getting any errors relating to security permissions
which isn't helpful ... meaning that I could be barking up the wrong
tree.

[Billy]

Leon, are you or have you every been able to run a Client Web app on
one machine which accessed a dll on another machine and the Client app
has the property 'copy local = false' against the dll?

Regards

Billy