My application provides data lookups for subscribers and I want to create a 2nd Process class specifically for my own maintenance tasks with it's own scriptmap, authentication, etc. but have access to the same database as the end users for maintenance purposes.

Because the virtual was created when I created the project, I'm assuming that I should leave "Create Virtual Directory" unchecked in the New Process wizard when creating the 2nd process class.
Is this correct ?

Thanks,
Carl

Make sure you do a backup (or check into source control) before you do anything just in case - this part is still under some construction.

To be safe you can create a new virtual, and then simply copy the script mapping into the web.config of the old virtual or root. You may also have to change the YourApp.ini settings to point at the old virtual. This works in any version.

+++ Rick ---

Since you said creating a new virtual works with any version, I tried this on my laptop that still has Version 6.0 B3 (12/1/15) on it.

Running Console from Explorer as Administrator...

First Try:
I selected "Create Virtual Directory" and set the path to match my main application path.
Example: c:\webconnectionprojects\myApp
No errors reported during configuration.
Hello World failed - 404.
Looked in IIS Admin and noticed that the application's Physical Path and Handler Mappings Executable Path did not match that of my original/main Process. Figured that was the problem.

2nd Try:
Same as above but set path to c:\webconnectionprojects\myApp\Web
No errors reported during configuration.
Hello World failed - 404.

In IIS, the application's Physical Path and Handler Mappings Executable Path do match that of my original/main Process.
Looks OK - doesn't work.

Also:
When hitting a page with a script map extension for the original/main Process class, I now get the following error which did not previously occur:

Unable to write File Messaging message file in the TEMP path (.\temp\).
Please make sure that the directory exists and that the user - SYSTEM - has FULL access permissions in this path.

Don't know what to try next.

Carl

When you create a new project that will be created for you, but if you have an older project (pre-beta generated) that folder won't be there. When you add to an existing project it won't recreate the folder structure. Either change the temp path or create the temp folder in the deploy folder.

The 404 indicates that the virtual is not configured. Check in the IIS Management Console. Can't really say why that wouldn't work. Make sure you always go to the Web folder not the the base folder although that will still work to create the virtual, just in the wrong place.

I can't really tell what you're doing based on the description.

If you want to do this manually you can do this:

* Copy an existing process class
* Remove the body code and rename it your new class
* Rename the class and the PRG file
* In AppMain.prg in the Process class copy one of the script map CASE statements
* Replace the scriptmap with your new scriptmap, replace the Process with your new Process PRG
* In Web.config copy one of the existing scriptmaps in the Handlers section
* Change the script map name and extension to what you want

As I mentioned the Add Process functionality was still under construction especially pre-RC so you may be seeing a somewhat in between state if you are still running beta 3. In RC1 this should be working reasonably well and it will be all done in RC2 which should arrive in a few days hopefully.

+++ Rick ---

Unable to write File Messaging message file in the TEMP path (.\temp\).
Please make sure that the directory exists and that the user - SYSTEM - has FULL access permissions in this path.

This project was created from scratch 3 months ago using Version 6.0 B3. It's the project I moved to my main machine a while ago as we discussed in Thread ID 4JB0FJ15N.
The original configuration went smoothly and the app ran fine until I tried to create a new process class today.

The subfolder TEMP exists in the DEPLOY folder with FULL ACCESS for the SYSTEM user.

The New Process function did the following correctly as far as I can tell...
1. Created the new process class PRG file - looks OK.
2. Added the CASE statement to psPartsMain.Process() for the script map "PSM".
3. Added the following to web.config

<handlers>
            <remove name="AboMapperCustom-556907" />
            <add name="AboMapperCustom-556907" path="*.psm" verb="*" modules="IsapiModule" scriptProcessor="c:\webconnectionprojects\psparts\web\bin\wc.dll" resourceType="Unspecified" requireAccess="Script" preCondition="bitness32" responseBufferLimit="0" />
  </handlers>

The IIS Manager, the virtual (IIS Manager refers to it as an Application) is under the Default Web Site and the Physical Path is "c:\webconnectionprojects\psparts\web" as it should be.
The Handler Mappings in IIS Manager show the same path for ".psm" as was inserted into web.config as shown above.

In case it matters, the Web Server selected is IIS ISAPI.

Anything else I can look for?

Thanks,
Carl

Unable to write File Messaging message file in the TEMP path (.\temp\).
Please make sure that the directory exists and that the user - SYSTEM - has FULL access permissions in this path.

The ISAPI extension requires a full path in the ini. The .NET module can take relative paths like ~\..\deploy\temp\ which is much more portable.

There's more info on troublehsooting here:

http://www.west-wind.com/webconnection/docs/_s8h1ecqdy.htm

