Filer.dll - need to register

[Bryan - Gendev]

I am using a 'complex' program routine based on a modified filer.dll in my application.

All runs fine on my 2 PCs but a user reports that he is getting a 'filer.dll unregistered' error on his. Others may not have gone that deep down in my programs routines.

Is there any need to register filer in my installer to take care of this.

I do have VFP installed on both PCs.

GenDev

 

[Olaf Doschke]

Hi GenDev,

yes, there is the need register this dll.

See, you create a filer object via

oMyFiler = CREATEOBJECT('Filer.FileUtil')

There is a dot in that class name, which is a sure sign it's an OLE class and not a native foxpro class. No class you create within foxpro can have a dot in it's name, try it, it's not allowed.

That said ole classe don't need to have a dot in their name, but typically have.

So, as said initially, yes, you need to register filer.dll in your setup. You don't need on your computer, as VFP installation did that.

I don't find a mention of filer.dll in the list of redistributable files, but also don't find it in restricted features and/or files. As it's within /Tools/ I'd say it's legal to redistribute.

In Installshield in the Installation designer step take a look at step 2 (Specify Application Data), subitem "Dependencies" while that sections says it's only part of the full Installshield version Installshield does detect the need to register a dll.

Go into subitem Files. Somewhere in "destination computers files" you'll have the filer.dll. Now right click on it, choose properties. There is a tab "COM & .NET Settings", There is a option "Registration Type". That should be "Extract COM information". That should be sufficient, you may also try "sel-registration". I'm not sure if that option is only possible for EXE files, but I know every COM dll has a registration function embedded, so it could work.

Bye, Olaf.

 

[Bryan - Gendev]

I use the Inno compiler. It claimed not to find the file in Tools so I've used a runregsvr32 filer.dll in my code. My user doesn't have a new exe to test yet.

Regards

GenDev

 

[Olaf Doschke]

It's not directly in the Tools folder, the Tools folder contains several tools. Why don't you simply inspect the folder yourself?

? File(Home()+"tools\filer\filer.dll")

besides filer you have other tools in there:

cd (Home()+"tools\")
getfile()

see?

Bye, Olaf.

 

[Bryan - Gendev]

Sorry Olaf,

You misunderstood.

I HAVE inspected and found filer.dll.

It's the compiler which for some reason says it is not there. But of course it is...

Thanks

GenDev

 

[Mike Lewis]

GenDev,

With Inno, I generally move all the required DLLs, OCXs and similar files to a specific folder, just below the Inno SourceDir. I then hard-code the relative path to that folder in the Inno script.

For example, if the application's main directory is c:\MyApp, and the DLLs are in a sub-directory named Install_Source, the script might contain something like:

SourceDir = "c:\MyApp"
Source: "Install_Source\Filer.DLL"

You'll need to add the flags to tell the system to register the DLL, but I assume you already have that.

Hope this will help.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Sorry for the misunderstanding, but then why do you grab the files for the setup from where they are. Like Mike I'd always put together all files needed. No matter if doing the setup with inno or installshiled or something else.

Bye, Olaf.

 

[Bryan - Gendev]

Thanks Guys,

Again I do have a [tools]folder but chose to get it direct.

Putting it in [Tools]- Inno compiles correctly.


GenDev

 

[IlyaRabyy]

Colleagues,
Correct me if I'm wrong, but AFAIK, DLLs do not need to be registered as long as the Program (your EXE) "knows" where to find it - that is to say it's enough to have this DLL in the locations listed in the PATH command for VFP, or in the PATH system variable.

I usually enforced the placement of the DLLs into the EXE's own directory in the Setup kit (or even in the work instructions for the customers' Sys Admins, like "Copy the entire contents of the Master CD into a dedicated directory on your local or network drive") - and that did it, without registration.

This is how it worked in WinOS environ from Win 3.1x to Win9.xx (95...ME)to WinNT4/5.xx (2K...XP).

