How can I have the same application for different clients on the same server.

Both will use the same exe (easyprod.exe) but in different folders due to different settings.

E.g.

Customer 1 localhost\easylabweb

Customer 2 localhost\easylabweb1

Customer 3 localhost\easylaweb2 etc,

I even managed to create the other domain in IIS etc, but the problem is to register the same Exe name. How should I proceed?

Thanks!

You need 2 different projects, each having its own GUID and server name to deploy and register the COM objects in 2 different folders.

I figured it could be that! I thought it would have some other way.

It worked perfectly, each client running the website folder and the executable, however, when I run the command below. Easyprod1 and easyprod2 are going to localhost/easyprod. What do I have to change?

	thisform.wUserLogOff()
	wBackHome() 

I fixed. l only changed the path in XXXprod.ini in the virtual property. Worked perfectly. Thank you!

right, glad you could figure out the fix

The only thing that didn't work was that when I stop IIS, easyprod1.exe and easyprod2.exe are not closed, only easyprod.exe is closed properly. What else do I need to configure?

strange… check your COM server definition in each wc.ini

Follow below, my wc.ini.

; .INI FILE FOR WC.DLL
; ==========================

; wc.dll reads this file once at startup, and each time you press the
; 'Update DLL INI File' button in the 'Editing Config Files' form
; (admin.asp > 'Edit configuration files' .../wc.dll?wwMaint~EditConfig)

; Comments in this file originate partly from web connect documentation,
; partly from FoxInCloud to ease server setup. You obviously can delete or
; simplify these comments when your application goes into production.

; wConnect documentation about this file is titled "The wc.ini configuration file"

; Everywhere in this file, you need to replace 'easy' by your application 
; code as explained in the FoxInCloud documentation:
; http://foxincloud.com/How-to.php?HowTo=awServerDev

; easyProd.exe means either the Test or Production version of 
; your FoxInCloud Server.

; 'Test' and 'Development' are 2 different concepts for FoxInCloud:
; you should have a Test server in your production environment to test
; changes in your application before putting them into production for real users.

[wwcgi]

; ==================================
; BASE DEVELOPMENT SETTINGS
; ==================================

Path=C:\Users\Public\FoxInCloudTemp\easy\
; Full path to wConnect Temp files directory.
; REQUIRED
; wc.dll needs to write into this directory:
; - requests files when running with 'Mechanism=File' (see below),
; - its error log (file 'wcErrors.txt')
; As wc.dll may run under various NT accounts depending on how you setup
; wc.dll application in your site/virtual directory configuration,
; it is advisable to give the widest rights to most users on this dir.
; Typically, on a development machine, giving 'full control' to 'all users'
; on 'c:\Temp\' is a common practice.
; Rights should be further refined on a production machine.
; MUST MATCH 'Tempfilepath=' in your FoxInCloud Server configuration file.

Timeout=400
; Delay in seconds to allow a request to finish.
; REQUIRED
; wc.dll aborts request after this number of seconds elapses
; Set to the longest possible request in your application
; If you have very long requests (batch printing, archiving, etc.),
; consider building an asynchronous process.
; Keep in mind that, the longer the timeout, the longer the server
; will appear busy to other users; in production, you can overcome
; this by launching several COM servers (see 'Mechanism' and 
; [Automation Servers] below)
; Recommended values:
; - developement: 600
; - production: 5-20


AdminPage=/easyProd1/admin/admin.asp
; Admin Page used for Backlinks from pages generated by wc.dll
; Indicate a full server relative WEB path (starting with '/')

; ===================================
; OPTIONAL DEVELOPMENT SETTINGS
; ===================================

Template=wc_
; Message File Template (1st 3 letters), default is 'wc_'
; REQUIRED FOR 'Mechanism=File'
; Only needed if you intend to use a different template
; MUST MATCH 'Template' in your FoxInCloud Server configuration file.

PollTime=100
; Delay in milliseconds for wc.dll to poll the 'Path=' directory 
; for 'completion' messages from the FoxInCloud Server
; REQUIRED AND USED ONLY FOR 'Mechanism=File'
; This setting is ignored with 'Mechanism=Automation' above,
; thus saving response time in this mode.  

PostMethod=UrlEncoded
; Value: URLEncoded or INI
; FoxInCloud recommends keeping URLEncoded
; Must match POSTMETHOD in wconnect.h / wconnect_override.h

FileStartInstances=0
; FoxInCloud makes no use of this setting.

Impersonation=0
; Determines under which user context wc.dll executes internal ISAPI requests
; 0 (default, recommended for FoxInCloud) 
; No impersonation: wc.dll runs under the underlying IIS account (SYSTEM or NETWORK SERVICE),
; or user defined for Application Pool to which wc.dll belongs.
; 1
; wc.dll uses user impersonation and runs under the account that is currently logged in.
; This means IUSR_ for anonymous requests or the specific user if Basic or Windows Authentication is applied against the request.

; =========================================================
; PRODUCTION SETTINGS (Full licensed developers only) 
; =========================================================

