When I try to instantiate a VFP COM (OlePublic) DLL from my .NET web app running in IIS on Windows server 2016 I get:
Retrieving the COM class factory for component with CLSID {A55C4127-DDCB-4E5F-B69C-A7EAC83A83DC} failed due to the following error: 80004005 Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)).
I was able to track it down (using Simon's comment) to it not being able to find vfp9r.dll:
Those files got installed w/ my InstallShield package under C:\Program Files (x86)\Common Files\Microsoft Shared\VFP:
vfp9r.dll
VFP9RENU.dll
vfp9t.dll
Why isn't "it" searching that dir? I got one server it is finding them under program files and another that isn't. How does that magic work?
update
if I install VFP 9, it will search that dir & successfully load it. So what is the VFP 9 install doing to my machine to tell "it" to search that dir not just the current dir & \SysWow64? 🤔
workaround
import these registry keys:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VisualFoxProRuntimeMT.9\Shell\Open\Command]
#="C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VFP\\vfp9t.dll"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VisualFoxProRuntime.9\Shell\Open\Command]
#="C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VFP\\vfp9r.dll"
(save the above 'script' as a .reg file and double click it to import it)
how I figured this out:
Hyper-V checkpoints so I could quickly go back and forth from a working to a non-working vm along w/ resetting after I did some test to find the minimal workaround
Search & export registry key w/ vfp9r.dll or vfp9t.dll
Compare exports via Notepad++ Compare Plus Plugin
The diff for vfp9t.dll was smaller so that was helpful. I grabbed the first key and that worked. Then I searched for the same-ish path for the vfp9r.dll export and grabbed that key.
I encounter a problem using the windows visual studio "lib.exe". (in my case, located under C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin )
Actually, it seems I have too many objects to merge in that lib, which makes a very long command line... too long for Windows.
My command line looks like:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\lib.exe /NODEFAULTLIB /SUBSYSTEM:WINDOWS /out:mem/libxps.lib mem/bmWrapper.obj mem/bmWrapperWinGdi.obj mem/bmWrapperInternal.obj ... and lets say 200 arguments here
This gives the error:
command line is too long.
First, what is the proper way to create a .lib (static) on windows? I saw some ways with a def file from a dll (dynamic).
Second, if I'm on the right path, how to get around such an issue?
I want VS let me use remote debbuging on Linux machine. I have downloaded necccessary packages and tools for this goal, so, I've denoted output and build directories. Build directory is created always successfully, but next step is Makefile that is not run, because CMakeList.txt is not sent from Windows machine.
I text in Additional Sources To Copy that this file should be copied, but I cannot know a reason of unsuccessful action. Only make command notifies me that this file does not exist. I guess this problem is in Visual Studio!
I have solved the problem and totally sure, that these things will exactly help you out!
https://developercommunity.visualstudio.com/content/problem/447310/2019-makefile-project-doesnt-copy-source-on-build.html
Fix the file
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Application Type\Linux\1.0\Linux.Makefile.targets
243 line, add this:
<Target Name="PrepareForNMakeBuild" DependsOnTargets="SetBuildDefaultEnvironmentVariables;SetUserMacroEnvironmentVariables;_RequiresRemoteConnection;_CopySources;">
Never use '~' when you denote pathes on remote machine in properties of debbuging, only like
/home/machine_name/project_name/$(SolutionName)/$(USERNAME)
I need to change an installer script to put the files into C:\Program Files (x86) for 32 bit and C:\Program Files for 64 bit.
I'd hoped $PROGRAMFILES was the right variable to use but from the docs, this always points to C:\Program Files (x86).
"The program files directory (usually C:\Program Files but detected at runtime).
On Windows x64, $PROGRAMFILES and $PROGRAMFILES32 point to C:\Program Files (x86)
while $PROGRAMFILES64 points to C:\Program Files. Use $PROGRAMFILES64 when
installing x64 applications."
I'm familiar with how to test the system at install time with ${If} ${RunningX64} but there are dozens of $PROGRAMFILES entries in the script so I'd like to avoid that approach if at all possible.
Is there a different variable that gets set automatically?
No there is no program files variable that matches the system. $PROGRAMFILES matches the bitness of the installer.
If you need to match the bitness of the system then you have to create your own variable and initialize it in .onInit. $PROGRAMFILES64 probably degrades to $PROGRAMFILES32 on 32-bit systems but I'm not sure if I would endorse using it like that.
This is usually not an issue because you should be using $InstDir when referencing the destination folder.
I am trying to install Spark in Win7 and am getting an error.
These are my environment settings:
SPARK_HOME : C:\spark (this is where I have unzipped the spark files)
JAVA_HOME : C:\Program Files\Java\jdk1.7.0_71;
SCALA_HOME: C:\Program Files (x86)\scala
PATH : C:\Program Files\Java\jdk1.7.0_71\bin;C:\app\Sampad\product\11.2.0\dbhome_1\bin;C:\Python27;C:\Program Files\Python27\;C:\Program Files\Python27\Scripts;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Java\jdk1.6.0_45\bin;C:\Program Files\nodejs\;C:\Program Files\Python27;C:\Anaconda;C:\Anaconda\Scripts;C:\HashiCorp\Vagrant\bin;C:\Program Files (x86)\scala\bin;C:\spark\bin;
HADOOP_HOME : C:\winutils; (set this after reading this blog
Please let me know what mistake I have made. Thanks in advance.
I installed java and spark in folder with out spaces and I am using windows 10.
In my case I added
JAVA_HOME=C:\Java\jdk1.8.0_191\bin
so it was trying to search for executables in "C:\Program Files\Java\jdk1.8.0_191\bin\bin"
make sure to add variable as
JAVA_HOME = C:\Java\jdk1.8.0_191
and In path environmental variable add
%JAVA_HOME%\bin
""same for SPARK_HOME""
It is working for me now !!!
Probably, it happens, because different java versions:
JAVA_HOME : C:\Program Files\Java\jdk1.7.0_71;
C:\Program Files\Java\jdk1.6.0_45\bin
Instead of "C:\Program Files\Java\jdk1.6.0_45\bin" use "%JAVA_HOME%\bin"
Spark: Trying to run spark-shell, but get 'cmd' is not recognized as an internal or
Try modifying the spark-shell2.cmd file first line from
#echo off
to
rem #echo off
For me it showed me that it was trying to load a file from c:\spark\bin\bin on the following line
"%SPARK_HOME%\bin\spark-submit2.cmd" --class org.apache.spark.repl.Main --name "Spark shell" %*
In my env %SPARK_HOME% was set to c:\spark\bin. My installation is at c:\spark\bin
So I set the %SPARK_HOME% to c:\Spark and added %SPARK_HOME%\bin to my PATH.
you need to setup JAVA_HOME and path
the first thing is you have to go
edit system Environment variable -> Environment variable -> under the User varibales for <user>
add New
1. JAVA_HOME = C:\Program Files\Java\jdk1.8.0_191
In path
add %JAVA_HOME%\bin
2. SPARK_HOME = C:\spark //*spark is my folder where i have installed spark*
In path
add %SPARK_HOME%\bin
This will fix your problem
For me everything that is specified above was correct still it was not working.
The reason I found is all the environment variables where added in "system variables" section so when I added them in "user variables" section it started working.
I added JAVA_HOME,SPARK_HOME, HADOOP_HOME and PATH in user variables.
I had the same problem, but I solved it by correctly setting up JAVA_HOME environment variable. Basically, you need JAVA version 8 to run Spark. So you need to install JAVA 8 and properly set up the environment and the path just like the way you set up SPARK_HOME. For example variable name: JAVA_HOME, variable value: C:\JAVA. Then you go to the path and set up the path for java as: %JAVA_HOME%
I had similar issue, I reinstalled java(new version) and corrected JAVA_HOME. This resolved the issue for me
I had same issue on windows 10, make sure that only JAVA_HOME value is absolute path, rest everything is relative to %JAVA_HOME%
One of the reasons is either JAVA_HOME or SPARK_HOME has a space in the path. In this case :
"SCALA_HOME: C:\Program Files (x86)\scala"
Here after "Program Files (x86)" has space in its path. Try to move files to location where there won't be space involved in the full path. In my case I had space in JAVA_HOME path.
In my case I noticed my JAVA_HOME env variable had semicolon(;) at the end of the path resulting in above mentioned error (as this was leading to incorrect path resolution).
I could find this issue by commenting #echo off.