ClickOnce deployment strategy is not viable in some circumstances, such as ones where strict security policy is in place and all applications have to explicitly be given permission to run.

Under ClickOnce deployment method, .NET framework downloads the application files to the current user profile directory and then runs the application from there, making it very hard for the system administrator to define a rule in the security policy to allow the application to run.

A new feature in this release will address this problem by enabling the network administrator to generate a version of VLF.NET that can be launched locally and does not employ ClickOnce deployment technology. It is important to note however that this alternative deployment method does not change the fact that you will still need to have a LANSA web server to serve the content of your framework.

The generated application files can then be manually copied (XCOPY deployment) to a location accessible by end-users, such as a network share. This way of deploying VLF.NET will also come in handy when Citrix environment is used as it means only one copy of VLF.NET needs to be present in the server as opposed to one copy per user if ClickOnce deployment is used.

Below are the steps to produce VLF.NET application files for manual deployment:

1. Deploy the ClickOnce files as normal to the website hosting VLF.NET
   
   
2. Enter in the URL to launch it on the address bar of your browser - make sure to include any additional parameters (such as Partition=xxx) that are required. Add an additional parameter “GenerateDesktopApp=Y”. This parameter is the key to the files generation as instead of running the framework, VLF.NET will generate the application files. It will also write out a configuration file containing all the parameters that you specified in the query string.
   
   
3. When completed, VLF.NET will open the folder containing the generated files in Windows Explorer. Those are the files you (or the network administrator) need to manually deploy. Once deployed, the administrator needs to identify the main executable file (it’s the executable file outside the Content subfolder – do not do anything to the files inside the Content subfolder) and do these steps:
   
   
   1. Modify the Windows security policy to allow the executable file to run.
   2. Modify the .NET security policy to grant Full Trust to the executable. This is especially important when the files are in a network share as by default they will be treated as partially trusted.
   3. Optional - create a shortcut to the executable file for the convenience of the end-users.
      
      

Configuration File

Since the application is going to be launched locally, there is no notion of a URL and query string. To allow you to specify parameters when launching VLF.NET locally, a configuration file is employed as a means to specify these parameters. The name of the configuration file is the same as the name of the executable file but ends with .config extension. If you rename the executable file, make sure to rename the configuration file as well to match the executable file.

When you generate the application files (by specifying the parameter GenerateDesktopApp=Y) a default configuration file will be generated for you based on the parameters that you specified in the query string of the URL at the time of generation. If later you need to change the values of the parameters, open the configuration in a text editor (such as notepad) and carefully change the values of the parameters.