No Touch Deployment
No Touch Deployment
On Feb 17, Robi and I will be reprising our early effort, based on the feedback - this version will be more hands on. Dev Chat: No Touch Deployment in the real world from the official descritpion:
In October 2004, Databeacon launched the Databeacon Smart Client family of products. These products use no-touch deployment to provide web reporting and data analysis capabilities to Windows PC users enabled with the .NET Framework. Join the two chief developers responsible for this project as they outline the technical strategies, obstacles and actions taken in bringing one of the first no-touch commercial software products to market. This session will focus on no-touch deployment and integration with Microsoft Office products.
If you want to learn more about No Touch Deployment and see if it makes sense for your WinForms application our dev chat will be a good place to start.
What is No Touch Deployment?
When Windows Forms applications is downloaded (from a web server), run directly on the users' machines without prior installation.
BTW you might also be interested in our success story the launch of our product (and the world's first commercial No Touch Deployment application) http://dotnetjunkies.com/WebLog/mlevison/archive/2004/10/18/28961.aspx
Update: the chat has happened, the recording is now up at: http://www.placeware.com/cc/lmevents/view?id=msft021705ad&pw=2WRDXC
Recently Mike Gunderloy reviewed our 1.0 release in
Application
Development Trends. Thanks for the kind words especially about the charts
(that's been a large chunk of my work in the past two
years).
Next Wednesday (Nov 24th), Robi Khan and I will be doing a DevChat "Zero Touch Deployment"
In October 2004, Databeacon launched the Databeacon Smart Client family of products. These products use no-touch deployment to provide web reporting and data analysis capabilities to Windows PC users enabled with the .NET Framework. Join the two chief developers responsible for this project as they outline the technical strategies, obstacles and actions taken in bringing one of the first no-touch commercial software products to market. This session will focus on no-touch deployment and integration with Microsoft Office products.
Update: The dev chat has happened if you want to see the recording visit: http://www.placeware.com/cc/lmevents/view?id=msft112404my&pw=QQXK77
Apparently the recording will be online for another year (Until Nov. 24/05). If you have any questions/feedback post them in the comments and I will address them in future blog postings. In addition I will tidy up my answers to the Q/A - I'm not a fast typist and most of answers could do with some editing.
Finally Robi and I will be another dev chat on February 17th - based on the feedback so far - we will make the next one a bit more hands on. To sign up visit: http://www.microsoft.com/canada/events/event_details.aspx?event_id=1032265808
BTW you might also be interested in our success story the launch of our product (and the world's first commercial No Touch Deployment application) http://dotnetjunkies.com/WebLog/mlevison/archive/2004/10/18/28961.aspx
Finally after 2 ½ years – I can talk about the work we’ve been doing in .NET. I work for Databeacon and we produce "Web Reporting and Data Analysis" software. Last week we launched what we believe to be the world's first commercial No Touch Deployment application with .NET.
We have 3 end-user viewers in Databeacon Smart Client Standard and Smart Client Professional editions:
1) Web Reporter - for casual users raised on static report, displays a report (accessed by clicking a report name on the left) with mouse-over tooltips over on data
2) Player - modelled on the various media players - allows the user to explore data and save reports (accessed by clicking the play button at the top of a Web Reporter page, or can be a standard viewer if report designer decides to deploy that way).
3) Insight - our power-user viewer - creates reports for Insight, Player and Web Reporter with drag-n-drop OLAP and richer data filtering options. (accessed by pressing the play button in the bottom left corner of Player viewer)
To check this out visit: http://cubert.databeacon.com/smartclient/detect/detect.aspx
But before using the product, you must first ensure that you have a proper Microsoft .NET environment. There are three steps to follow:
- Verify that Microsoft .NET 1.1 Framework is installed
- Use the Microsoft .NET Framework wizard to grant full trust to trusted sites
- In Microsoft Internet Explorer, add services.databeacon.com to the list of trusted sites (via internet options)
Otherwise you can visit the feature tour or download an evaluation copy of Databeacon Smart Client standard.
Update: For the Web client Full Trust is not required. For the Player and Insight our client side solution to command line argument problem requires Full-Trust. In addition Export to Excel, Send Report as Mail etc require access to unmanaged code. This is a large part of why I asked MS for optional permissions in Whidbey see: FDBK14571 and “Click Once Permissions Elevation a good start, but...”. If we get optional permissions then we will only need UIPermission unrestricted - for drag n' drop and resize operations.
Update: a couple of images to give you an idea of what the product looks like. First the player and then Insight.
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
In "Launching No-Touch Deployment Applications with Command Line Arguments", Chris Sells described a server side solution for passing arguments to a NTD app. While this works if your clients use IIS and are willing to make these changes, we've had to implement an awfully crufty hack[1] so our clients can deploy our app. Does Whidbey Click Once solve the argument passing problem, so that we won't require Full Trust to launch our smart client?
[1] We currently use a shim approach. Launch our shim as an embedded winform. Save its command line args to file. Fire up our real NTD app (using Process.Start()). It opens the file and reads the command line args. Hang our heads in shame for using such a crufty approach. Be sad because this required full trust.
Update: Chris Sells replied saying this is exactly what 'Click-Once' is supposed to solve. Time to install Whidbey and test this all out.
What is "Winforms Web Clients hosted in IE"? Rather than use the ASP .NET model of controls that run on the server side and render to html, Winforms are downloaded to the user's machine and executed in their browser.
Why is this useful?
- Reduce the load on the server, since it will download components and push most of processing to the client side
- Reuse - if your building a smart client desktop application, the same components can be repackaged to render in the browser
- Server doesn't have to support ASP .Net - many of your clients be running Apache, Linux or even an older version of IIS
- Latency - your user's don't have to wait for a round trip
What are the limitations:
- User must wait for your dll's to download the first time
- User must be running Windows and using IE
- Your application must live within a restrictive permission set either the 'internet' or 'intranet' permision set
Articles that explain the basics: Using Windows Forms Controls in Internet Explorer and Host Secure, Lightweight Client-Side Controls in Microsoft Internet Explorer Also http://www.windowsforms.net/ has some useful resources.
Here is what I discovered through my research - these are all best guesses, so I include the observation:
- AppDomains exit - only after the browser dies. (the back, stop or refresh buttons affect them). Evidence:
- Statics persist over multiple invocations of an object (ie hit back button, reload the page and my static gets incremented).
- Threads started in controls only finish when IE exits
- Refreshing the page or returning to it with the forward button, start new versions of a control - but threads started by previous instances live on.
- When either the back or refresh buttons are hit (or the browser exits) the control's dispose method is called (stop button has no effect). Therefore we can use the dispose method to tidy up any child threads.
- Two controls on the same page share the same thread, statics et al
- IE is blocked while the thread with the control is working. So use a background thread for all computations or requests that might block
- If we use Application.DoEvents() on the control thread then IE will not appear blocked. Furthermore DoEvents() doesn't block if there are no events. All IE buttons appear to work when this is being called. BUT ***IE*** can't be stopped -- the processes dialog end task must be used.
- If we use Application.DoEvents() during an api call then IE will not appear blocked. Furthermore this method appears to be non-blocking calls can be made without having to check if there are events first. All IE buttons appear to work while in DoEvents(), but ***IE*** can't be stopped -- the processes dialog end task must be used.
If you're application is running without full trust (either from the Internet or the Intranet), then you have to keep in mind some issues:
- Controls can use IsolatedStorage to save settings and prefences. However if you launch a full blown Rich Client (ie No Touch Deployment), it will not have access to these settings.
- The default Internet permission set provides the following restrictions are:
- no access to the system clipboard: so copy and paste only within the application, no drag & drop - at all
- top level windows display a warning banner
- access to the filesystem only through the default ("safe") File Open dialog
- no access to enviroment variables
- printing only via the default ("safe") printing dialog
- The default LocalIntranet permission set is more open, it
- full access to the system clipboard
- no warning banner around top level windows
- access to the filesystem only through the default ("safe") File Open and Save dialog
- provides access to the USERNAME enviroment variable
- Provides printing programmatically to the default printer, along with safe printing through a less restricted dialog box.
- a few other permissions which have never been useful to me (run caspol -l to see the entire list)
Update: I've just published a new article “Debugging No Touch Deployment apps“
If you want to see a no touch deployment application in action, see my posting: First Commercial .NET No Touch Deployment application
Jon has a short
interview with David Treadwell interview
Jon ask's "Why wasn’t No-Touch Deployment more successful, and how will ClickOnce correct that?" Treadwell: No-Touch Deployment was shaky. It didn’t have the infrastructure to do auto-updates. You want to be able to install in a low-impact manner without changing the machine configuration. And when you’re cached on the machine, you want to check for updates and refresh that cache automatically. The infrastructure wasn’t quite there yet; ClickOnce, in Whidbey, will be better.
Its funny, I think David misses much of the point. The caching features of No-Touch Deployment (NTD) work well enough. Click Once will be useful, but there are many other issues dealing with NTD apps. My impression is that MS didn't dog-food enough NTD.
I think there are a few key areas that need work:
- When the smart client is launched from a web page and you have a config file, then you can't have CGI style command line arguments (app.exe?param:value). Because IE will ask for app.exe?param:value.config instead or app.exe.config. Chris Sells proposes a solution Launching No-Touch Deployment Applications with Command Line Argument that requires server side code to resolve "app.exe?param:value.config" back down to app.exe.config. Unfortunately, that doesn't work if you can't install code on customer's server. Nor is it appealing to have to write 3 versions of this solution, ASP.NET, ASP and Perl/Python to support Apache
- Lack of documentation and tutorials. We need two tutorials:
a) A complete tutorial that shows a multiple assembly application, being deployed as an embedded application (via an OBJECT tag) aka a follow-up to the Windows Forms Tutorial
b) Another tutorial detailing a multiple assembly application, being deployed as a rich client using no-touch install aka a follow-up to Chris Sells NET Zero Deployment Security and Versioning Models in the Windows Forms Engine Help You Create and Deploy Smart Clients.
Both tutorials should demonstrate:
- strongly naming all assemblies
- use of cab files
- use of config files as required
- use of features that require permissions
- how to assert permissions and what will happen if we try to use dll with
minimum permission requirements
- how to debug when the application/control fails to load.
- fuslogvw
- IIS logs
- other facilities when these don't cover everything
- warnings about interactions with ASP .NET (i.e. config files not being downloaded)
- describe the warts/pitfalls the author finds in implementing this
In addition the winforms tutorial should cover:
- sharing data between two components on the same page
- A deployment newsgroup on microsoft.public
- Cab files supported as first class components. So that the fusion.dll looks for them and they can contain multiple assemblies. (This is the main reason we needed a config file)
If you want to see a no touch deployment application in action, see my posting: First Commercial .NET No Touch Deployment application