Wednesday, March 24, 2004 - Posts
How do I use command line arguments in No-Touch Deployment apps?
In the MSDN Library you will find the following lines:
Note Managed code executables deployed by Internet Explorer using an HREF link should not be started with command line arguments. Arguments are not successfully passed to the executable.
Well, that's just partly true. Chris Sells shows you how.
Note that his solution involves the manipulation of the IIS settings to be able to pass requests to executable files to a self created HTTP handler. You will probably not have the possibility to change the IIS configuration on an external web server.
Additionally one might ask the question why you would need command line parameters in conjunction with No-Touch Deployment applications. In Chris example he wants to remember the user name for the login dialog. In my opinion the usage of Isolated Storage files would be more appropriate in this scenario.
So, if you can tell me why command line support is essential to No-Touch Deployment apps, drop me a comment!
On more information about No-Touch Deployment visit www.dotnet-online.com/notouch/.
Von Jörg Neumann erschienen in dotnetpro 9/2003 auf Seite 70
Um eine Anwendung grafisch zu gestalten, bietet das .NET Framework viele Steuerelemente. Für einige Systemklassen des Windows-API existieren jedoch keine .NET-Gegenstücke. Der Artikel zeigt anhand zweier Klassen, wie man eigene Steuerelemente auf der Grundlage von Systemklassen erstellt und so die Beschränkung überwindet.
Zum Artikel
Von Jörg Neumann erschienen in dotnetpro 10/2003 uf Seite 112
Visual Studio .NET bietet mit den Enterprise Templates eine Erweiterung für die Software-Entwicklung im Team. Sie unterstützen den Entwickler beim Erzeugen von Projekten durch Vorlagen, Richtlinien und Hilfestellungen. Das fördert eine einheitliche Architektur sowie die Qualität und die Produktivität bei der Programmierung. Alles wird leichter. dotnetpro stellt die grundlegenden Konzepte vor und führt in das Erzeugen eigener Vorlagen ein.
Zum Artikel
Von Jörg Neumann erschienen in dotnetpro 12/2003 auf Seite 120
Wichtige Produktionsanlagen werden laufend überwacht. Der Prozessablauf wird protokolliert, und wenn etwas schief geht, blinken rote Lämpchen und Sirenen heulen los. Im Prinzip genau das Gleiche leistet das Enterprise Instrumentation Framework von Microsoft für Software-Systeme. dotnetpro zeigt Ihnen, wie Sie es in Ihre Anwendungen integrieren können.
Zum Artikel
Von Jörg Neumann erschienen in dotnetpro 2/2004 auf Seite 106
Mit dem Help Integration Kit bietet Microsoft einen einfachen Weg das Hilfesystem von Visual Studio .NET um eigene Inhalte zu erweitern. Das ist für Komponentenhersteller interessant und für Teams, die Hilfetexte der eigenen Komponenten in die IDE integrieren möchten. dotnetpro stellt das Toolkit vor und gibt einen Überblick über den neuen Hilfestandard MS Help 2.
Zum Artikel
Von Neno Loje erschienen in dotnetpro 12/2003 auf Seite 93
Wenn Sie Objekte aus einer Assembly, die mit einem starken Namen signiert ist, serialisieren, kann es beim Deserialisieren ein Problem geben. dotnetpro hilft weiter.
Zum Artikel
How do I detect my local application path?
When launched from a Web server .NET applications are copied in the assembly download cache (ADC) of the client machine.
Note: Please be aware that you have no right to read or write within that location by default and need to assign the necessary permissions or FullTrust to the assembly.
When you write a Windows Forms application there are basically four ways how to determine your application path.
- Application.ExecutablePath (Windows.Forms)
- Assembly.CodeBase (Reflection)
- AppDomain.CurrentDomain.BaseDirectory (System)
These three return the URL to the folder on the web server the application was launched from. And finally...
- Assembly.Location (Reflection)
... returns the local path in the assembly download cache (assuming the necessary permissions).
On more information about No-Touch Deployment visit www.dotnet-online.com/notouch/.
How do I know if my application has been launched from a Web server?
You just need to check if the codebase of your assembly starts with "http" or "https".
using System.Reflection;
...
string codeBase = Assembly.GetExecutingAssembly().CodeBase;
if (codeBase.StartsWith("http") ||
codeBase.StartsWith("https"))
{
// app was launched via URL
}
On more information about No-Touch Deployment visit www.dotnet-online.com/notouch/.
How do I use app.config files with No-Touch Deployment?
All Windows Forms application can store there settings in a configuration file which has to be named like the executable followed by the extension ".config" (e.g. MyApp.exe.config, if the executable's name is MyApp.exe). When running an application from a webserver the configuration file is also a URL and gets automatically downloaded with the application.
Many developers complain that this does not seem to work. Here's the solution. The IIS forwards requests to .config files to the ASP.NET runtime which denied the access by default, because .config-files in many cases include sensitive information. You can prove the behavior by entering the URL to the config file in Internet Explorer. It should show up a page telling you that the access is denied. So what can you do?
Solution 1: You configure your web site in IIS to not forward requests to ".config"-files to ASP.NET. IIS would then return them directly as static text if they are requested. Important: When you turn off application configuration mapping, you open a security hole. And that is not the only problem with this solution, because it requires that you have control over the IIS configuration. If you don't, for example if you use an external web hoster, you have a problem. And here comes:
Solution 2: You tell ASP.NET to serve ".config"-Files if they are requested. Check your app.config that it does not contain any sensitive stuff. Please consider that this also allows access to the web.config files used in ASP.NET web applications and web services. Now to make ASP.NET do what you want it to do you need a web.config file in the root of your application that should look like this:
<?
xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<httpHandlers>
<remove verb="*" path="*.config" />
<add verb="*" path="web.config" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
</system.web>
</configuration>
Note: In both scenarios annonymous access has to be enabled in IIS!
You can check if your settings work by requesting the configuration file in your browser. Enjoy!
On more information about No-Touch Deployment visit www.dotnet-online.com/notouch/.
How to debug No-Touch Deployment applications?
No-Touch Deployment applications run in the IEExec.exe process, which is the reason why you cannot see the applications in Task Manager.
To debug your application you have to run the IEExec.exe instead of your application
In Visual Studio, change the Debug Mode in the project properties (under Configuration Properties|Debugging) to program and enter the IEExec.exe as Start Application. The IEExec.exe is located in your .NET Framework directory. On Windows 2000, XP this is %WINDIR%\Microsoft.NET\Framework\v1.1.4322. IEExec.exe requires the full qualified URL to your application as command line argument. For Example: IEExec.exe http://MyServer/MyApp/MyApp.Exe.
For those of you still having trouble debugging make sure to read Mark Levison's tips.
Note for .NET Framework 1.0 SP2 users only:
The IEExec.exe provided by .NET Framework 1.0 SP2 requires a second argument representing the flags and allows an optional third and fourth parameter.
Usage: ieexec.exe url flags [securityZone] [domainId]
url Assembly to launch, e.g. http://localhost/foo.exe
flags Flags to control execution. Values that can be added together are:
0: no flags
1: create evidence for the zone
2: create evidence for the site
securityZone If evidenceFlags != 0, sets the security zone.
Values can be {0, 1, 2, 3} for {MyComputer, Intranet, Trusted, Internet}
domainId If evidenceFlags != 0, unused hex-encoded bytes. Use 00.
Still trouble debugging? Drop me a comment.
On more information about No-Touch Deployment visit www.dotnet-online.com/notouch/.
No-Touch Deployment is a very young technology and far away from being perfect. Prior to start using it you should be aware of the limiations associated with it.
Advantages
- Easy deployment / Low TCO
No need to create setup or update packages.
- Automatic Updates
Clients will be updated as they run the application the next time.
- On-Demand Downloads
In multi-assembly apps, assemblies are downloaded when used.
- Secure
By default, applications cannot harm your machine.
Disadvantages
- No offline support
The Web server needs to be online to be able to run the application.
- No desktop integration
The user has to manually create an icon or internet shortcut to your URL.
- No file handler registrations
You cannot register any file handlers on the machine.
- No GAC installations
You cannot place assemblies in the global assembly cache (GAC).
- No entry in Add/Remove
The user will not see your application in Add/Remove Programs in the Control Panel.
Still questions? Drop me a comment.
On more information about No-Touch Deployment visit www.dotnet-online.com/notouch/.
There was a time, where No-Touch Deployment was very young and not well known. At that time may people invented many names for just the same thing. Here is a list of synonyms I found on my journey collecting information on the topic:
- No Touch Deployment
- No Impact Deployment
- Zero Touch Deployment
- Zero Impact Deployment
- Auto-Download Deployment
- Web Deployment
- „URL launched applications“
- HREF Exe [thanks to Chris Kinsman]
If you happen to find another one, please drop me a comment.
On more information about No-Touch Deployment visit www.dotnet-online.com/notouch/.
Why should I use No-Touch Deployment since there is ASP.NET?
There is a bunch of reasons why you would choose a Windows Forms application rather than a web application. However if you need to create an OS-independent software you will have to stick to ASP.NET.
ASP.NET is great and it will get even better in future versions, but it also has it limits. With ASP.NET the client is the Browser and Browser are “stupid”, because they just display what is described in a meta language – such as HTML. As a developer you have to ability to do client processing using a script language like Jscript which is unmanaged – and therefore potentially unsafe as you can see from the amount of security updates released.
When you need cutting-edge performance, want to use of the local resources efficiently (e.g. DirectX), want to integrate with local applications / APIs a “rich” GUI with a high responsiveness (no postbacks to the server), ASP.NET is simple the wrong choice.
And if you decide to create a Windows Forms application it should not fail due to the complex deployment such applications typically involve. This is exactly the vision of No-Touch Deployment: Deploy your Windows Forms applications as simple as Web applications.
On more information about No-Touch Deployment visit www.dotnet-online.com/notouch/.
What is No-Touch Deployment?
No-Touch Deployment (short: NTD) is Microsoft's first attempt to create a Windows Forms deployment model with similar characteristics to the deployment of toda