Finally getting around to upgrading our flagship app from 6.22 to 7.04. I copied in the updated framework files, then went through the code to fix the references to wwXML and wwSQL to use program based classes. I am leaving the VCX based wwBusiness objects in place for now.

I was able to get my project to compile and run without errors, but when I attempt to hit any of my mapped pages, I get an application error of this type:

Could not find file 'c:\temp\wc\WC__8_24b73242.out'.

This is running in File mode, using the .NET handler, under localhost on my development system. Seems like this is not my code but something farther upstream.

Any suggestions would be appreciated.

--stein

That sounds like a permissions or file location issue. Make sure you temp paths between client and server match and you have the proper permissions to that folder and that folder exists.

New recommendation for temp folder location is to put it in your application's hierarchy below the binary folder for easier location and simpler reference. In the config you can then just use:

 <add key="TempPath" value="~\..\temp\" />

and in your app.ini you can use:

Tempfilepath=.\temp\

which is 100% portable and you don't have to create folders. The 7.0 configuration manager also automatically sets permissions in that folder. Just a thought.

IAC, make sure permissions and path are correct in both the Web config and the app configuration.

+++ Rick ---

OK, I can double-check permissions.

But can you explain how any of that could have changed just by applying the upgrade?

--stein

No - but the message is pretty clear - it's not able to find the file that's been dropped. Either means the file is not there or the server app doesn't have permissions to read it (although it is weird that it gets that far). Just make sure the paths truly match in the two config files.

I'm not sure where that message is coming from frankly whether it's from the DLL or from the Web Connection Fox bits. Can you paste a screen shot? I think based on the UI I can probably tell.

+++ Rick ---

I launched the exe after logging on with my account which has full admin rights on this box. Also made sure that the IUSR account has read/write access to C:\temp\wc

The config settings look OK:

TempFilePath=C:\temp\wc\
Template=WC_
   <add key="TempPath" value="c:\temp\wc\" />

Screen shot:

--stein

I'm not sure where that error is coming from - just did a search of the code base for that message ('could not find file') and neither the .NET module nor the FoxPro server generate that.

What does wcerrors.txt say? If it's a DLL error that error should be logged.

To check this out the best thing to do is:

• Shut down your FoxPro server (no com no file no autostart)
• Make sure the Web Connection module is in file mode
• Hit one of the pages
• Check the temp folder
  • Is there a new message file (id.tmp)

If there's no .out file you have a permissions problem with the Appplication pool not being able to write to the temp folder (or the path is wrong).

If it does show up, now turn on your FoxPro server. .out file should disappear and if you look closely (if you can't stop the WC server code) you should see a .out and .ret file created and go away immediately. The .out holds the generated output, the .ret file is a flag file that signifies the request is done.

I've checked the code and I can see if there's a problem with the .out file not existing or permissions being bad a generic error will occur which is what this likely is. I've added some additional logging there and that particular error should now produce a proper error page. That won't help but it'll determine if that's where the error is firing.

https://west-wind.com/files/webconnectionexperimental.zip

You can just update the webconnectionmodule.dll on the server.

+++ Rick ---

OK, I put the updated DLL in place, disabled all instances of the app, set it in File mode, and hit a page. I do not see an .out file but a file named .tmp shows up in the Temp folder.

When I start the app exe, the .tmp file disappears, but watching closely I see no sign of additional files being created even momentarily. I do now get your updated error message:

Unable to retrieve Server Output

We failed to pick up server output from the Server. This most likely is a path or permissions configuration issues.

It seems to me that if it's a path or permissions problem it wouldn't be able to create the .tmp file...

--stein

There's one of two things that can happen here. The server is either not returning any output or not creating the required out file but it is returning the .ret file that the module uses to check and see that output gets sent back. if you're running in file mode, capture request output and see what's being sent if anything. I suspect you have an error in your app and perhaps the error handling is failing (ie. an error in the error handler) which can cause no output to get generated.

If that's the case you need to debug the application and see where it's failing and why the error handler is bonking. if you're coming from 6.22 there shouldn't have been any changes to the error handling but from 5.x there were a few changes that had to be made to the error handlers and the way that the StandardPage and ErrorMsg methods worked.

+++ Rick ---

OK, I found the problem. It was failing at this line:

loProcess=CREATEOBJECT("Acecode",loServer)

which is why I was getting an error on every hit, and also why the error handler was not being invoked (since the handler is a process object method).

The cause was a misplaced ADDITIVE clause - introduced when I was fixing the wwSQL references - that killed the SET PROCEDURE list so wwProcess was not included.

Anyway with that fixed, it looks like the app is fully functional using the WC7 classes. Next step is to migrate the wwBusiness objects to use the PRG based classes.

Thanks,

--stein

Stein,

You should definitely check your error handling in your app and make sure that a failure will produce an error page and not just fail. Add a dummy request (perhaps behind a login) to force an error and see what you get.

The error you had should have produced some output even if it was in start up code with the new way that Web Connection 7 launches servers where wwServer::OnLoad() is not fired until the first request comes in which now reports an error message that you won't get past until the startup code is fixed.

+++ Rick ---

I in fact do have a crashme method in place and have verified that once the process object is instantiated error handling works as intended.

My problem earlier was that screwed up SET PROCEDURE call. Leaving off the ADDITIVE clause closed most of the procedure files that should have been opened when instantiating the Server. So hardly anything in the startup process could function properly, effectively undermining all your well intended logic. The server error handler did kick in and it was logging scads of error records in wwRequestlog - had I checked those initially there should have been enough clues for me to figure out the problem.

--stein

Ok - that's good.

General rule for debugging installations is to first check the error logs always. They may not always have information but when they do it's likely to be very useful.

One of the issues is that there are lots of places where error info goes:

• wcErrors.txt (in temp folder - Module errors for .NET or ISAPI)
• wcTracelog.txt (in EXE folder)
• wwRequestLog.dbf (in EXE folder)

Ideally it would be all in the request log but that's not available to the .NET bits or when the server is initially starting up...

+++ Rick ---