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?

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 ---

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.

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 ---

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.

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 ---

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.

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 ---

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.

Hi Rick,

I am hoping to have a live support call with you to save us both time, but in case you are not available, I am trying to get the web connection managed handler setup on a staging site. I am able to use the wwmaint tools just fine with this staging site, but i cannot load my custom app. I get the error below when doing it. I am hoping there is some way to debug this so we can understand what is going on and what file or files need to be updated or sync'd. I tried various versions of dotnetbridge and webconnectionmodule (old and new and in between).

HRESULT: 0x80020006 (DISP_E_UNKNOWNNAME))

Just as a follow up because this turned out to be an interesting failure that others may run into if they're doing a mismatched version update to Web Connection.

First, the problem Michael ran into is a COM invocation error HRESULT: 0x80020006 (DISP_E_UNKNOWNNAME)) which is caused by a missing method in the COM server.

Which is weird, because Web Connection calls exactly two well known functions over COM from the Web Connection module. How could it not find those functions in the COM Server?

Turns out Michael had replaced webconnectionmodule.dll in his old application, with a new version from the current 7.28 release. And as of v7.12 Web Connection has changed how COM calls into the Web Connection server.

As of v7.12 Web Connection now calls the FoxPro COM server with a binary value, rather than a string. This was changed due to internal reasons that were originally related to the .NET Core server, but which also affected the .NET Module. Basically converting to a string in .NET adds a lot of extra overhead which in some cases of large content was actually failing. By sending the binary data, the data passed is considerably smaller, doesn't require the extra conversion step in the Web server, and skips COM fixup of these string values which add additional overhead as part of the system COM call. As far as the Web Connection connectors go this is a pretty big performance and resource improvement, although for most applications this isn't going to make a noticable different - especially if you don't have large requests.

Anyway as a result of this change the Web Connection Server interface had to change however. Instead of calling into wwServer::ProcessHit(string data) the connectors now call wwServer::ProcessHitBinary(byteData).

And that is what was breaking Michaels code and the reason for the DISP_E_UNKNOWNNAME error.

Michael updated the DLL, but didn't update the old Web Connection server code, which now doesn't have the ProcessHitBinary() method and so the code breaks.

This bears repeating:

Web Connection is a matched system that by design depends on the server piece (ie. the module, .NET Core Web Server, ISAPI) so when you update your applications you should update your Web Connection server framework and the connector binaries!

While there have been very few changes to this simple base interface over the years they do happen occasionally so it's highly recommended you keep the DLL and the server interface in sync!

Now it turns out there's a simple fix for this because ProcessHitBinary() is a very simple method that can be added to the wwServer class:

************************************************************************
*  ProcessHitBinary
****************************************
***  Function:  Receives the request buffer as a byte array and returns
***             the result as blob. This is called in COM operation from
***             the ASP.NET Handler and ASP.NET Core Middleware
***    Assume:  Using this approach avoids unnecessary string conversions
***             on the Web Server connector processing which reduces memory
***             usage and improves performance slightly
***      Pass:  lvRequestBuffer  -   BLOB data from the server
***             llFile           -   If this is for file processing (not used)
***    Return:  BLOB data (byte array - byte[])
************************************************************************
FUNCTION ProcessHitBinary(lvRequestBuffer, llFile, loAspNetContext)
LOCAL lcResult, lcRequestData

*** Cast BLOB to a string
lcRequestData = CAST(lvRequestBuffer as Memo)

*** Process Hit and return result back as a BLOB
RETURN CAST( THIS.ProcessHit(lcRequestData, llFile)  as BLOB)
ENDFUNC
*   ProcessHitBinary

You can add this method after the ProcessHit() method

This method simply takes in the binary content from the server (which is a UTF-8 encoded string) and casts it to a string which in FoxPro happens to be very efficient - certainly a lot more efficient than COM BSTR_ conversions as all FoxPro does with it is a memory assignment. It then calls the old ProcessHit() method and request carry on like before.

With this added method added Michael's COM server started working even though he's running a v5 server (yikes).

Note that the ISAPI extension still calls ProcessHit() with a string as it did before, and that also still works. However, if using the new .NET DLLs in combination with an older server doesn't work, **unless you add the ProcessHitBinary() method.

Moral of the story is this:

It's a good idea to keep up with Web Connection releases. You don't have to update to each release but maybe every few months or year updating to latest is just good housekeeping to ensure you have all the bug fixes and feature updates like this mid-stream release update.

+++ Rick ---