One issue I still haven't figured out with the .NET Handler...
We have the app set in the wconnect virtual (OK technically an IIS application). The web.config file is in wconnect and webconnectionmodule.dll is in wconnect\bin. Since the handler mappings are defined at the wconnect level, we have to include wconnect in the path each time we hit a page.
Under ISAPI, I could just define script maps at the root level that pointed to wconnect\wc.dll to avoid having to include the extra folder in the path. I haven't been able to make anything equivalent work on the .NET installation. My attempts to define handler mappings at the root level end up bringing down the whole site
--stein
Huh?
Script maps don't require a path as long as you're not referencing a physical file. It doesn't matter whether the map is ISAPI or .NET - the process of script mapping is handled through IIS and the behavior as far as paths are concerned are the same.
Make sure you don't have file requirement flag set on the extension.
Again I recommend you use the tooling to do this - it'll make sure the right settings are made. It sounds like you have your own installer. If not take a look at a new project and the yourapp_ConfigServer.prg file and see if you can create something like this for your app. Latest versions automatically let you run that with YourServer.exe CONFIG.
+++ Rick ---
``
Script maps don't require a path as long as you're not referencing a physical file.
That's true if they are defined at the root (default web site) level. But in this case the box to "Make scriptmap available to virtual only" was left checked - you can see the results here:
http://70.167.40.88/wconnect/about.awp
"About" is a dynamic page mapped to a Process method, so it's not an issue of needing the physical file.
My question was how to go about retroactively changing the mappings while leaving the rest of the app in place, but maybe it would be simplest to reinstall using the console exe?
--stein
PS We have our own installer program which attempts to use your tools by incorporating your wwAppWizard code (from the console folder). But I see that hasn't been updated in a while - maybe I need to look at the ConfigServer program.
Not sure I understand what you're saying.
I think you can do what you want with the handler as well. Move all the 'application configuration' to the root site then you can declare the handler and configuration globally and WC will be accessible anywhere below.
It works with ISAPI because ISAPI handlers are global to the entire application pool. If you want that same behavior you essentially achieve the same thing by moving the WC configuration to the root. The one problem with that is that it will change your meaning of the ~/ path - when you move to root the ~/ root will be the web site root instead of at /wconnect. But other than that I wouldn't see any downside to using the root folder instead of /wconnect.
The idea never was to isolate the /wconnect folder - the idea was to isolate the context of an application, and prevent leaking configuration to a root Web site when the entire application is self-contained in a virtual. Ultimately .NET just works with the IIS Application model why ISAPI (which long predates all that) works globally.
+++ Rick ---
OK, I got this to work, sort of. I moved defined my handler mappings at the root level (in wwwroot\web.config) and added the
But since customers may have hard coded links to the wconnect folder, I also want to support calls to \wconnect\xxxxxxx.awp. When I first tried that (with webconnectionmodule.dll removed from wconnect\bin), I got:
Could not load type 'Westwind.WebConnection.WebConnectionHandler'.
To make it work, I had to copy webconnectionmodule.dll back into wwwroot\wconnect\bin. But that means I now have 2 copies of the DLL, which does not seem like a sustainable solution.
--stein
You need to now remove the application from /wconnect because that essentially splits your site into two 'applications': The root Web Site and the /wconnect virtual.
If you remove the application, or make /wconnect just a Virtual (not an application), then /wconnect runs within the context of the root folder and it all runs as one. This is the best approach and probably the way the app should have been set up in the first place, but now you have to watch out for potential path problems as your base locations for pages has changed to the root site physical (and virtual folder), which may or may not be a problem depending on how you reference your pages.
Web Connection's internals shields you from most of the differences but whenever paths are embedded via code you likely have to adjust them to not point at the correct relative location.
+++ Rick ---
That makes sense. We used to base our configuration on a virtual folder - it looks like our recent installs define wconnect as an application - not sure why we switched.
Thanks for helping clarify this for me...
--stein