Web Connection User Discussions
Migrating from ISAPI to .net managed handler
Gravatar is a globally recognized avatar based on your email address. Migrating from ISAPI to .net managed handler
  Michael B
  All
  Jun 21, 2020 @ 04:48pm

Rick,

I am trying to setup a new site on an old server running the .net managed handler. I got it working in file mode, but discovered that the site now has two web.config's. My root web.config and one in the admin folder. Is this normal?

Also, when I try to hit my home page I get this error when in COM. A reminder that I am trying to have an existing COM isapi install running on same server. The new site has a 'bin' folder and has the managed handler mappings as it should.

The Com server threw an exception during the server method call:
Unknown name. (Exception from HRESULT: 0x80020006 (DISP_E_UNKNOWNNAME))

This works fine in file mode and yes I did re-register my exe.

Any suggestions?

Gravatar is a globally recognized avatar based on your email address. re: Migrating from ISAPI to .net managed handler
  Rick Strahl
  Michael B
  Jun 22, 2020 @ 11:48am

Generally all settings should go into the root web.config, but if you used the IIS Admin tool to set specific settings on the admin folder then yes that will create a separate web.config file there.

As to the COM Error - make sure you are using the right DLL with the right version of Web Connection. Remember when we worked through this stuff the other day, Web Connection 7.13 has a new mechanism to pass messages in COM mode (to support the new Web Connection Web Server).

As always test it local first and make sure it works then ensure you copy all the local files to the server.

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: Migrating from ISAPI to .net managed handler
  Michael B
  Michael B
  Jun 22, 2020 @ 03:47pm

Ahh that could be. However, I merely copied what was on dev to production, so it should have worked. Can you confirm that the wc.dll is not used 'whatsoever' in the COM mode using .net managed handler?

Also, is it safe to assume that I can and should use many wc'dll's if I have many websites and each needs its own 'temp' path, even if running in COM?

Sorry if this is a RTFM type of question.

Gravatar is a globally recognized avatar based on your email address. re: Migrating from ISAPI to .net managed handler
  Rick Strahl
  Michael B
  Jun 23, 2020 @ 01:44am

Also, is it safe to assume that I can and should use many wc'dll's if I have many websites and each needs its own 'temp' path, even if running in COM?

I'm not sure what that means exactly. I assume you're talking about your multi-tenant setup with using one DLL to run many applications. Yes that only works with the old ISAPI DLL. THe .NET module has to be configured one per each application/Web site (IIS application/AppDomain boundary).

ISAPI is and effectively has been deprecated for a while now. It's not been updated in a long time and won't be going forward. Most of the UI changes that have been recently been, the administration interface integration changes etc. have only been made to the .NET and .NET Core servers. ISAPI may see a fix here and there if necessary, but beyond that code base is done.

As to multi-tenancy - there are other ways to get this to work. None are easy, but it can be done with the right high level setup of sites and virtual directories. There's a topic in the docs:

Multi-Tenant Web Connection Applications

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: Migrating from ISAPI to .net managed handler
  Michael B
  Rick Strahl
  Jun 23, 2020 @ 06:27am

Rick - your assumption is correct - I assume you're talking about your multi-tenant setup with using one DLL to run many applications. Yes that only works with the old ISAPI DLL. THe .NET module has to be configured one per each application/Web site (IIS application/AppDomain boundary).

Yes - currently my application has a single wc.dll mapped at the 'root' so that every IIS website on the server is able to share a single configuration bound to a single exe (from my POV that is what a pure multi tenant app is). The net result of my setup is a 'server within a web server' because the routing to websiteb.com and website.com happens inside my 'server' as well.

Maybe it's best to reset why we are discussing this in the first place. For the past year we have been having lots of crashes that do not recover gracefully in IIS. We get regular COM errors, and recently starting getting 503 errors. When you checked out our setup you immediately said 'you need the net managed handler'.

Great! A possible solution on the horizon. I also should confirm that I took the WWWC class prg's from version 7.10 and replaced them in my app after a backup. I then recompiled and everything seems to be working (in dev).

What I am not comfortable with at the moment is not knowing what actually has changed. Meaning, does the .net interface do anything differently with respect to firing up many instances of my app if they are needed? Is it ok if 100 sites in IIS all share my single exe through 100 web.config's that are all having essentially the same configuration?

If the answers are YES, it is not clear to me why this will help anything. I suspect you might say, if one site crashes, it wont take down the entire app for all. That would be a benefit for sure.

Gravatar is a globally recognized avatar based on your email address. re: Migrating from ISAPI to .net managed handler
  Rick Strahl
  Michael B
  Jun 23, 2020 @ 04:39pm

