>>>>>I ran an app from the command window and all was well, I thought.
>>>>>I built an .exe.
>>>>>When I ran the .exe it told me that a oapp.fedproc did not exist.
>>>>>When I looked at the applib.vcx the function did not, in fact, exist.
>>>>>Fortunately, I had an old copy that included fedproc, added it, and all is well.
>>>>>What is going on?
>>>>
>>>>Sounds like the old copy you referred to was in a folder that's earlier in our path list. And that you or someone else deleted the missing parts in the newer version.
>>>>
>>>>Anyway, make sure that the correct version if applb.vcx is included in the project.
>>>
>>>>Sounds like the old copy you referred to was in a folder that's earlier in our path list
>>>Tore
>>>Thank you for your reply.
>>>Can you please clarify what you mean by path list?
>>
>>I mean the order used in VFP's default path and your Set Path commands. Run this program, it will show the order in a readable format:
>>
>>

>>*Listpath.prg
>>#Define crlf Chr(13)+Chr(10)
>>Local laDummy[1], lcDummy, lnY
>>lcDummy = Set([Path])
>>lnY = Alines(laDummy, m.lcDummy,1+4, [;], [,])
>>lcDummy = []
>>For lnY = 1 To m.lnY
>>   lcDummy = m.lcDummy + m.laDummy(m.lnY) + crlf
>>Endfor
>>Messagebox( m.lcDummy )
>>

>
>But this only half of the problem. It misses for example SET CLASSLIB. what deals with this as well. Also systems search path.
>And if you open up a class from somewhere else, VFP caches the classlib, and this got precedence over all of this. There is a lot of fun included.
>
>I run all my tests from a clean environment with no path / classlibs except systems PATH


>And if you open up a class from somewhere else, VFP caches the classlib, and this got precedence over all of this

That might be the issue here
I frequently look at classes in other apps - in like-named libraries- without leaving the current app.
How to defend against this?