+++ Rick ---

<handlers>
            <remove name="AboMapperCustom-556907" />
            <add name="AboMapperCustom-556907" path="*.psm" verb="*" modules="IsapiModule" scriptProcessor="c:\webconnectionprojects\psparts\web\bin\wc.dll" resourceType="Unspecified" requireAccess="Script" preCondition="bitness32" responseBufferLimit="0" />
  </handlers>

Unable to write File Messaging message file in the TEMP path (.\temp\).
Please make sure that the directory exists and that the user - SYSTEM - has FULL access permissions in this path.

I did some testing here to give you better feedback.
I installed Version 6.0 RC1 for these tests.

Following are the results of 8 tests I did when creating a second process class in a given project.
In each test, a new project was created (verified by Hello World test page) and a 2nd Process class was then added.

The first 4 tests use the IIS .Net Handler and the last 4 tests use IIS ISAPI.

The options chosen for each test were as follows...

Test 1
- Create Virtual Directory checkbox: Checked
- Virtual: new unique name
- Path: new unique path

Test 2
- Create Virtual Directory checkbox: Unchecked
- Virtual: <empty>
- Path: <empty>

Test 3
- Create Virtual Directory checkbox: Unchecked
- Virtual: same as main process class
- Path: same as main process class

Test 4
- Create Virtual Directory checkbox: Checked
- Virtual: same as main process class
- Path: same as main process class

RESULTS - .Net Handler
===============
Test 1
- All OK

*******************************************
Test 2
Numerous errors occurred starting with "loDOm is not an object"
More errors occurred involving loWebNode, loCRNode, loConfigNode,...
I just clicked "Ignore" until the process ran to completion.

Primary Process Hello World still worked.
New Process Hello World DID NOT WORK.

Manually added the Managed Handler for the new Process script map in IIS.
- Hello World for new Process then worked.

*******************************************
Test 3
No errors during config.

Primary Process Hello World NO LONGER WORKED.
New Process Hello World worked OK.

The Managed Handler for the script map for the primary Process Class was no longer in IIS.
Manually added the Managed Handler for the primary Process script map in IIS.
- Hello World for primary Process worked again.

*******************************************
Test 4
Same as Test 3

RESULTS - ISAPI
===========
Test 1
No errors during config.

Primary Process Hello World still worked.
New Process Hello World DID NOT WORK.
ERROR: Unable to write File Messaging message file in the TEMP path (.\temp\).

*******************************************
Test 2
Non Fatal Error: Scriptmap
Unable to create scriptmap .tfb
Please configure the scriptmap manually in your Web server administration application.

Manually added the Script map in IIS.

Primary Process Hello World still worked.
New Process Hello World also worked (after adding scriptmap in IIS)

*******************************************
Test 3
No errors during config.

Primary Process Hello World NO LONGER WORKED.
ERROR: Unable to write File Messaging message file in the TEMP path (.\temp\).

New Process Hello World DID NOT WORK.
ERROR: Unable to write File Messaging message file in the TEMP path (.\temp\).

*******************************************
Test 4
No errors during config.
Same as Test 3

Here's another test with interesting results...

1. Create New Project (IIS ISAPI)
2. Change TempFilePath in project INI from .\temp\ to .\foo\
3. Hello World Test Page
- Request Timed Out
4. Restore TempFilePath to .\temp\ (Hello World OK again)
5. Create New Process Class
- Virtual name and path same as initial project virtual
Side Note: Script map for 2nd Process was not added to the INI file (added it manually here)
6. Hello World with either Process
- Unable to write File Messaging message file in the TEMP path (.\temp\)
7. Change TempFilePath in project INI from .\temp\ to .\foo\
8. Close and restart VFP WC Server (I actually closed VFP completely)
9. Hello World with either Process
- Unable to write File Messaging message file in the TEMP path (.\temp\)

It appears that "(.\temp\)" in this message did not come from the INI TempFilePath setting. I would have expected a Request Timed Out response like Step 3.

Carl

Hi Rick,

When I first starting working with WC again a couple years ago (after a long absence), the Web Connect Demo project would not set up no matter what I tried. When I created my project, I selected .NET but it failed (don't remember the details but nothing was actually created if I recall correctly). I then created the project using ISAPI and it worked and I've been using it ever since. Having zero understanding of anything IIS, I just stuck with what worked and never tried the .NET Handler again on this machine.

I do realize that .NET is the preferred approach.
What makes it preferred ?
Can my existing project be altered to use .NET instead of ISAPI with just manual editing? I'm a bit gun-shy about automated configuration on this machine.

Thanks,
Carl

More info here:
http://west-wind.com/webconnection/docs/_0g013muoo.htm

+++ Rick ---