Installing the exe assembly on each and every computer just isn't an option!

[Carl Johansson]

I think I'm going nuts! I have a perfectly fine exe assembly built with
Microsoft Visual C# 2008 Express Edition. When executed from my local hard
drive it runs as exactly as expected. However, when trying to launch it from
a network drive it just won't run. One suggestion I saw was to start the
"Microsoft .NET Framework 1.1 Wizards" and run "Trust an Assembly". However,
after having browsed to the assembly the wizard simply reported that it
wasn't possible to load the assembly. So I continued my search and added
this to the AssemblyInfo.cs file of my project:

[assembly: SecurityPermission(SecurityAction.RequestMinimum, UnmanagedCode =
true)] // Request to run unmanaged code
[assembly: FileIOPermission(SecurityAction.RequestMinimum, Unrestricted =
true)] // Request complete File IO functionality
[assembly: RegistryPermission(SecurityAction.RequestMinimum, ViewAndModify =
"*")] // Request complet access to the registery key
[assembly: ZoneIdentityPermission(SecurityAction.RequestMinimum, Zone =
SecurityZone.NoZone)] // Request unrestricted zone

I then recompiled the project (had to add the namespaces
"System.Security.Permissions", "System.Security.Policy", and
System.Security), copied it to the network drive, and tried the Microsoft
..NET Framework 1.1 Wizards again. Same result: "not possible to load the
assembly".

I realize this is a .NET security issue, but there must be some easy to
understand way to get this working, or at least some tutorial that can
explain what needs to be done. The assembly "talks" to a SQL Server 2000
server on the network, and works perfectly fine when executed from a local
hard drive on any computer in the network.

Regards Carl Johansson

 

[Marc Gravell]

You can't use the 1.1 wizard because this is a 2.0 (or higher) assembly;
1.1 is not compatible with the 2.0 CLR that drives 2.0, 3.0 and 3.5.

The 2.0 wizard (unlike the 1.1 wizard) is not installed by default with
the runtime; it is part of the SDK instead. You can generate an msi from
a central machine that can be used (on other machines, perhaps via group
policy) to overwrite the security settings - but to me this is too big a
brush. Alternatively, you can use "caspol" on each machine to change the
security settings (perhaps via a login script).

However, the better option is probably ClickOnce; a ClickOnce deployment
includes trust information and can be signed etc, and includes all the
common auto-update options you might want (which makes updates
comparable to the "zero touch" approach you are currently using for
deployment).

The full VS2005/VS2008 include ClickOnce support by default - otherwise
you're looking at "mage.exe".

Marc