Strong Name Assembly

[Roman]

My Windows Forms Application loads an assembly,
AppDomain.CurrentDomain.Load(assemblyName),from the web.
The loaded assembly interacts with excel. Normally, I am
getting security exception. To aviod getting the exception
I would have to chenge the security policy on the local
system. My question is: if I put a strong name in my
assembly would it allow me to interact with excel without
having to set the secirity policy on the system. The
reason is that I shouldn't force the users to midify their
security setting specifically for my application.

 

[Hernan de Lahitte]

Unfortunatelly, just strongnaming your assemblies won't solve your problem.
You will have to modify the security policy as well.
To modify the polcy to trust a specific strong name by using the Microsoft
..NET Framework Configuration you have to follow this steps:
1.. Right click on All_Code (Machine policy level) , and select New
2.. Create a new code group for your strong name, and hit next
3.. Select a strong name membership condition from the drop down box
4.. Hit the import button, and select your assembly. The configuration
tool will import your public key. If you want to trust everything you sign
with this key, leave the name and version boxes unchecked
5.. Select the FullTrust permission set. (A better way might be to use a
custom named permissionset with only your required permissions).
If you don't want to force every user to change its security policy
manually, you can use several deplyment options.
Here we have some of them:

a) Creating an MSI deployment package with required Policy settings and
pushing it across the corpnet via SMS deployment.
b) Using Group Policy mechanism to do basically the same.
c) Making sure all the corp machine run at logon time some script that
configures the policy.

 

[Roman]

Your answer is a big help to me. Users of my application
are unrelated individuals (sometimes working from home)
and organizations. Which approach, do you think, is most
effective?

 

[Hernan de Lahitte]

This depends on your clients networking connection requirements (VPN, plain
HTTP, others). This has to do basically if your clients are authenticating
against any AD domain or just accessing your app from the internet with just
http. If your scenario is the latter, you might use option "a" and put your
msi in a web site to be downloaded and installed by your clients (Recall you
usually need administrator privileges to modify the security policy).


You might find usefull information in this FAQ:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/entsecpoladmin.asp
Here you will find good tips for admin. sec. policies:
http://msdn.microsoft.com/library/d.../cpcongeneralsecuritypolicyadministration.asp

 

[Roman]

Thanks Hernan,

The users connect over the HTTP connection. Your last
message confused my a little. My application is going to
be installed over http connection using Microsoft
installer (as you wrote in your message). But than the
installed application will load assemblies (as needed).

AppDomain.CurrentDomain.Load(assemblyName),

These assemblies will not be installed locally. They will
have to be loaded again if need again. These assemblies
interact with excel application and maybe a file system.
As such they need to deal with the security issues we have
been talking about.

Was it your understanding of the scenario as well?

Roman

 

[Hernan de Lahitte]

The assembly that you load with "AppDomain.CurrentDomain.Load(assemblyName)"
must be strongnamed and the security policy updated in a previous
installation of the msi Deployment Package. This msi might be installed
after your main application deployment.
Another approach to consider might be to modify the security policy by code
from an installer class in your main application. This class would be
configured as a "custom action" on your main app installer project. I think
this will give you the added benefit of a better "user friendly" deployment
by updating the sec policy in the background. Of course, this last strategy
will work only if the client user account has administrative privileges over
this machine.


Hernan de Lahitte
Lagash Systems S.A.
http://weblogs.asp.net/hernandl

 

[Roman]

Thanks Hernan,

You are are right. It would be a better way. Does it mean
that if the user is an 'admin' then the applicatikon's
installer can modify the security without the user's
permission during the installation process? Do you have
any code examples?

Roman

-----Original Message-----
The assembly that you load

with "AppDomain.CurrentDomain.Load(assemblyName)"