If you used to run wc.dll in the root folder through a root Web site, with several virtuals, you were essentially running one big application even though they looked like they were separate. Meaning all those virtuals basically shared the same COM instances. That can be desirable in some cases, but it's probably not a good idea as all applications are then effectively linked.

Using .NET every application - root Web Site or an IIS Application but not a Virtual - are completely separate from each other and each application runs in its own memory space. They can still share the same Application Pool which is the host EXE, but the applications themselves are separate in .NET AppDomains. Each application then has its own set of COM objects, which means you'll have many, many COM instances for all the applications that are running, each with its own set. They can all run the same COM server, but they will effectively all be separate.

It all depends on how many servers you have and how busy they are really. You'll want to run at least two instances for each application.

Managing this can be difficult however. Because you can't easily shut down these instances short of shutting down IIS and if you're sharing binaries and data files it'll be very hard to be able to get exclusive access to data to perform maintanenance ops (if you're using Fox data - less or no problem with SQL servers).

I would argue that it's a better approach to isolate each application and give it its own set of servers and this mechanism is likely to be more stable than running a ton of instances accessed from a number of different Web sites. And if you really need to it's still possible to create a root Web site, register the handlers there and then use virtual directories to create sub sites.

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: Migrating from ISAPI to .net managed handler
  Michael B
  Rick Strahl
  Jun 23, 2020 @ 05:25pm

The 'current' way I manage this is each 'tenant' has their own IIS 'website'. We use two custom scriptmaps that point to a single shared wc.dll. The scriptmaps are assigned at the server level in IIS and each 'site' inherits it. We have a single wc.ini as well. We also have a shared content folder that is a virtual for each IIS 'site'.

When a hit comes in, the fox exe gets the request (we run between 10-15 instances), and then 'routes' it to the correct 'store' record. This in turn creates an object (oStore), and the store object knows what process class to use, and then the pages are evaluated from there. Each 'store' has its own 'datapath' and 'contentpath' for html files. If they are empty, they use the shared virtual mentioned above.

We also use MySql for wwSession and wwRequestlog and a mix of dbf's and or remote sql tables. Depends on the package our clients choose...

That's the long story short.

I do think the net managed handler can be used for each tenant because each tenant gets their own 'website'.

The difficulty in setting this up, is that instead of one wc.ini - I end up with one for each 'tenant' inside of web.config.

Lastly, I am not sure about the admin page. I do not think there is a reason for a 'tenant' to be able to shut down an exe, or maybe that is precisely why this is a good thing.

Your next response should be the ah hah moment for me.

Gravatar is a globally recognized avatar based on your email address. re: Migrating from ISAPI to .net managed handler
  Rick Strahl
  Michael B
  Jun 24, 2020 @ 12:41am

Lastly, I am not sure about the admin page. I do not think there is a reason for a 'tenant' to be able to shut down an exe, or maybe that is precisely why this is a good thing.

Each 'site' has its own admin page and if you run the module each site can shut down its own instances which is a bonus. But if you're sharing the same FoxPro data across all servers then shutting down one site's instance isn't going to be sufficient to get exclusive file access (for maintenance for example) - they need to all be shut down, which means shutting down IIS and then running some maintenance operation separately most likely.

This may not be a big issue for you though especially if the data is partioned to each Web site and local to it. if each site has it's own set of data, then you can still set the server to load a single instance - run the maintenance tasks, then start back several instances.

I think if you had designed the application using the module from the beginning this wouldn't be an issue because you would have already have thought about these limitations and how to get around them. It's entirely doable. With today's hardware gigabytes of memory you can run tons and tons of FoxPro instances without much of a hiccup. It'll be messy if you look in task manager, but beyond that these things just run in the background and spin up and shut down as needed. If you use relatively short site timeouts you can let the sites that are not receiving traffic power down and come back up when traffic comes back.

But since you have an existing app that didn't do any of that - because it probably predated the .NET module and the 'per application' isolation - it's not so easy to change the architecture now.

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: Migrating from ISAPI to .net managed handler
  Michael B
  Rick Strahl
  Jun 24, 2020 @ 04:41am

Thank you Rick for the time and attention.

FWIW - the app does isolate data from each tenant, sorry if I was not clear about that. The 'sharing' is really just the shared use of a 'current version of my app'. The 'share data' is all remote sql accessed via odbc and or api's we have written.

So, to your point, each site will have its own admin, its own collection of my app, and away we go. I just have to get comfortable managing it before pulling the trigger. Seems to me I can move one site at a time, instead of any major modification so that's a huge plus.

© 1996-2020