Sunday, February 15, 2009
WPF and No Touch Deployments
I tried creating a simple WPF application and running it as a click-once/no-touch deployment application, but could not. It seems WPF does not support no-touch deployments.
Sunday, February 8, 2009
Supporting web service calls within a no touch deployment application.
What is no touch deployment?
A no touch deployment application exists in a directory underneath IIS’ wwwroot, and is called via an URL and run in the context of the caller’s machine. The advantage of no touch deployment applications is that they do not have to be installed on every user’s PC; a single desktop client application can be deployed to a local intranet server for multiple users yet be easily maintained and updated like a web application. This is ideal in many ways as it allows a development team to deploy rich thick client functionality to the masses without requiring the burden of a large IT rollout project.
Problem:
No touch deployment applications use the .NET framework’s configuration system differently than regular desktop applications. Since the application is served via IIS, IIS determines which configuration file to associate with the application. This is done by appending the “.config” extension to the end of the calling URL and sending that file back to the user’s machine. For example, if the user called the application with the URL http://intranetserver/myapp.exe, IIS would send the configuration file on this URL: http://intranetserver/myapp.exe.config.
This isn’t a problem as this configuration URL is a valid URL, but what happens if the no touch deployment application is called with arguments? For example, what if the user called the application with the URL http://intranetserver/myapp.exe?silent=true. Provided with this URL then IIS would construct the following URL for the configuration file: http://intranetserver/myapp.exe?silent=true.config.
If you don’t believe me create a no-touch deployment application that uses the System.Configuration namespace. It will fail. Then create a no-touch deployment application that will accept query string arguments and call a web service. Proceed to call it via the URL. It will also fail.
However, this can be easily resolved by creating a custom configuration handler and configuring it within IIS. The drawback is that part of this configuration involves allowing anonymous access to the no touch deployment application. In a secure IT environment, this is not allowed. The broadcast industry is one of those that is closely regulated by the government, and thus most broadcasting corporations have lots of IT security regulations enforced upon them.
So the problem really is, how do you override the default configuration system in the no-touch deployment application so you can call web services within it without allowing anonymous users access?
Solution:
The solution is still relatively simple. Strip off the query string (?silent=true) from the URL and set the APP_LAUNCH_URL variable of the application’s current domain (AppDomain.CurrentDomain) to the trimmed URL. Then construct the configuration URL using this URL so it is now http://intranetserver/myapp.exe.config and set the APP_CONFIG_FILE variable of AppDomain.CurrentDomain to this value. This can be done using AppDomain.CurrentDomain.SetData(“APP_LAUNCH_URL”, newURL) etc…
Broadcast No Touch Deployment Handler
Description:
This abstract class provides the basic functionality required to have a functioning no touch deployment application in a secure IT environment. The constructor will have the URL processing features required to avoid the configuration system problems a no-touch deployment application experiences in a secure IT environment, and there is an abstract method to implement that processes query string arguments.
Functional How-To:
Just create your own implementation of this abstract class in your application and implement the process query string method yourself. Then instantiate an instance of this class at the beginning of your application, preferably near the top of your Main() function in the Program.cs file.
When to use it:
In the broadcasting technology environment, there are strict controls on who can access what, as well as the number of executables that can exist in a production environment. In one particular case, to drive a process, a no touch deployment executable had to double as a thick client as well as a web service client called by a scheduled task. Since in both cases the application would be called via an URL, the way to distinguish when to start it as a thick client and when to start it as a silent web service client was via arguments sent via an URL query string. Since the IT environment did not support anonymous access, we could not build a custom configuration handler for IIS. At first we tried to disable calls to the .NET framework configuration system, but soon found out that the SoapHttpClientProtocol and WebRequest classes of the System.Net namespace all initialized the configuration system by default. After much experimentation, I found this approach to be the best.
Examples:
I implemented an example on http://www.codeplex.com/tv/. Just run TestNTD2.exe from an URL (http://localhost/TestNTD2.exe?arg=silent) to see it work.
The requirements to make the example work are:
IIS 6.0 configured for Windows authentication.
.NET Framework 3.5.
A no touch deployment application exists in a directory underneath IIS’ wwwroot, and is called via an URL and run in the context of the caller’s machine. The advantage of no touch deployment applications is that they do not have to be installed on every user’s PC; a single desktop client application can be deployed to a local intranet server for multiple users yet be easily maintained and updated like a web application. This is ideal in many ways as it allows a development team to deploy rich thick client functionality to the masses without requiring the burden of a large IT rollout project.
Problem:
No touch deployment applications use the .NET framework’s configuration system differently than regular desktop applications. Since the application is served via IIS, IIS determines which configuration file to associate with the application. This is done by appending the “.config” extension to the end of the calling URL and sending that file back to the user’s machine. For example, if the user called the application with the URL http://intranetserver/myapp.exe, IIS would send the configuration file on this URL: http://intranetserver/myapp.exe.config.
This isn’t a problem as this configuration URL is a valid URL, but what happens if the no touch deployment application is called with arguments? For example, what if the user called the application with the URL http://intranetserver/myapp.exe?silent=true. Provided with this URL then IIS would construct the following URL for the configuration file: http://intranetserver/myapp.exe?silent=true.config.
If you don’t believe me create a no-touch deployment application that uses the System.Configuration namespace. It will fail. Then create a no-touch deployment application that will accept query string arguments and call a web service. Proceed to call it via the URL. It will also fail.
However, this can be easily resolved by creating a custom configuration handler and configuring it within IIS. The drawback is that part of this configuration involves allowing anonymous access to the no touch deployment application. In a secure IT environment, this is not allowed. The broadcast industry is one of those that is closely regulated by the government, and thus most broadcasting corporations have lots of IT security regulations enforced upon them.
So the problem really is, how do you override the default configuration system in the no-touch deployment application so you can call web services within it without allowing anonymous users access?
Solution:
The solution is still relatively simple. Strip off the query string (?silent=true) from the URL and set the APP_LAUNCH_URL variable of the application’s current domain (AppDomain.CurrentDomain) to the trimmed URL. Then construct the configuration URL using this URL so it is now http://intranetserver/myapp.exe.config and set the APP_CONFIG_FILE variable of AppDomain.CurrentDomain to this value. This can be done using AppDomain.CurrentDomain.SetData(“APP_LAUNCH_URL”, newURL) etc…
Broadcast No Touch Deployment Handler
Description:
This abstract class provides the basic functionality required to have a functioning no touch deployment application in a secure IT environment. The constructor will have the URL processing features required to avoid the configuration system problems a no-touch deployment application experiences in a secure IT environment, and there is an abstract method to implement that processes query string arguments.
Functional How-To:
Just create your own implementation of this abstract class in your application and implement the process query string method yourself. Then instantiate an instance of this class at the beginning of your application, preferably near the top of your Main() function in the Program.cs file.
When to use it:
In the broadcasting technology environment, there are strict controls on who can access what, as well as the number of executables that can exist in a production environment. In one particular case, to drive a process, a no touch deployment executable had to double as a thick client as well as a web service client called by a scheduled task. Since in both cases the application would be called via an URL, the way to distinguish when to start it as a thick client and when to start it as a silent web service client was via arguments sent via an URL query string. Since the IT environment did not support anonymous access, we could not build a custom configuration handler for IIS. At first we tried to disable calls to the .NET framework configuration system, but soon found out that the SoapHttpClientProtocol and WebRequest classes of the System.Net namespace all initialized the configuration system by default. After much experimentation, I found this approach to be the best.
Examples:
I implemented an example on http://www.codeplex.com/tv/. Just run TestNTD2.exe from an URL (http://localhost/TestNTD2.exe?arg=silent) to see it work.
The requirements to make the example work are:
IIS 6.0 configured for Windows authentication.
.NET Framework 3.5.
Subscribe to:
Posts (Atom)
Posts
