Rick,

We regularly have issues with fxp getting stuck in the IIS/OS cache. Since our platform is a multi tenant application, we end up having fxp's in all of our clients folders. I got to thinking that it would be cleaner to have a single folder to house the fxp files. Do you think it is safe and or advised to put them in a folder such as c:\temp

Thanks in advance.

MB

Wouldn't make a difference. The problem isn't IIS the problem is FoxPro. FoxPro loads procedures into memory and doesn't unload them if there are reference to any code inside.

wwScripting tries to unload scripts after they are run so the FXPs are released, but that can fail if your code has any hanging references to anything that lives within the scope of the script function that gets generated (ie. a hanging class reference or circular reference) which will lock the FXPs.

The way to deal with this is use the compilation feature and run in single COM mode to recompile all scripts on a site in batch. Then fire up the full server load after you're done.

Alternately add a routine to you server admin routines that does recursive delete of all FXP files. Again if you're in single use mode this should clear out all other running instances and if you just started up the current admin session none of the FXPs should be locked which means they can be deleted.

They will be recreated the next time the app runs (unless you're running in precompiled FXP mode).

+++ Rick ---

Rick - having some trouble understanding your response here. Can you confirm that 'single com mode' means when compiling the exe to make it 'single use' or do you mean have only a single instance of the exe running in com? I think we have 10 servers loaded by default now.

Also, we use templating for the UI (html with various vfp and app functions). If you recall in my world, we have a multi tenant app with each tenant using 'shared' templates. This means each client has a folder below inetpub, and they end up sharing fxp's from a central 'system' folder. When we recycle our exe i suspect you are telling me that we should delete *.fxp (everywhere)... That's fine, but do we have to do the following?

1. stop iis
2. delete fxp's
3. swap out exe
4. start iis

The only way to reliably cycle compiled FXPs when multiple servers are active is to restart the COM server pool to unload FoxPro. You don't have to cycle IIS - cycling the Application Pool or the COM Pool is enough. You just need to get VFP to unload.

The way it works is this:

If a template is changed and you run it the next time one instance will grab the PRG and compile it into an FXP. That instance will see the change it made because that VFP instance knows a new FXP was created. However, other instances will never try to reload the now updated FXP file because they are cached - until they restart.

In short no easy answers.

It might be interesting to build a file system watcher that can detect template changes and automatically restarts the FoxPro Application Pool when one is updated.

+++ Rick ---

It might be interesting to build a file system watcher that can detect template changes and automatically restarts the FoxPro Application Pool when one is updated.

Short of having that watcher app, what options do we have for remotely unloading the COM servers? Of course we can use ModuleAdministration.wc?_maintain~Release from the Admin page IF we have the AdminAccount credentials. But with many of our customers that's a problem. The account id is the sys admin's personal account or it's a service account that nobody remembers the password for or worse, they never get around to setting an account so we have to go in and set it to Any just to secure the page. The upshot is we can't get to the admin functions.

We run into a lot of situations where it would be really nice if we could unload the COM servers without having to track down an admin to restart IIS.

--stein

You can't shut down COM servers any other way than through the admin interface, or by physically nuking them with TaskKill or the like.

However, the accounts that have access to the admin page and links don't have to be admins - the Web app has to be running under and Admin account, but that's separate from the user's actual account. As long as they can get to the admin links admin rights are not required.

+++ Rick ---

Admin access isn't the issue - it's having any type of access. Our app is running on the customer's server - by default, we're not going to have credentials for any of its user accounts. We suggest that they set up an account specifically for maintaining our app, set AdminAccount to that user name and let us have the password, but that does not often happen. As noted, we typically end up with AdminAccount=Any but we don't have "any" credentials.

Question: if I issue a call to ModuleAdministration.wc?_maintain~Release, does it check the config file for the AdminAccount setting each time? i.e. could I programmatically manipulate wc.ini to clear the AdminAccount setting, then release the servers, then reapply the security?

--stein

No the values are cached. Loaded on startup and then cached in memory so you can't re-write the values.

+++ Rick ---