Whidbey's new Click Once (No Touch Deployment version 2), offers a new feature called "permissions elevation" .Net Security Blog:
"Permission elevation allows a ClickOnce application to specify that it would like to run with a specified set of permissions, and it can be granted these permissions without the need to have the user modify their policy."
If the user grants the permissions the application is run. If the user denies the permissions the application won't be run at all.
This is a huge improvement over the existing No Touch Deployment (NTD) in VS 2003, but it is only a start. To explain the problem, I will describe our application and Permissions Elevation's limitations.
We've developed a NTD app for use over both intranets and the internet. Our app checks to see what permissions it has and then quietly degrades the functionality (as recommended in Matthew Lyons chapter "Writing a Semi-Trusted Application") if they're not available. The thinking is the application should always run and adapt if the permissions are not available.
Permissions elevation all or nothing approach is the opposite of the way we developed the application. We would like some permissions (like unmanaged code for excel export), but can live without most of them.
To make use of the permissions elevation feature we will need to create two (or more) links on the web page to launch the app. The first link will be: "Launch the app with many permissions and all features", the second "Launch the app with the default permissions and fewer features". While the framework has avoided any issues with the complexity of optional permissions, the burden is being pushed down to the NTD developers and our end-users.
Improvements I'm asking for:
Whidbey: If the user denies the permission request, then the application can still be run with its original permission set.
After Whidbey: Give the users an explanation of the features and the permissions they are tied to. Perhaps allowing the user to add permissions once the program is installed and running. Consider this scenario: John launches the NTD app from the internet with the standard low trust permission set. After doing some work he wishes to export the data excel. He chooses File -> Export -> Excel and up pops a dialog saying, "the application has asked for unmanaged code permission to complete this action".
If you agree with me then vote for FDBK14571 on ladybug (aka labs.msdn.microsoft.com/productfeedback)
So you've built a WinForms app and its a struggle to deploy, here are some tips.
Clear the IE and download cache (gacutil /cdl) on the client machine to ensure that old versions of dll's have not been left lying around.
Check the client machine trust's your application/website.
Ensure the vitrual directory (in IIS) that has your .exe and .dll's is properly configured
-
Ensure the permissions are set to Read and Run Scripts. (Not Execute as that would try to run applications server side).
-
If the application uses a configuration file then ISS's default handling must be disabled: Under Configuration dialog in the Mappings Tab, remove the entry for the .config extension.
-
Don't use a virtual directory named “exe“ - apparently asp.net has a directory watcher process that 'corrects' the permissions of exe directories once a day.
Use your IIS log to see if the application files have been sent to the client.
Enable the "IEHost Log" (more details including how read the log at: 
http://support.microsoft.com/default.aspx?scid=kb;en-us;313892)
Add the following registry keys (using Regedit):
In HKEY_LOCAL_MACHINE/Software/Microsoft/.NETFramework
- Add a DWORD value named DebugIEHost to this key; assign it any non-zero value.
- Add a string value named IEHostLogFile. Assign it the full path (including the file name) of the file in which you want to record the debug trace (for example, C:/Temp/IEDebug.log).
Use fuslogvw (installed with dev environment) to look for binding errors. At the end of the help page there are a couple configuration settings that are occasionally useful in debuginng bind problems.
Now the application is running on the client machine here are the tools I use to debug it:
-
To launch a debugger, put the call 'System.Diagnostics.Debugger.Break();' in your code. That will launch the JIT debugging dialog. I recommend you choose 'New Instance of Mircosoft CLR Debugger 2003' (don't choose your current editing devenv, it will probably lock up).
-
Attach to the running process via the Processes dialog (Debug -> Processes...)
- To capture Debug.WriteLine() output, use Sysinternals DebgugView This is the only option that doesn't require the development enviroment on the client machine.
If you want to see a no touch deployment application in action, see my posting: First Commercial .NET No Touch Deployment application