Hi,

After adapting part of the code and "publishing" it, I now want to build the original project (not xxxprod or xxxtest) and recreate the original .exe.
In this project there is aw.prg, ab.prg and ac.prg - should they be in this project or only in the xxx projects?

The problem is that when the project is built there are about 30 additional ab, ac and ww files added to the project - it seems like all of FiC and webConnect!
Is this right?

A related problem is that the project already uses the commercial version of wwClient (v7.07), including wwDotNetBridge. After these files are added I now get an error on this line when wwDotNetBridge is initialised :
DECLARE Integer SetClrVersion IN WWC_CLR_HOSTDLL string
From reading the wwClient forum it appears that there is a conflict in versions going on.
Is this a known problem?

Thanks
Paul

Hi Paul,

After FoxInCloud adaptation, your desktop project only needs public libraries located in home(1) + 'tools\ab\', nothing in sub-folders.

I suggest you remove all libraries in ac\, ww\ and aw, build your project in a 'naked' version of VFP (without the FoxinCloud Set PATH), and find in the error report what code needs additional resources requiring all these extra files.

after you check these resources are only needed in Web mode (conditioned by some wlWeb), you can use name substitution to cheat the project manager: eg. newObject('someClass', 'class' + 'Lib.vcx')

After these files are added I now get an error on this line when wwDotNetBridge is initialised : DECLARE Integer SetClrVersion IN WWC_CLR_HOSTDLL string

'an error' alone never helps… we need to know the kind of error you get. I understand this error occurs at run time.

FWIW, FoxInCloud does not use, and knows nothing about wwDotNetBridge.

This is the error :

I think it is because something from wconnect is being dragged into the project and a #define from there interferes with one from wwClient.

What I am trying to achieve, which may be difficult perhaps, is have just one project for both desktop and web - the original project and original .exe; so don't use xxxprod.
To do this I have added xxxprod.prg, xxxserver.prg and xxxsets.prg into the project, as well as ab*.prg and awpublic.prg. The compiler then wants to add awserver.prg and it starts spiraling from there, wanting to add more files from ac, aw and wc.

I haven't actually compiled xxxprod yet, so I don't know what that looks like after being built - would you expect the web project to contain all of those ac*, aw* and wc* files?
If the answer is yes then I suppose I either accept that in the desktop project or keep the desktop project separate from the web one.

What I am trying to achieve, which may be difficult perhaps, is have just one project for both desktop and web

you definitely need 3 different projects, each with a different main program.

xxxTest and xxxProd must be separate to have a different COM GUID and class ID on the server, each being linked to a specific web application.

would you expect the web project to contain all of those ac*, aw* and wc* files?

definitely yes; not needed in the desktop project however as explained earlier.

Turns out wwipstuff.dll in my application directory had been reverted back to a version from 2012; presumably from the old version of web connect that FiC uses! This was causing the wwDotNetBridge error.

After trying so many steps I don't actually know what process copied this old file over, I certainly did not copy it manually.
If something in the build process is doing this then that will be a problem for us. I will go through the process again next week and check.

I know what you are saying about the different projects and I will think about what to do.
On the one hand it would be nice to only compile one .exe to cover everything and on the other hand it would be nice to reduce the project bloat for desktop-only.
I intend distributing the application via Docker, so having different .exe's for test vs live won't be so much of an issue.

Paul

I did not find any evidence that FAA copies this file, maybe somewhere deep in the code, however it's definitely not during the project and/or exe build.

Again you need different projects and exe for web because the entry point (main program) is essentially different from the desktop: you need to keep the ability to check the web server in file mode (run xxx[Test|Prod].exe) before using it in COM mode; in this case the read events expects wwFileTimer.Timer() events, not user events.