MSVCR71.DLL

[sdocker]

Hi,

I just started getting the message attached whenever I tried to run an exe created with VFP 9.0.

I tracked it down to the file msvcr71.dll that was in a folder that was probably created accidentally, and the file moved there accidentally. The errors started when this folder was deleted and stopped when it was restored.

The OS knows where the file is, even though it doesn't belong there.

My question is where does it belong? ie. where was it originally when VFP was installed.

Thank you.

Sam

 

[Mike Lewis]

On my development machine, it's in the %SYSTEM% directoy (the actual name and path of which will vary with the version of Windows).

But it could be installed anywhere where the application can find it. When distributing my own applications, I usually install it in <Program Files>\Common Files\Microsoft Shared\VFP. But I've also installed it in the application's own executable directory.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Come to think of it, there is also an issue with the registration of MSVCR71.DLL. It's not unusual to install it in the application's own executable folder (as mentioned above). But, according to this, during the installation process it needs to be somewhere where Windows can find it so that it can register it. That's why you might install it in the System directory or the Common Files directory referred to above.

The Wiki article in the above link suggests you install it in one of those shared directories on a temporary basis so that it can be registered, and then remove it and install it in the application's directory. The article shows how to do that using Inno Setup, but the issue is not specific to Inno; the principle is the same with any installer.

I don't know if this information is relevant to your problem, but it might be something to keep in mind.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[sdocker]

Mike,

Thank you.
I made sure all the system folders contained the file, but it still doesn't work, if it is not in the user created folder.

Is there a way to determine/change the search path?

Sam

 

[Mike Lewis]

To determine the existing search path, open a DOS command window, and type [tt]PATH[/tt].

You can use the same command to change the path, but it's slightly tricky, because the chances are that you already have several directories in the path, and you don't want to accidentally change any of them while you are adding a new one.

A more interactive method is to go to Control Panel / System (or System & Security in some versions) / Advanced (or Advanced Settings) / Environment Variables. That will take you to a dialogue where you can edit the path variable.

Note that I am talking about the Windows path here. This has nothing to do with the VFP path, which isn't relevant to this discussion.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If you put this dll into the %system% folder, where did you do that and how?
If you manually open up windows explorer and copy it there, it doesn't really get there, it is copied to your profiles virtual store folder.

The file most probably was put whereever it works during a setup and also registered there, so it is found there, as the registry points to it.

But you can put it into many places and I'd put it into your apps folder. It's not only unusual, but even recommended.

Bye, Olaf.

 

[sdocker]

Hi Mike,

I used your instructions and discovered that many of the PATH variables contained the file, and the relevant folder was not in any of the PATH's. SO, it was obviously not a PATHing issue. I did however figure it out.

The app uses MSINET.OCX which requires registration. To accomplish this, so the app worked from workstations, I created a WorkStationSetup.exe. This setup created the folder and registered the OCX.

All I had to do was uninstall the WorkStationSetup and the all is working fine. I'm think it may revert to the original registration on my machine.

I'm mentioning all this in case it may help someone else in the future.

Sam

 

[Dan Olsson]

Come to think of it, there is also an issue with the registration of MSVCR71.DLL. It's not unusual to install it in the application's own executable folder (as mentioned above). But, according to this, during the installation process it needs to be somewhere where Windows can find it so that it can register it. That's why you might install it in the System directory or the Common Files directory referred to above.

IMHO, that should not be necessary. I have installed my app (which been up and running for 20 years now) in hundreds of places and I always install ALL dlls in the app-directory itself with no problems at all.

 

[Mike Lewis]

Sam: Glad to see you've solved the problem.

Dr Dolittle: Yes, I also normally install the DLLs in the executable directory (as I mentioned above). But there are sometimes advantages in storing them where they can be shared with other applications. I've done that with at least one of my applications, although it was an unusual case.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

>where was it originally when VFP was installed

In regard to that specific question a counter question: Didn't you install VFP? Did you copy the installation over?
VFP does not installs several things in HOME() but into the system and into a Microsoft Shared folder. Despite how easy it is to copy over the installation you better simply install VFP, if you move to a new development pc.

And I also thought your question was more specific on some application programmed with VFP, not VFP itself, it doesn't really matter where VFP itselfs installs the C runtime, your setup has to do so and following walkthroughs and help file on application distribution you'd use installshield express and its C runtime merge module and wouldn't need to know where that installs the c runtime.

So how VFP itself installs the c runtime doesn't matter, it's not the only viable way to do so. To prevent DLL hell, which isn't about how many DLLs are installed but about how different versions are needed and in the worst case ore overwritten you simply disregard anything else but installing the runtime a secondary, third or more time into your own app folder only.

The only thing that can only be put in one place for all is some registered component. Assemblies are advanced in that way, as the global assembly cache can hold several versions of the same DLL, it stores them with different names in the file system, but this doesn't work for COM/OCX.

Does the c runtime have some COM server at all? I actually don't think so, but you find usages of regsvr32 mentioned even by Microsoft staff. Anyway, you don't need to register that DLL for VFP nor for your own app, it'll be sufficient to be in the folder of the application. As you identified the problematic component wasn't really that DLL but an IE component.

Bye, Olaf.

 

[sdocker]

Thank Olaf,

Sorry to admit, but some of your comments are bit above my expertise.

I do understand the difference between my VFP installation and a distributed app, but until I figured it out, i had no way of knowing how far the problem extended.

Sam