Mechanism=Automation
; Indicates how wc.dll communicates with FoxInCloud/wConnect Server.
; REQUIRED
; File
; ----
; This is the original Web Connection file based messaging:
; both wc.dll and the FoxInCloud Server poll the above 'Path=' directory 
; for Request and Response files.
; In order for this mode to operate, your FoxInCloud Server
; must 'listen to requests', IOW run in any of the following way:
; - by typing in FoxInCloud Studio IDE
; DO easyProd.prg
; - by:
; . compiling your easyProd.pjx into easyProd.exe
; . running easyProd.exe from Windows (double click on explorer) 
; Can be set by http://.../wc.wc?_maintain~SetFileMechanism
; This mode can only be used in the development phase as your production
; FoxInCloud Server requires 'Mechanism=Automation' described hereafter.
; Automation
; ----------
; Use OLE Automation Server Interface
; In this mode, wc.dll instantiates the COM server(s) indicated in the
; [Automation Servers] section below, and exchanges Request and Response
; messages through a synchronous method call / RETURN through COM.
; Can be set by http://.../wc.wc?_maintain~SetAutoMechanism
; This mode is required in a FoxInCloud production environment. 
; Interactive
; -----------
; Call up the VFP development environment via Automation.
; FoxInCloud makes no use of this setting.

AdminAccount=
; Account for admin tasks such as 'http://.../wc.wc?_maintain~*' or 'http://.../wc.wc?wwMaint~*'
; Possible values:
; <Empty>
; no Authentication; recommended in development, 
; strongly discouraged in Production
; NT User Account(s)
; example: user1,user2,user3
; Any of the specified user account(s) must log in
; Case-sensitive with most browsers
; Any
; Any NT user account may log in

ExeFile=
; Full path to your easyProd.exe 
; wc.dll uses this key to:
; - DEVELOPMENT: launch your easyProd.exe in file mode
; (not really useful in development as you can simply double click your .exe in Windows Explorer)
; - PRODUCTION: update your easyProd.exe with a new version specified in the 'UpdateFile' key below. 
; Crucial when using easyProdServerUpdate.prg (derived from awStart.prg!awServerUpload()) to update a your Production FoxInCloud Application Server. 

UpdateFile=
; Full path to the new version of your easyProd.exe
; This path usually points to a secured directory shared on FTP where you upload 
; new versions after full testing in your development environment.
; We encourage developers to use easyProdServerUpdate.prg,
; (derived from awStart.prg!awServerUpload()),
; which fully automates this update process.  

[Automation Servers]
; Settings in this section apply when 'Mechanism' key is set to 'Automation',
; IOW when wc.dll instantiates your FoxInCloud Server as a COM
; object (OLEPUBLIC clause in your application server class definition).

; This is REQUIRED IN PRODUCTION, optional in development though it is 
; strongly advisable to fully test your FoxInCloud Server in COM mode
; on your development machine BEFORE going into production.

; Please note that, as wConnect, FoxInCloud uses plain .exe COM objects
; as opposed to 'COM+' objects obtained by compiling project into a .dll 

Server1=easyProd1.easyProd1Server
Server2=easyProd1.easyProd1Server


; Name of the COM servers generated when compiling your project into a .exe
; The naming scheme above is FoxInCloud standard; you may check the actual
; name in your project's information panel (Project > Project Info.. Ctrl+J),
; 'Server' tab, 'Description' field.
; The NT user account under which wc.dll runs must have the right to 
; instantiate this COM object; you can check this with DCOM configuration
; utility (DCOMcnfg.exe); please check out West-Wind Web Connect documentation
; for more information.

; Server4=easyProd.easyProdServer,RemoteServer
; This is an alternative syntax where COM object may be instantiated on a 
; different machine named 'remoteServer'.

; West-Wind recommends a maximum of 2 COM servers per available CPU  

ServerLoading=0
; When wc.dll instantiates several COM servers,
; determines how requests cycle through the servers.
; 0 - Load Based
; Server only gets called when the previous one is busy.
; Typically the first server is worked heaviest and the last server the least.
; FOXINCLOUD RECOMMENDS THIS VALUE as FoxInCloud Server skips restoring
; form state when the same user issues successive requests on the same server.
; 1 - Round Robin
; Request always cycle through servers sequentially.
; All servers are loaded equally.

KeepAlive=1
; This flag allows getting around a DCOM bug that causes COM objects
; loaded by IIS threads to unload after 8 minutes of idle time. 
; 0 - Normal
; Servers can unload. Use this if your servers are lightly loaded
; and run with short requests and you want the system to unload
; these servers to preserve resources.
; 1 - Keep Alive
; Keeps an extra COM reference to force servers to stay alive at all times.
; Servers unload only when IIS unloads or when you use
; Web Connection's own unload links.
; FOXINCLOUD RECOMMENDS THIS VALUE OF 1.

[Extra Server Variables]
; Use this section to add additional HTTP Server variables that IIS provides to your incoming Request object.
; Though Web Connection provides the most common variables,
; this option allows you to retrieve any additional Web Server variables that aren't natively provided.
; To find out the server variables that IIS exposes, see MSDN online.
; Use Var1, Var2, Var3 etc. keys to specify each of the server vars to add as in the following examples:
; Var1=LOCAL_ADDR
; Var2=APPL_MD_PATH
 
[HTML PAGES]
; Use these to override DLL messages
; Full Path required
; A future version of FoxInCloud will provide branded pages here. 
TimeOut=
Busy=
NoOutput=
OleError=
Maintainance=
Maintainence=
Exception=
Execption=
NoLoad=

Looks OK; to better understand how it works:

• IIS application pool (AP) runs each application's script-mapped wc.dll
• wc.dll instantiates the COM server indicated by wc.ini
• when IIS AP stops, wc.dll unloads COM server before stopping

Well, other than that. The rest worked perfectly. Is it okay for me to create a script to eliminate these exes when necessary?

It's a matter of preference… I would rather try to understand what starts this undesired exe…

FWIW, if your admin page is protected, …/admin.asp?ProcessList=true lets you kill the undesired process(es):