CAS: Running exe from intranet

Question

Before I get flamed and down-voted without mercy, my company will not allow the install of .NET3.5 on non-dev machines yet (others are currently on 3.0).

I have a managed exe on network share that needs to be able to run from there. This is a common problem with pre-.NET3.5SP1, but I cannot figure out how to solve it. I have read this question, as well as, this article, in addition to the MSDN CAS articles (which is like trying to read and understand a EULA). I cannot seem to solve this problem.

I've tried signing it; along with other suggestions found in the articles. The only way I've found to get it to run from the network is to make it a click-once application and publish it; which is unacceptable because it creates a bunch of different files in the published directory (which confuses our less-than-technical users) and creates entries in the Add/Remove Programs in the Control Panel.

I'm just a dev, so I don't have rights to set/alter machine policies and such. Can anyone give me step-by-step instructions (or point me to a easy-to-read site) on what needs to be done to enable this thing to run from the network? Is it even possible without setting machine/domain security/software policies (which I don't have access to)?

Edit
Ok... I expected to get voted down; however, it would be really nice if people would explain why they down-voted. This is a serious question that many people seem to be having a problem with; and almost no one seems to know how to fix.

Answer 1

Pre 3.5 and without access to the machine itself or machine/domain policy, I think you're out of luck.

The brute force approach is to go to Control Panel > Administrative Tools > MS .NET Framework X.X Wizards > Adjust .NET Security on each machine and set the security level for the Local Intranet zone to FullTrust. The security risk with this approach is that now you're trusting all .NET code that's available on your intranet, which may not be what your organisation wants.

The more surgical approach is to give your .NET assemblies a strong name by signing them with your development team's private key (which can be generated by .NET). Then do a once-only install of a policy on your users' machines that trusts all assemblies signed with your team's key. Now all of your team's .NET assemblies will be fully-trusted no matter where they're physically located.

Answer 2

You could create an unmanaged bootstrapper that copies your .net code locally and launches it. Or you can use click once and create a shortcut in another directory to hide you other files.