Has anything changed in this respect (besides further drastic reduction in the End User's access rights) in WinNT6?



Regards,

Ilya

 

[Olaf Doschke]

Ilya,

this is not true for OXC or COM DLLs, they need to be registered. Filer.dll is used as COM object in Filer.scx

Bye, Olaf.

 

[IlyaRabyy]

Oh, that's what it is!
Then including Filer.DLL into the setup kit should do it.



Regards,

Ilya

 

[Bryan - Gendev]

Further to all of the above - i have had filer being registered by my Inno setup file.

Now a user has told me he gets an error message when he runs the setup. So I happen to have had a refurbished Acer PC delivered yesterday and intend to use it as a trial PC including the One Instance code mentioned in another thread which now works on my users PC.

Well, this new PC now gives me the 'can't register' message on running Setup.

When I run the deeper code in the app that uses Filer I am offered a 'do you wish to install?' message.

When I click [Yes] I get an error - Class Definition FILER.FILEUTIL is not found.

So 3 questions.

1 Why do some PCs not allow registration in a setup? ( Another OCX is registered OK.)

2 Why does the install offer throw up an error.

3 What can I do to get around this - the filer object ( as modified by me) is a nice way for my users to find the files thay want to use in my app.

Thanks

GenDev

 

[Olaf Doschke]

If the OS is XP, then a setup does not force to be done with admin permissions, so it can fail to do things only admins can do, if the setup is not started by an admin.

Since Vista every setup is forced to be done by admin with admin credentials and permissions.

The other issue you could have is 32bit vs 64bit. You need to use the right regsvr32.exe to register the dll, there are two versions of this in a 64 bit system. As Filer.dll is a 32 bit dll it should go into SysWow64, the 32 bit subsystem folder on 64bit oses ad be registered with the regsvr32.exe from there.

I don't know inno setup, Mike says you just need to set some flags to make it register a file, maybe it's failing on the 32bit/64bit difference on a newer OS.

That's the only differences I know of, which could make a registration of a COM dll during install fail. There might be other things I'm not aware of.

By the way: To test setup an easier way than buy a new pc is to install virtual pc. Even from the legal point of view: In fact you need a seperate OS license for installing Windows into a virtual PC, but Windows versions come with a 30 day grce period and you can use that and it's totally legal to do so, to install the same OS than you have installed on your real PC into the virtual PC. And that gives you the chance to test all the OSes you have and in their clean and bare state, without foxpro itself installed.

Bye, Olaf.

 

[Mike Lewis]

Mike says you just need to set some flags to make it register a file, maybe it's failing on the 32bit/64bit difference on a newer OS.

Yes, you use the regserver flag to tell the Setup program to register the component. But it's the same flag for both 32-bit and 64-bit installs. My understanding is that Inno decides whether to install in 32-bit or 64-bit mode, depending on the processor.

I've not had any difficulties in using Inno to install 32-bit components on 64-bit systems. Most of the issues I've seen are to do with permissions.

By the way, I agree with Olaf's suggestion of using a virtual machine rather than a dedicated PC for testing. The nice thing about it is that you can simply delete it and re-install it, so you are free to make any changes you like to the configuration.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

The best bet to find out what is happening during install maybe is to process monitor and let it monitor the setup.exe during the setup process. Process monitor can monitor, what API calls are done and what files are opened or written and what other processes including regsvr32 are called by it.

http://technet.microsoft.com/en-EN/sysinternals/bb896645

And well, in ragard of your understanding, Mike, "Inno decides whether to install in 32-bit or 64-bit mode, depending on the processor"

I hope this is only halfways the truth and I'm quite confident the decision of inno also considers the OS architecture, but mostly the DLL architecture.

Possible combinations:

(CPU/OS/DLL) = (32/32/32):
No problem, no choice, system folder is 32bit.

(CPU/OS/DLL) = (32/64/32)
impossible, because a 64bit OS does not install on a 32bit CPU.

(CPU/OS/DLL) = (64/32/32)
Unusual, as nowadays the OS mostly is bundled with hardware, so you don't get a 32bit OS on 64bit hardware, but it's possible to install a 32bit OS on a 64bit CPU, as CPUs are backward compatible.

This will not make use of the CPU power, but has no problem for the install, as there again only is a 32bit OS system.

(CPU/OS/DLL) = (64/64/32)
Most common nowadays. It's problematic, if the installer does not detect a 32bit dll, and does not register it appropriately. If the installer itself is 32 bit there is no problem, as an OS redirects access of 32bit processes to the 32bit subsystem folders, including installer processes and including what regsvr exe it uses. If the installer itself is 64bit it must be aware of the problem, the OS does not redirect a 64bit installer to the usage of the correct 32bit regsvr version, the OS will only be aware of the wrong usage, if it's already too late, if a 32bit DLL is registered via 64bit regsvr, and that should error, perhaps exactly the error you experience, gendev.

(CPU/OS/DLL) = (64/64/64)
no problem obviously, and it's the only combination you can install a 64bit DLL anyway. OS and CPU also must be 64bit. We don't have that situation, as there is no 64bit VFP, and also Filer.dll is a 32bit DLL.

So, gendev, install process monitor, configure it to monitor your setup, however you call it, before you call it and then see what process monitor finds out. My guess is, the newest innno version you may use is a 64bit process itself, and fails to use the correct way to register filer.dll.

Well, or the problem simply is, you didn't even specify filer.dll must be registered. But then you wouldn't have an error during installation.

Bye, Olaf.

 

[Bryan - Gendev]

I appear to have found the solution.

I saw in procmon that the regsvr32 last line with filer.dll in it was followed by MSVCP71.DLL -this gave a NOT FOUND error.

Looking in

http://fox.wikis.com/wc.dll?Wiki~Filer

is saw the question - 'In VFP9 Filer.dll is msvcr71.dll and msvcp71.dll dependent?'

On a hunch I added MSVCP71.DLL to my setup file list putting it into the app folder along with filer.dll - and the result was

SUCCESS

Filer was registered with no error message and works within my app.

Thanks for all the contributions above.

GenDev

 

[Olaf Doschke]

That's good news, gendev.

Glad you found out via procmon. You can't find this info in the VFP help, nor do you find msvcp71.dll in the Tools/Filer folder. It's not always needed for C++ DLLs, only if they are multithreaded, dynamic link, and also for debug mode DLLs.

http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.71).aspx

One other tool could also help find dependent files: Dependency walker.

Bye, Olaf.