Assemblies on Shared Drives

[Dmorley]

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? It should mean that the Citrix team only have to do one bit of configuration, then we can roll out updates as and when...?


Thanks

[Dmorley]

I think I've managed to look into the above 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

[mmetzger]

My company uses a .NET app hosted inside IE. We sit at the All_Code area to host trust the app. We also use several 3rd party components and it works fine here. The biggest problem I've seen is if everyone doesn't access the app in the same way (ie, some use DNS, some use IP, some use machinename, etc.) The security doesn't always work if an alias is used.