Executing Assemblies on Shared Paths

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

DylanM - 31 Aug 2005 16:30 GMT

Hi,

We are a software development team for a retail company, all of the programs
we develop are for use internally on our network. Recently, we have moved
towards thin-client technology with everyone running remote desktops using
Citrix.

This proves to be troublesome when deploying - only domain administrators
can actually install anything onto the Citrix Server itself. Since we have a
farm of about 30 servers, we have to schedule in a deployment date & ensure
the Citrix team carry out the install correctly and replicate it across all
servers!

We've got around this in the past by deploying onto a network share that has
user specific data in. Eg;

\\SharePath\data\UserName\Program Files\MyExecutable.exe

This ensures we are in control of our programs, we have an auto-update
program that rolls out any fixes or amendments we have made to programs -
there is no major delay in rolling out a new version.

In the .Net framework, there are security issues when running from a shared
network drive. What is the best approach to allow us to continue to run an
executable from a share path, using resources located locally on the Citrix
Server?

We have a Strong Name key file for our department that we sign all of our
programs with. If the Citrix team amend the security configuration for the
.Net framework on each of the servers, can we trust all assemblies signed
with our Strong Name Key so that they can run from network shares (as in .7
of .NET Framework Enterprise Security Policy Administration and Deployment
FAQ?)

Is this the best approach to allow us to continue share deployment?

Thanks

Reply to this Message

DylanM - 02 Sep 2005 09:55 GMT

I think I've managed to look into this enough to determine that it is the
best solution with the minimum amount of administration for everyone
involved.

However, it brings me to another question!

Our in-house developed programs will all be signed so that the security
policy trusts these assemblies. However, we also use some third party
components etc that also require trust to be executed on a share.

Should we create a code group just below the 'All Code' level for each
vendor who sign their assemblies with a different strong-name? I have tested
this, and it works on my machine.

Would it be a better configuration to create code groups for the third party
vendors as children of our in-house code group? This seems to keep everything
grouped together, it will be clearer to everyone that the children code
groups are all used by our in-house apps, rather than having various groups
at the All_Code level. I did try to test this, but encountered security
exceptions.

I didn't change the settings of the code group at all, merely the level at
which it resides on the tree. Just below All_Code, it works fine. As a child
of our in house code group, it fails.

Is there something else I need to configure, or just stick with everything
at All_Code level? (since that works!!)

Any advice on recommended configurations appreciated.

Thanks

> Hi,
>
[quoted text clipped - 33 lines]
>
> Thanks

Reply to this Message

Executing Assemblies on Shared Paths

Free Magazines