Below are several features of the Web Installer that uniquely separates it from others:

• Web Installer downloads your service files from your online location (a website, for example) instead of containing all service files in itself, installing the latest version of your Windows service every time a user runs it.
• If the "famous" corruption of the GAC reference counts happens, it becomes a challenge for the users of your Windows service to uninstall it. At the very least, they must obtain the same version of the .msi installer they used to install your service and attempt to repair the installation. When this fails, users often try to manually clean up Windows registry or run the Windows Installer CleanUp Utility, often corrupting the entire system. The Web Installer, on the other hand, only creates several standard Windows registry keys that are necessary to register a Windows service.
• You can easily add custom fields to your installer and require input from the end user during service installation.
• Web Installer builds a small (about 440KB) .exe file that is easy to store, move and distribute. No more need to include a bootstrapper file to your .msi "package" and explain to the end users why they need it.
• The .msi installer often depends on a particular version of Windows Installer. The Web Installer does not use the Windows Installer at all.
• Advanced web-based UI of the Web Installer eliminates the need to develop and test a separate installer project for your service, helping to lower your budget and cut development time.

The Web Installer installs your Windows service files by downloading them from your online location over HTTP (HTTPS) protocol every time the user runs the installer. This lets you deliver files from your latest build, ensuring that users always install the latest version of your Windows service. The URL of each file is compiled into your installer.

The location of your files doesn't have to be public. You can use any server on your home or corporate network as well as any Internet location. Your installer will be able to download and install your service as long as all the files can be accessed by the user, for instance, by typing file URLs into the browser. If you use a private network location, please ignore the yellow "warning" icon that appears next to the file URL field as you customize your installer.

Files don't have to be on the same server. For example, it's perfectly fine if some of them are on YourDomain.com and the rest are on SomeOtherDomain.net.

Note that two of the service files, the main executable .exe and the configuration .config, have dedicated fields on the customization page. The configuration file is optional, of course.

There are two ways to host your files online:

Direct Access: Simply upload your files to an online location. In this case, each file should be accessible directly, like http://YourDomain.com/Folder/File.exe. Please note that some web platforms may restrict certain file types to be served over HTTP if accessed directly. For example, by default the ASP.NET run time prevents IIS from serving the .pdb, .config, as well as some other file types. If you use the Direct Access to host your files and your Windows service does have a .config file, add the .xml extension to its file name on the server. For example, rename your App.config to App.config.xml or MyService.exe.config to MyService.exe.config.xml. The URL that you enter into the configuration file's field would now be http://YourDomain.com/Folder/App.config.xml or http://YourDomain.com/Folder/ MyService.exe.config.xml. The installer will properly recognize this new name of the configuration file during the installation.

Dedicated Page: Code a single web page or other HTTP handler that would serve all your files by looking at the query string of its URL. In this case, file URLs would look similar to this: http://YourDomain.com/Page.aspx?token=file. Please download our test ASP.NET web application project that provides the code of such a page. You can build this project and deploy it to your IIS as a stand-alone website to begin hosting your files right away - no strings attached. Just add your files to the /Files/ folder and register them in /Files.config file or use it as a basis for your own solution. This allows you to host any types of files on your IIS for any purpose. Of course, all other modern web platforms have similar file serving capabilities built in. If you are new to web development, search the Net for code samples.

Use our Support page if you have any additional questions about online file hosting.

The Web Installer allows you to include custom fields to your installer's UI. There are five types of fields that you can work with: email address, URL, password, plain string and a check box. You can specify if the field should be required and if it is, provide your own validation message.

The best way to see custom fields in action is to add several of them to a Demo Installer and test it. You can add as many custom fields to your installer as you want. Just remember that each new field adds about 60 pixels to the overall height of your installer's main form. Depending on users' screen resolutions, too many fields may prevent your users from viewing or even working with your installer correctly. In general, you should always assume that your user's screen resolution will be 800 x 600 pixels.

The VS 2008 project of our demo Windows service contains the code that uses values of custom fields (see the Demo's Worker.cs file).

In general, if your installer contains custom fields, the Settings.config file is created and placed in the current execution directory of your service (System.Environment. CurrentDirectory) during installation. Build a Demo Installer with some test custom fields, install it on your machine and look for this file in the Demo's installation folder. It's a plain XML document that contains fields and their values entered by the user during installation. .NET provides many ways to load and manipulate XML documents. Again, the Demo project has a sample of how to do exactly that.

There are a myriad of third party software available - ranging from free to extremely expensive - that can install and uninstall anything over the wire.

No. One of the purposes of the Web Installer is to generate installers that would not interfere with Windows. Therefore, we intentionally designed it to be as "stealthy" as possible for a Windows service without being treated as a spy- or bloatware by security programs.

Instruct your users to use the Web Installer every time they need to install, repair or uninstall your service.

Another advantage of the Web Installer is that users do not need to keep the same version of the installer they used to install your service (as with many .msi installers). We will notify you if a new version of the Web Installer is released. You can build your installer with that new version and provide it to your users. They will still be able to fix or uninstall your service with the latest version of the installer.

The resulting installer of your Windows service that you build with the Web Installer should work properly on Windows 7, requesting the UAC elevation when a user runs it. Windows 7 will correctly show the "famous" UAC dialog. Because of the way the UAC was implemented in Windows Vista (Windows Server 2008), the same installer may require users to disable the UAC entirely before attempting to install your Windows service. The user can enable it again after the installation is finished. This is not a specific Web Installer issue. Many of the currently available software titles also encounter this problem with Vista.

The installer that you built with the Web Installer is a "combination" of your code and ours. Although, by definition the Web Installer cannot sign a mixed code, you can try to sign the resulting installer yourself, as if you would with any of your other code. Please read the Introduction to Code Signing article on MSDN to get started.

Even though we do not support non-.NET services, we don't see any reason why it would not work. Users of your service will still need .NET 3.5 installed on their machines, though.

Having said that, Irina Projects, LLC and its staff make no guarantee and hold no responsibility for any damage, loss of data or property, loss of any and all resources, or any negative influence what-so-ever that may result from the usage of the Web Installer.

It would be a good idea to contact us first before building such an installer.

The icon must be an .ico file. Even though the plain favicon.ico that you'd use on a website would work just fine (try http://codeeffects.com/favicon.ico when building the Demo Installer), we strongly recommend you to spend some time and create a real Windows icon. There are plenty of icon creation software available. Please refer to their documentation on how to create one. It's not difficult and usually free or very inexpensive. If omitted, the default icon will be used.

Allowed formats for the optional "side" logo image are JPEG, BMP and GIF. The image should be 63 pixels wide and 200 pixels high. If omitted, the default image will be used.

It's a good idea to test your icon and logo by including them in a Demo Installer before you use them in a real installer.

Unlike service files, optional icon and logo image will be downloaded and compiled into your installer. Therefore, it will use the original icon or logo image and will not see any updates to these files in their initial locations. If specified, URLs of these files must point to a publicly accessible HTTP or HTTPS location, no private locations (such as corporate or home networks) are allowed.

Initial "pre-alpha" versions of the Web Installer contained capabilities to specify the entire installation path and user account. This, however, brought many more issues for test users than it solved.

Since then, we decided to simplify our service and defaulted to the most common and safest way of installing Windows services. The Web Installer will use the directory returned by .NET 3.5 System.Environment.SpecialFolder.CommonApplicationData property as a basis for installation path, letting you to optionally add your own sub-directories to it. It defaults to the Local System account to run your service.

You should look into building your own installer if your service has more demanding requirements.