My EXE File creating DLLS automatically 1

[TrueCode]

I have a project which calls some DLLs which I BUILDed. However, when I run the EXE which calls those DLLs the EXE creates copies of the DLLs with an 'r1' added. So if the DLL was crypman.dll. the EXE would create a 3.3Mb DLL called crypmanr1.dll. You can only delete the created file after the EXE is closed, I mean not running.


What sort of a joke is that? Can somebody help me?



------------------------------------->

"I have sought your assistance on this matter because I have exhausted all the help that I can find. You are free to direct me to other source of help"

 

[Mike Gagnon]

TrueCode

Apparently you are not the only one :thread184-667887

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[TrueCode]

Mike,

I know that this has surfaced before. Now, I really need to deal with it. I thought that the files were being created at the time of BUILDing but no, It happens when the EXE file starts to run. Before running the EXE, I delete them, then run the exe, they show up....

I wished that Ramani, wgcs, Dave and the other Gurus would pay some attention to this thread.


------------------------------------->

"I have sought your assistance on this matter because I have exhausted all the help that I can find. You are free to direct me to other source of help"

 

[DSummZZZ]

Hey TrueCode,

Better late than never huh?

This issue has been an itch on my uhhh... knee since I first saw it. Along the lines of .tmp files being created which can be an issue. I hate mystery files showing up on my computer.
Anyway, see the link below for more details, but for those that don't want to chase the link, here are some hilites:

*The Visual FoxPro run time, vfp7r.dll, does not service multiple in-process .dll Automation servers. Each in-process .dll now uses a separate instance of the vfp7r.dll run time.

*The in-process .dll first called has exclusive use of the vfp7r.dll run-time library ...

*If an in-process .dll already has exclusive use of the vfp7r.dll run time, a renamed copy of the vfp7r.dll run time is created on disk and loaded into memory for each in-process .dll called.

*For example, if an in-process .dll named Myserver.dll is called, a copy of the vfp7r.dll run time is renamed to myserverr.dll...and is loaded into memory to service the in-process .dll.

And so on.....

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fox7help/html/newvfp7r.asp

-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[thatguy]

hey there Dave n others--

better late than never, indeed.. a star for the link to M$..

i just got into the dll thing recently and happened upon this oddity in VFP8.. i had been playing around with my dll for a week or two with no problems, then after a rebuild, the ___r1.dll file started appearing. turns out i accidentally rebuilt it as a single-threaded instead of multiple-threaded dll.

i noticed a really odd thing during my frustration.. i tried unregistering with regsvr32 /u proj2r1.dll and ran my exe again only to find that the VFP runtime dll had been unregistered! incredibly strange, i thought..

my question -- if a single-threaded dll causes VFP to create the __r1.dll file, what's the draw to using it? why not always create multi-threaded? is there some sort of performance loss? just curious

thanks
-- frank~

 

[DSummZZZ]

A couple reasons come to mind for using single threaded. One is app performance.
Since each instance of a com server is a separate thread, the OS can handle the optimal time slicing or multitasking. Which there would be none of for a multithreaded dll. During execution of a slower procedure, other apps may have to do some waiting.

Also, if several apps are sharing one instance of a com server and it crashes, they are all out of luck.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm