Best way to distribute .FLL files

[GriffMG]

Further to my previous question... I want to distribute Craig's .FLL file with my application (he has given permission - thank you Craig!).

At the moment, I'm using a free table contained within the complete .EXE file holding the .FLL file as the contents of a binary memo field. I'm writing that out to disk each time the app starts using FileToStr() - putting the file in the same folder as the executable.

This works quite well - it's a technique I use quite a lot for encapsulating binary files that I want to put on disk.

Is the the 'RIGHT' way to distribute a .FLL file? Or is there another way?



Regards

Griff
Keep [Smile]ing

 

[Olaf Doschke]

This is A way to do it, and I wouldn't call it wrong. It's especailly good as it will ensure it's the correct version. Overwriting existing flls with the version included in the EXE is a good though.

Despite of that it's just an (un)usual DLL, so you may simply keep it as a separate file. Just a matter of taste.

You may not want to compress that memo field with the fll as you need the fll first to uncompress itself then ;-).

Bye, Olaf.

 

[GriffMG]

Thanks Olaf,

I never thought of compressing the contents of the binary tables... I suppose I could now!

B-)

I was wondering if .FLL files were more 'native' and if I included them in the project itself, could I access them in the same way I do the free table... VFP seems to understand that when I issue the command:

use c:\dev\myproject\myfreetable

That I mean the version INSIDE the .dbf not one on a disk on the client's machine - if you follow me?

Can it do the same with a .FLL file?


Regards

Griff
Keep [Smile]ing

 

[Olaf Doschke]

Hi again,

There are two sections in a project for fll and app files: Code->API Libraries and Code->Applications. But you can't include these in the build process like you can do with tables. So this is just another way of informing the project (manager) that there is an external file belonging to the project, AFAIK.

Which means: Bad luck, nope.

Bye, Olaf.

 

[GriffMG]

That's not 'BAD LUCK'!

That's just fine, it means the way I'm using it is probably as good as it gets... thanks Olaf


Regards

Griff
Keep [Smile]ing

 

[Olaf Doschke]

Hi Griff,

yep, if you include the compression fll first and extract that first, then use it to decompress further flls, dlls or whatever, then you got my hint right and may be as good as it gets.

As long as someone has an additional idea to make things even better.

Bye, Olaf.

 

[Olaf Doschke]

There is one big problem with this: Users having insufficient rights to write to the program files folder can't use your exe then, if you install your application the way it's meqant to be.

If you do some setup with eg the Install Shield Express, that comes with foxpro, this will compress the needed setup files into one self extracting setup.exe anyway.

Bye, Olaf.

 

[GriffMG]

Hi Olaf,

You are quite right user rights are likely to be an increasing problem - for all of us!

I like to use the 'binaries within .exe' method because I can update remote applications really easily - without sending the whole install program.

I include an 'updater.exe' in the application that is written out each time the app is loaded. The user can check on-line for an update and download it (from within the app) and then unzip it (using Craig's utility) and then switch to the updater.exe which then copies it from the unzipped location, overwriting the original .exe file (which has quit after running the updater.exe) and then reloading the original file (phew). Using my technique I can update the application, the updater or any other file that the application needs - just by downloading the application's .exe file (in zip format).

It generally works well (using up to now an external unzipper run in a DOS window!) - except where the IT depts don't give user rights to download.




Regards

Griff
Keep [Smile]ing

 

[tsh73]

may be silly thought:
if user [could] have no right to write in program's folder,
could you extract FLL in TEMP folder (which is set in os like %TEMP% etc) and use it from there?
I guess this folder is always writable.

 

[Olaf Doschke]

Hi tsh73,

Yes, of course. Or make use of the %AppData% folder, eg %AppData%\yourapp\libraries\.

Working with an update.exe replacing the app.exe that app.exe could/should also be in %AppData% and in the program folder you'd just put some simple start.exe which is only subject to seldom changes, if at all.

It's really a misuse of a DATA folder and opens up many possibilities to manipulate the exe and dlls/flls, but it would work with restricted accounts too.

Bye, Olaf.