i want each instance of my vfp app to create and use it's own temp folder 1

[cfsjohn]

I've chased my tail on this one for days. I need an expert.

I am modifying my vfp app to run from RDP. I am trying to cover every conceivable temp files issue meaning I want to simply not worry about 2 instances of my app using the same temp folder. My users can run multiple instances of my app simultaneously. To make a long story short, I am thinking...when my app starts up, if it could create a unique temp folder and then use that temp folder, there is no way there could be any issues with overlapping temp files. My app is run from a desktop icon with the -Cc:\<home dir>\config.itf (itf is the name of my app). The contents of config.itf is:
TMPFILES=.\temp\itf

The above gets me to where my app is storing temp files in a folder under the app's home named temp\itf

Basically I want to have each instance of the app create a subfolder under <home dir>\temp\itf
So if there were 3 instances of my app running there would be:
<home dir>\temp\itf\instance1
<home dir>\temp\itf\instance2
<home dir>\temp\itf\instance3

I have gotten this far:
modify the config file to run a separate prg named createthisinstancestempfolder.fxp
The contents of createthisinstancestempfolder.prg is:
lcdirtocreate=SYS(2015)
MKDIR (lcdirtocreate)

Modify config.itf to be as follows:
RUN do createthisinstancestempfolder

So in the config file I am telling VFP to run my program that gets a unique name and creates the temp folder. That works.

But, now I need to HAVE that folder name so the next line in the config file can be:
TMPFILES=<the name of the temp folder I just created>

I can't see a way to do that.

Thanks for your thoughts,
John

 

[Scott24x7]

John,
A few things:
First, when you create the TEMP directory (unique name) you should give it the fully qualified path.

So:
lcdirtocreate = ADDBS(SYS(2023))+ADDBS(SYS(2015))

MCDIR(lcdirtocreate)

Next thing you need to do is assign that value to something you can use. If you have something like a USERTABLE (which you use at login verification time, so this would be AFTER the user logs in you create their TEMP area), then do something like
<find the users record>

USE USERTABLE
<find the user>
REPLACE USERTABLE.TEMPDIR with EVALUATE(lcdirtocreate)

Then from then on you can access that table with the users <reference> (I assume you have a way to track the logged in user), so just make calls to that tables value when you need to set its useage.
If you have a goAPP application object (or similar) you can assign it there too, which will persist only for that users instance, so it won't collide when you have multiple instances of the application running.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

In Remote Desktop, every user session has a separate temp dir, so just using %TEMP% (GETENV("TEMP")) will work, which should be your default anyway. I know this because I had to adjust applications using a hardwired folder on D:\apptemp, which of course worked for local drives of each single user before going RDP.

If you have some files, which are more permanently expected despite being stored in a "temp" folder, you have to cover users getting different sessions perhaps even on different terminal servers, which means storing this temp data somewhere along with other permanent backend data.

But in the simplest case, just programming for the usual temp dir would make this a piece of cake. This also shows programming by standards and not against them is to be considered the norm. MS has solved the problem from the outset by providing session specific temp folders, but that only helps you, if you make use of the system temp dir.

Using VFPs TMPFILES config.fpw setting should be obsoleted. You don't have VFP running on Mac and UNIX, which would justify such own organized configurations, you live solely on Windows, make use of Windows standards.
By the way, there is a number within the GETENV("TEMP") folder, which is the user session id. There might be places you are interested in that id and reading out GETENV("TEMP") is the easiest way I found to get at that id. One thing this is necessary to know is reading which processes are started within the current user session from a WMI query on all processes, eg for a routine to avoid starting your application twice, but only check that against the current session, now.

Bye, Olaf.

 

[Mike Lewis]

But in the simplest case, just programming for the usual temp dir would make this a piece of cake.

Another advantage of that is that, if for any reason you fail to delete your temporary files when the program exits, the system has various disk cleanup tools that let the user do that themselves. (But of course there's no guarantee that the user will actually do that.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Eugen Fintina]

Hello, friends

My clients said to me that, from time to time, they have got some errors about the concurrent access to data records. It’s a bit difficult to receive detailed information from them, so I conclusioned that error raised because they use RDC for access to the application. Now I realized that I don’t know if they use distinct credentials to access RDC or, all of them, use same credentials (all of them use same user).

For solving this issue, I thought that I must use unique name for cursors that I use in application. In this way, I changed

lcRecordSource = "Select Distinct ... Into Cursor Temp Readwrite"
Thisform.Grid1.RecordSource = lcRecordSource

to

lcMyCursor = Sys(2015) + Alltrim(Str(pnIdUser)) && pnIdUser = Application user’s id
ThisForm.MyCursor = lcMyCursor
lcRecordSource = "Select Distinct ... Into Cursor " + Thisform.MyCursor + " Readwrite"
Thisform.Grid1.RecordSource = lcRecordSource

Reading yours previous post, I understand that Windows uses a different temporary folder for store temporary files for each RDC session. In this way, the error didn't must raise. Now, I’m a bit confused because I don’t understand from where the error raise.
I must specifies that I have for all forms

Set exclusive off
BufferMode Property: 1
DataSession Property: 2

All the best,
Eugen

 

[Olaf Doschke]

Access to cursor indeed can't be a problem, also cursor file names differ from the workarea alias names - jsut look into DBF("cursorname") to eee the .tmp file name. That wold even differ, if all users are in the same temp folder.

Besides, even same user used to connect would cause different temp folders due to different session ids.

Your problem must be about the access of the DBFs you query FROM, not the cursors you query into.

Bye, Olaf.

 

[JRB-Bldr]

My clients said to me that, from time to time, they have got some errors about the concurrent access to data records. It’s a bit difficult to receive detailed information from them, so I conclusioned that error raised because they use RDC for access to the application.

Now, I’m a bit confused because I don’t understand from where the error raise.

I am also confused. This question was originally posted by cfsjohn

Are you providing an answer to their question or are you posting a new one of your own?

Yes, there is some similarity in that you both have users access your VFP application via RDP.
BUT, if your question is a new one, then you need to post it into a separate thread so that it can be answered separately and not 'jump onto' and existing question.

Good Luck,
JRB-Bldr

 

[Tore Bleken]

I have read your message over and over, and I have one important question: Why? If you have a problem with sharing a temp folder, you should spend some time fixing this problem, and not try to "add band aid". Using a shared temp folder shouldn't be any problem, unless you use temp file names which "collide". If that's the situation, please provide the code you use to generate temp file names.

 

[Mike Lewis]

You might also provide some indication of what exactly went wrong: what error message the users saw (if any), or what unexpected behaviour occurred.

If you don't have that information, maybe installing a proper error-handler would be a good idea.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[cfsjohn]

Hi ALL,

I have been (for several hours now) re-writing my initial question. I have decided to tell you the WHOLE issue rather than the simpler question I had asked. While doing this re-write, I see additional replies to my question. I want to answer tbleken first because his response makes me wonder about something I am "assuming".

I am assuming that each instance of my app needs a separate temp folder. I do not generate any temp filenames for temp files in my code. As far as I know the only temp files generated while my app is running are generated by VFP. Having said that, my app is written using the Visual FoxExpress framework and I can not assume the framework isn't generating any filenames for temp files but I believe it would be safe to say they do not.

My app IS multi user. I can have 100 users running the app simultaneously and updating the same tables.

I guess it comes down to this. tbleken, are you telling me that if 100 users are accessing my app and if they were all using the same temp folder that VFP temp filenames are unique enough that I do not need to worry about any crashes due to 2 users generating the same temp file names?

If that is what you are saying then Yes I am worrying about nothing but I seriously doubt that is true.

I am going to continue re-writing my original question and will post ASAP but will await tbleken's reply.

Thanks,
John

 

[Olaf Doschke]

Indeed, the only real temp files VFP writes are for cursors and they aren't alias names of workareas, they are quite like SYS(2015) unique on their own, still MS Windows has good reasons to provide a dynamic %TEMP% variable value per user session of remote desktop, to avoid general problems, even if an application does generate temp file names not unique to several user sessions normally running each on their own desktop client and with their own local drive %TEMP% folder, which then does not need to be dynamic.

Worrying about temp folder file name collisions indeed is the wrong thing to worry about, look at this:

FOR lnCount = 1 TO 10
    CREATE CURSOR crsTest ( sajsldjkf F)
    ? DBF("crsTest")
ENDFOR

Even though creating the same cursor alias over and over again means only one crsTest will exist at each time and its file name could be reused, VFP just generates a new name for each CREATE CURSOR.

It's unclear whether FoxExpress creates further temp files without looking deep into its code, but this is a framework from the Feltmans and employees, they know what they do. If they would generate any temp files in GETENV("TEMP") they would most probably make use of SYS(2015) and anyway, as there is a different folder per user session, you don't get any problems with temp files of cursors or files you create in GETENV("TEMP"), only problems, that would also show up on a single desktop with a single user. The only chance of unwanted collisions are about using TMPWORK as one configuration setting for all. That's where I go back to my earlier statement of making such configuration options obsolete and go with what the OS system offers, there is no good deed in defining an own temp work folder, nor progwork nor sortwork.

I agree with what Mike last says, both on providing an example and also on implementing an error handler - in case of FoxExpress making use of its surely available error handling, logging and reporting features and look at errors and their source. For example above code will make clear an error about "alias name is already in use" is not reporting an already used file name, but an already used name of a workarea, these names do not correspond to each other in the general case, which people often only ever learn, when they use cursors, views and more, since using a dbf creates the same alias name as dbf file name by default.

Even just native VFP us not making use of the inverse and does not create file names by default equal to alias names you give to cursors, because MS and the VFP team are aware you could run several datasessions with same alias names, even multiple processes of the same exe, not only on remote desktop and several applications sharing some framework code and thus also reusing alias names. Names on disc do not need to correspond to alias names and thus are also not doing so. The opposite, opening any_table.dbf with a random seeming alias name would make developers reject VFP as a cryptic programming IDE, wouldn't it? But since you only work with the alias name, after that file handling "hurdle" is taken, the inverse operation can make use of random but unique names and thus avoid the problem you fear in the outset, even if VFP was so successful, that every app running on a system would be VFP driven. Just think about that. The developers at Fox software had to think about that aspect very early on and VFP would have been no success, if it was otherwise.

Bye, Olaf.

 

[cfsjohn]

Olaf, You are soooooo thorough and I truly appreciate you reply. I am going to stop rewriting my original question and try this a different way. I am going to ask one simple question at a time and see if you can help me.

First, I understand that using GETENV("TEMP") would seem to be the ultimate solution but I have to tell you some unique things about my app.

My app is run from workstations (yes, like most apps). The executable is local meaning it resides on the workstation. The data is on a server with a shared drive the workstations can "see".

So the workstation has:
c:\ITF and ITF.EXE is in c:\ITF
The server has:
d:\ITF which is shared and the executable is also in d:\ITF.EXE
The data is on the server in d:\ITF\DATA

I use a start program originally written years ago by Doug Henning to run the local ITF.EXE after checking the server for the latest version and copying it to the workstation if necessary. I am sure you are familiar with that concept.

Second thing to explain:

I allow running multiple instances of the app and at the same time do not allow the same instance of the app to run simultaneously.

Let me explain:

Each client (my customer) can have multiple instances of my app. If my app is named ITF, my customer can run ITF-BANK1 and ITF-BANK2 on the same workstation simultaneously. ITF-BANK1 has it's own data and settings. ITF-BANK2 has it's own data and settings. Both are running the same executable. I merely rename them so on the server there is:
d:\ITF-BANK1 that contains ITF-BANK1.EXE
d:\ITF-BANK1\DATA
and
d:\ITF-BANK2 that contains ITF-BANK2.EXE
d:\ITF-BANK2\DATA

Just to be sure I am clear, the workstation is exactly the same as the server except of course there is no DATA folder on the workstations.

My app has code internally that keeps the user from running the same app multiple times simultaneously on the same workstation. They CAN run ITF-BANK1 and ITF-BANK2 simultaneously but they can NOT run ITF-BANK1 or ITF-BANK2 twice simultaneously.

On the server I can do the same as the workstations. I do not use the start program but instead run the executable from it's home directory on the server. I can run ITF-BANK1 and ITF-BANK2 simultaneously on the server and I can not run 2 instances of ITF-BANK1 simultaneously, again, same as the workstations.

Next unique thing about my app:

There are multiple apps running from the same home directory on the server. Let me explain:
In addition to ITF there is a second app that is a program that runs in the background for each ITF. This program is named ITFBACKGROUND. It has no user interface. IT runs 24/7. So using the above as a template, I have an app named ITFBACKGROUND-BANK1.EXE running from the server's d:\ITF-BANK1 folder and accessing ITF-BANK1's data AND I have an app named ITFBACKGROUND-BANK2.EXE running from the server's d:\ITF-BANK2 folder and accessing ITF-BANK2's data.

There are actually 2 more apps just like this, one is my web service and the other runs from windows task scheduler every few minutes and texts me when it detects something like an ITFBACKGROUND executable being down. So each of these apps also run from the ITF-BANK1 and ITF-BANK2 folders and access that ITF's data. They would be named ITFWEBSVCS-BANK1.EXE and ITFTWILLIO-BANK1.EXE and the same for BANK2.

Finally to my question:
Because there are multiple apps running from the app's home directory, many years ago, I implemented the following folder structure for each ITF.
On the server:
d:\ITF-BANK1
d:\ITF-BANK1\DATA
d:\ITF-BANK1\TEMP
d:\ITF-BANK1\TEMP\ITF
d:\ITF-BANK1\TEMP\ITFBACKGROUND
d:\ITF-BANK1\TEMP\ITFWEBSVCS
d:\ITF-BANK1\TEMP\ITFTWILLIO
The same exact structure applies to BANK2.

All that means that, each "app" running from the home directory has it's own temp folder.
The workstations only have the one app running so they have:
c:\ITF-BANK1
c:\ITF-BANK1\TEMP
c:\ITF-BANK1\TEMP\ITF

The config file is named by using the -C command line switch so the workstations look like this:
Target = c:\ITF-BANK1\start.exe -T -Cc:\ITF-BANK1\config.itf
StartIn = c:\ITF-BANK1
The config.itf contains:
TMPFILES=.\TEMP\ITF

I should note there is an ini file that tells start.exe where the data is on the server for this ITF and that tells it the name of the executable to check the version for and to run is ITF-BANK1.EXE

Repeat all that for ITF-BANK2.

The server looks like this:
Target = d:\ITF-BANK1\ITF-BANK1.EXE -T -Cd:\ITF-BANK1\config.itf
StartIn = d:\ITF-BANK1
The config.itf contains:
TMPFILES=.\TEMP\ITF

Repeat all that for ITF-BANK2 and for ITFBACKGROUND, etc.

So, I guess the simplest form of my question would be, now that you know all that, I personally do not believe GETENV("TEMP") works because something like ITF-BANK1 and ITF-BANK2 would be using the same temp folder. I can certainly be wrong and I hope that I am wrong. Am I wrong?

Thank You,
John

 

[Olaf Doschke]

It depends on what files your EXEs generate, but if this only is about the temp files VFP generates naturally, you are wrong. As I said already:

even if VFP was so successful, that every app running on a system would be VFP driven

VFP does not name temp files by alias names, it gives temp files unique names as my demo code shows. Unless YOU don't generate files with hardcoded names in your TEMP folders there is no problem. So if that is the case you will need to apply SYS(2015) at least as partial file name. That could be the case if you query INTO TABLE somename.dbf and the different EXEs create the same file names. If all your EXEs instead query INTO CURSOR crsName, it doesn't matter, whether all EXE processes will create same alias name cursors.

This all speaks for usage of cursors and views etc over creating DBF files on the fly yourself.

If you have a problem between multiple users, already removing the TMPWORK setting will separate files of different users into different temp dirs, without YOU making use of GETENV("TEMP"), VFP does so, when it creates cursor files. VFP takes this system setting into SYS(2023) automatically, you just DON'T set TMPWORK and VFP makes use of the system temp directory/directories automatically.

In regard of files created in your temp folders done by your INTO TABLE or CREATE TABELE or FCREATE or STRTOFILE or other file generating code, you are responsible yourself to use system temp path, also you should know yourself how you name files in there and where you generate them.

Bye, Olaf.

 

[cfsjohn]

Olaf, I do not select into tables. All my apps use views. ITF has 1300 views. The views are in a separate views database. What you are telling me does greatly simplify all of this. I've been writing FoxPro for 30 years and never knew that. I'm going to think about this some more. Than you, John

 

[Olaf Doschke]

Look, if all your simple question have this prologue, we will not get forward fast enough.

It really only will help, if you log errors and know what errors occur in what code. Everything else is theoretical guesswork, that can't cover anything your specific code does.

My experience with customers is, of course, it is not conceived very well if all you can offer is a new version of your software doing advanced tracing and logging for finding out more precise reasons of errors, but it surely is better conceived, than promising bug fixes by having a theoretical idea, even if that is backed up by experts suggestions, if this idea still does not hold true.

An error handler can tell you error number, message, program, and line number of the error and you may save variable states and other side infften enough just knowing the error message and location helps. And if it just helps to know where to add some points of logging states for tracing what happens. As you use a framework, logging might be included, if for example there is a form handler, you can add logging messages before any form starts, which form starts and other more or less neuralgic points and then also correlate that to error logging times. By the nature of error, of course logging certain mile stones goes up to the point just before an error happens. Doing these two types of logging before errors happen in the normal progress of code at certain events combined with logging errors hen they happen, will help to narrow down the analysis from the last log check point everything works as expected to the location of the error.

Bye, Olaf.

 

[cfsjohn]

Olaf,

It is probably natural to assume I am getting errors because I am asking about how to have unique temporary folders. I am not getting any errors. My app DOES log errors. It is built into the framework (and what an awesome framework it is).

I am trying to ensure I have done everything possible to keep from getting any errors when I run my app from a cloud server using RemoteApp. That is my current project.

I would like to use the advice of you and others and use the session's temp folder for temp files, for all the reasons you suggest. I am not convinced it would work.

I would like to concentrate on one scenario with the following being facts:
I never access tables directly.
I always use views and temporary cursors to access data.
I never generate tables from my app.
I never modify tables from my app.
My app has Stonefield tools builtin. Stonefield does all table adds and modifications when I do an upgrade with no users in the system.
I use Stonefield to reindex tables when no users are in the system.
The only files that are generated in the temp folder are files created by VFP using VFP's method for generating unique filenames.

I have multiple iterations of multiple apps on a single machine. Each iteration runs the same executable but the executable is renamed per iteration. Each iteration has it's own home directory, it's own data and it's own everything. Users are only allowed to run a single instance of any particular iteration on a single machine. The truth is I have 4 apps running in each "home" directory but for clarity I am only showing 2, ITF.EXE and ITFBACKGROUND.EXE

For more clarity I am only showing the server's configuration. I have seen your postings on other forums so I know you are familiar with RemoteApp so I know you understand the server can be virtualized so each session is a "window" on the server (like multiple workstations all on the same machine).

Example on one server.
d:\ITF-BANK1
d:\ITF-BANK1\ITF-BANK1.EXE (really just ITF.EXE renamed)
d:\ITF-BANK1\ITFBACKGROUND-BANK1.EXE (really just ITFBACKGROUND.EXE renamed)
d:\ITF-BANK1\DATA
d:\ITF-BANK1\TEMP
d:\ITF-BANK1\TEMP\ITF
d:\ITF-BANK1\TEMP\ITFBACKGROUND
and
d:\ITF-BANK2
d:\ITF-BANK2\ITF-BANK2.EXE (really just ITF.EXE renamed)
d:\ITF-BANK2\ITFBACKGROUND-BANK2.EXE (really just ITFBACKGROUND.EXE renamed)
d:\ITF-BANK2\DATA
d:\ITF-BANK2\TEMP
d:\ITF-BANK2\TEMP\ITF
d:\ITF-BANK2\TEMP\ITFBACKGROUND

The config to run ITF-BANK1 and ITF-BANK2 is:
TMPFILES=.\TEMP\ITF
The config to run ITFBACKGROUND-BANK1 and ITFBACKGROUND-BANK2 is:
TMPFILES=.\TEMP\ITFBACKGROUND

The configuration I have defined above ensures a single instance of each iteration has it own temp folder. That was fine before I switch to RemoteApp. Only one instance of any iteration was ever running on the same machine. With RemoteApp, multiple instances of the same iteration will be running on the same machine because all users will be running on the server. For example, Jack will be running ITF-BANK1 and ITF-BANK2 on the server and Jill will be running ITF-BANK1 and ITF-BANK2 on the server, all at the same time.

If I change the config files to say:
TMPFILES=%temp%

which is what you and others are suggesting, Jack would be using his session's temp folder for both ITF-BANK1 and ITF-BANK2 and Jill would be using her session's temp folder for both ITF-BANK1 and ITF-BANK2.

That does not provide a separate temp folder for each VFP app running on the server.

In case someone is wondering. I copied the following from Microsoft's website:
If a user is running more than one RemoteApp program on the same RD Session Host server, the RemoteApp program will share the same Remote Desktop Services session.
That means even though you may think Jack is getting 2 sessions, one for ITF-BANK1 and another for ITF-BANK2, he is not.

2 possible solutions:
1. It isn't necessary for each iteration to have it's own temp folder because VFP is generating temp filenames that are unique across all apps running on the same machine.
2. That puts me back to my original question about having my apps generate a unique temp folder for that instance of the app.

I am not real smart. I have been coding FoxPro for 30 years but because I work in a framework I missed a lot of the basics. My point is I may be a little slow but I do appreciate your assistance,
John

 

[Olaf Doschke]

What I suggested was to not at all have any TMPFILES configuration line, indeed you can do without any config.fpw file overall.

VFP will then take %TEMP%. And that is sufficient, even if there are multiple processes per user/user-session doing so and taking the same temp folder, as you say the only temp files will be natively created by VFP by creating several cursor types.

I would just have one final question or take it as test suggestion: Once you close your app, what files remain in the TEMP folders you now have and use for the TMPFILES configuration? Are there any files left at all? If so, can you delete them, is no process having them open? And finally are there files with non VFP extensions?

Bye, Olaf.

 

[cfsjohn]

Thank you Olaf,

To answer your questions:
The files in the temp folders below each app's "home", DO get deleted when the app quits.
There are NO files with non VFP extensions.

I just got access to a cloud server yesterday (the first time I have ever accessed a cloud server).
I setup 3 ITF's on the server. I ran them using remote desktop. Each one uses the temp folder under the app's "home" because I have not yet changed it to use the sessions temp folder.

The hosting company sent me the 3 RemoteApp connections and I ran all 3 simultaneously. The RemoteApp connections are using the sessions's temp folder. I can not see the properties of the RemoteApp connections but I suspect they did not use the command line parameters that I use when running via remote desktop and as you stated it is using the default. I have emailed them to ask.

Per your last answer, I am convinced using the session's temp folder is the right way to go. I will do that for my testing. I have many things to test. My app has settings for printer names for a plain paper and for a dedicated checks printer. The user never selects a printer. When my app is printing a report it automatically sends it to the plain paper printer and when printing a check it automatically sends it to the checks printer. That means I have to maintain "workstation settings" when my app is run, irrespective which workstation it is run from. That has been a real challenge but I believe I have it resolved. And then I also have a VFP/VFE web app (thanks to Rick Strahls immense help). That may present some challenges. Testing will be fun but this RemoteApp concept is just about the slickest thing I have seen yet. I truly believe it is the answer to speed until I can become a web app.

Thank you,
John

 

[Olaf Doschke]

n regard to configuration options: an rdp link is nothing but a text file, you can add a .txt extension and read it. It doesn't work at all like a fpw file, as it causes your local system to take some of that data to know how to make a connection and then start an EXE there, so it very much compares to a shortcut link, it has some settings like what to allow to be used shared, eg clipboard, etc. but it doesn't compare to the usual lnk file infos, too.

In the end your VFP EXE is run on the remote server side and any fpw file THERE, local, would have the same effect as a fpw file on a dektop client.

You still don't seem to get it or believe it, but you'll see.

In the case of an application I had to adapt from the usage of an own temp folder to system temp, that was not just only a TMPWORK setting folder, it contained several local DBFs, so it was rather a folder for local data, also persistent between sessions. That is something, that simply is not the real nature of temp files, but for permanent private non shared data, the user profile would have been better for such things.

What you use are simple normal temp files and the easiest way to cope with them is not coping with them at all. The VFP runtime adheres to system rules and you don't need to specify TMPFILES at all.

Bye, Olaf.

 

[JRB-Bldr]

I have multiple iterations of multiple apps on a single machine. Each iteration runs the same executable but the executable is renamed per iteration.

...until I can become a web app.

I agree with all of the advice you have received above about running in an RDP environment (RemoteApp enables you to make programs that are accessed remotely through Remote Desktop Services appear as if they are running on the end user's local computer.).
NOTE: Microsoft to drop Azure RemoteApp in favor of Citrix virtualization (Aug 16, 2016)

Based on all you have described above, you have a very complex, client-specific directory structure and separate client-specific executable 'architecture' (perhaps unnecessarily complex) which, in its current state, will not lend itself to a web app very well.

One of my clients has migrated from a RDP-oriented legacy VFP application for its many users to a web-based application and, as a result, needed to change many components of the application 'architecture'.

Perhaps now is the time to begin thinking forward and possibly begin thinking about re-designing your application so that it might work better both now and when you eventually convert it to a web app.

Good Luck,
JRB-Bldr