Currently on Window's 10 with Visual Studio Build Tools installed, elixir 1.10.4, erlang/otp 22. I'm trying to run an api locally that is built on phoenix/elixir, and am running into an error where argon2_elixir cannot compile, and the error causing it is "nmake" not found in path. I have been trying to research the issue and most solutions say to make sure Visual C++ build tools are installed, and that didn't seem to help the situation.
Any help would be greatly appreciated!
With newer Visual Studio versions, nmake.exe is located in a path which depends on the exact version of the C++ runtime/build tools. To locate it in a mostly version independent fashion, I use a batch script containing the following code snippet:
set VSPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional
for /f %%i in ('dir "%VSPATH%\VC\Tools\MSVC" /b') do set VCTOOLSVERSION=%%i
set NMAKE="%VSPATH%\VC\Tools\MSVC\%VCTOOLSVERSION%\bin\HostX86\x86\nmake.exe"
(for the 64 bit version replace HostX86\x86 by Hostx64\x64).
You can surely adapt this to your needs, for example, for finding the folder to nmake.exe and adding it to the PATH environment variable.
I'm using
cd C:\Program Files (x86)\Microsoft Visual Studio\VB98
vb6.exe /make Project1 /out %1
To basically compile my application, and I'm getting a compatibility issue (Saying doesn't work on my type of windows).
When compiling with the VB6 IDE (Make .exe) that works perfectly on my machine but this isn't, does anybody know how to fix this? Thanks
Error I receive when trying to open executable: "This version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 32-bit or a x64 64-bit version of the program, the contact the software publisher".
& It's a standard EXE application also.
I've tried running it as a administrator, trouble shooting / changing the compatibility to windows XP service pack 2 & 3, still didn't work.
Work prefer a good fix to this, like if there's anything I can do via console as a option or something or some option or anything.
Cheers! Please help ASAP
From the discussion in the comments, I believe the answer here is as follows (as identified by GSerg):
The problem is your use of the /make switch on the command line. The documentation says this about /out:
Outputs errors to a file when used with the /make or /makedll switch.
So, if you used vb6.exe /make Project1 /out Project1.exe, then Project1.exe would actually be a text file containing the error output from the compiler and thus would not be an actual executable, even though it had an .exe extension.
You actually don't specify the output binary when you use /make. The help output from running VB6.exe /? is a little more explicit:
Tells Visual Basic to compile projectname and make an executable file
from it, using the existing settings stored in the project file.
VB remembers the last filename and directory you used for compiling your project in the IDE, and it stores that in the .vbp file:
ExeName32="Project1.exe"
Path32="..\output"
I use a batch file to handle this issue. It sets the path to include both the 32-bit and 64-bit versions of the Program Files directories. Then just reference 'vb6.exe' and the correct one will be pulled from your path.
set PATH=c:"\Program Files (x86)\Microsoft Visual Studio\VC98\bin"
set PATH=%PATH%;c:"\Program Files (x86)\Microsoft Visual Studio\VB98"
set PATH=%PATH%;c:"\Program Files\Microsoft Visual Studio\VC98\bin"
set PATH=%PATH%;c:"\Program Files\Microsoft Visual Studio\VB98"
vb6 /m foobar.vpb
After windows update installed security update KB2687323, my VB6 project fails to load. Displayed error message is "'[project_vbp_path]/MSCOMCTL.OCX' could not be loaded--Continue Loading Project?". Note that the path in the messeage is the vbp file folder path instead of the control's registered path.
Details:
MSCOMCTL.OCX is registered in the usual system32 folder.
The executable produced by exactly the same project, an hour before the update runs fine and loads the updated MSCOMCTL.OCX (I have checked it with Process Explorer).
The security update description states that MSCOMCTL.OCX has a new fixed version. So I checked the project properties for "Upgrade ActiveX Controls" checkbox. I tried it both ways; checked and unchecked to no avail. VB6 IDE refused to load the upgraded OCX.
After hours of effort, system restore, register, unregister cycles and a night's sleep I have managed to pinpoint the problem. It turns out that the project file contains the below line:
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
The version information "2.0" it seems was the reason of not loading. Changing it to "2.1" in notepad solved the problem:
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX
So in a similar "OCX could not be loaded" situation one possible way of resolution is to start a new project. Put the control on one of the forms and check the vbp file with notepad to see what version it is expecting.
OR A MUCH EASIER METHOD:
(I have added this section after Bob's valuable comment below)
You can open your VBP project file in Notepad and find the nasty line that is preventing VB6 to upgrade the project automatically to 2.1 and remove it:
NoControlUpgrade=1
The problem has been resolved by running the following in elevated command prompt:
command :
cd C:\Windows\System32\
regtlib msdatsrc.tlb
or
cd C:\Windows\SysWOW64\
regtlib msdatsrc.tlb
I hope this helps.
The problem:
Microsoft Office 2010 products (or later) install updates that break compatibility of MSCOMCTL.ocx and COMCTL32.ocx. Unfortunately this affects many other programs such Visual Basic 6 SP6 and even Oracle Virtual Box v5. The actual problem is HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0 registry key. You can find detailed background information about this problem here.
Here is another working solution:
The solution assumes you have not damaged your registry by deleting, replacing and re-registering MSCOMCTL.ocx and COMCTL32.ocx without unregistering the Office patch files.
Create a batch file called fix.cmd and place the following commands in it:
regsvr32 /s /u %windir%\SysWOW64\comctl32.ocx
regsvr32 /s /u %windir%\SysWOW64\mscomctl.ocx
del /y %windir%\SysWOW64\comctl32.ocx
del /y %windir%\SysWOW64\mscomctl.ocx
msiexec /passive /norestart /i KB2708437.msi
msiexec /passive /a KB2708437.msi
regtlib %windir%\SysWOW64\msdatsrc.tlb
Download from Security update for Visual Basic 6.0 Service Pack 6: August 14, 2012 the msi file and rename it to KB2708437.msi.
Note: A direct link to the Service Pack 6 download is located HERE.
Run fix.cmd and the problem will be fixed!
What fix.cmd does is to properly unregister and then delete the current MSCOMCTL.ocx and COMCTL32.ocx files, and then apply the latest Visual Basic 6 SP6 rollup patch. In fact, the script enforces the patch to be installed and then re-installed by updating every file, regardless of version. Finally it registers msdatsrc.tlb type library.
Please let me know if this works for you.
======================================================================
Advanced Solution:
If however you have accidentally damaged your registry, you need to get as many versions of MSCOMCTL.ocx and COMCTL32.ocx you can find. Then you need to start from the newer version going back to the older and register and unregister the ocx files.
The latest version of MSCOMCTL.ocx is 6.1.98.39 (v2.1) of May 2012 which is more likely the one installed on your system and causing all your problems.
The oldest (legacy) version is that shipped with Visual Basic 6 on 1998 6.1.97.82 (v2.0), or the one shipped with an early service pack 6.1.97.86 on April 2005.
Example:
regsvr32 /s comctl32.6.0.98.34.ocx
regsvr32 /s /u comctl32.6.0.98.34.ocx
regsvr32 /s comctl32.6.0.81.6.ocx
regsvr32 /s /u comctl32.6.0.81.6.ocx
regsvr32 /s comctl32.6.0.81.5.ocx
regsvr32 /s /u comctl32.6.0.81.5.ocx
regsvr32 /s mscomctl.6.1.98.39.(2.1).ocx
regsvr32 /s /u mscomctl.6.1.98.39.(2.1).ocx
regsvr32 /s mscomctl.6.1.98.34.ocx
regsvr32 /s /u mscomctl.6.1.98.34.ocx
regsvr32 /s mscomctl.6.1.97.86.ocx
regsvr32 /s /u mscomctl.6.1.97.86.ocx
regsvr32 /s mscomctl.6.1.97.82.(2.0).ocx
regsvr32 /s /u mscomctl.6.1.97.82.(2.0).ocx
regsvr32 /s /u %windir%\SysWOW64\comctl32.ocx
regsvr32 /s /u %windir%\SysWOW64\mscomctl.ocx
del /q %windir%\SysWOW64\comctl32.ocx
del /q %windir%\SysWOW64\mscomctl.ocx
msiexec /passive /norestart /i KB2708437.msi
msiexec /passive /a KB2708437.msi
regtlib %windir%\SysWOW64\msdatsrc.tlb
WARNING:
Do not search the internet for those files. To find different version of the OCX files download and extract official Microsoft Installer packages such as the following:
2005 Apr - Microsoft KB896559
2008 Dec - Microsoft KB926857
2009 Apr - Microsoft KB957924
2012 May - Microsoft KB2708437
It is also recommended to run CCleaner version 4.0 or later to fix any other ActiveX related problems on your computer.
To Fix the Problem:
Make a Batch file with the following code:
#echo off
reg query "HKEY_CLASSES_ROOT\typelib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.1"
if %errorlevel%==0 GOTO DELREGKEY
if %errorlevel%==1 GOTO REGISTEROCX
:DELREGKEY
reg delete hkcr\typelib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0 /f
:REGISTEROCX
if exist %systemroot%\SysWOW64\cscript.exe goto 64
%systemroot%\system32\regsvr32 /u mscomctl.ocx /s
%systemroot%\system32\regsvr32 mscomctl.ocx /s
exit
:64
%systemroot%\sysWOW64\regsvr32 /u mscomctl.ocx /s
%systemroot%\sysWOW64\regsvr32 mscomctl.ocx /s
exit
I use win7 and has same problem.
Today I solved this problem, through loading with many error with my project just give order to continue after that goto Project=> Component => Microsoft Windows Common Controls 6.0 (SP6) then save the project (file use was c:\windows\syswow64\mscomctl.ocx)
The solution for me is to install this VB6 patch. I'm on Server2008 (32-bit).
http://www.microsoft.com/en-us/download/details.aspx?id=10019
It makes me sad that we're still talking about this in 2014... but here it is. :)
From puetzk's comment: These are outdated: you want to be using Microsoft Visual Basic 6.0 Service Pack 6 Cumulative Update (kb957924).
I do not find NoControlUpgrade=1 on my vbp project.
Instead, I develop on both xp and windows7 x64. When I moved the project from window 7 to xp, the error occurred.
From what I find out, these are different:
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX
I just changed the #2,1 back to #2.0 on the vbp file and it can run immediately.
These kind of problems occurred before, so hope Microsoft explain and solve them accordingly.
Thanks.
On some computers, I've found that the "2.0" version of MSCOMCTL.OCX has been added to the ActiveX KillBits list, and thus the control won't be allowed to load or run--even in design view. Updating to the "2.1" version will resolve this, and is the recommended solution.
In critical cases, where you have to run a program "now", or you don't have access to source code, or the control is used 400 times in a large modular project, you can use a "big hammer" method and update the registry to re-enable the control:
**
WARNING: Editing the Windows Registry in the wrong way can mess up your computer big time. If you're not sure what you're doing, please leave it alone, or get some schooling before you proceed.
**
The clear the KillBit:
Run Registry Editor (regedit.exe or regedt32.exe)
In the left-hand panel, navigate to key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility{BDD1F04B-858B-11D1-B16A-00C0F0283628}
In the right-hand panel, double-click on “Compatibility Flags”, change the value from Hex 0x400 (Decimal 1024) to 0, then click OK.
Launch the application that uses the "2.0" version of MSCOMCTL.OCX; it should run as designed.
The ActiveX KillBits list is intended to give Microsoft the means to disable controls that are deemed to be a security risk, and they've designed the mechanism such that the ActiveX KillBits list will be re-applied to the system at seemingly random times, in addition to when an Update is installed, so you'll need to plan for re-applying the registry change. Making a registry merge file works pretty well, but it's not something you want to do everytime the app runs, because it's not a quiet process (there are ways to do this quietly using Windows Scripting, but you'll have to learn that on your own). The KillBit is checked only when the control is requested by an application, so you're safe from resets once the application launches and loads the control.
You may try to check your registry
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}
If it is 2.1 version, it will cause cannot load MSCOMCTL.OCX issue.
You may restore to 2.0 verion (not only copy the file, you should unregiser 2.1 and register the restored file)
Or
You may try latest 2.2 version
https://support.microsoft.com/en-us/kb/3096896 (file date: 5-Nov-2015)
https://www.microsoft.com/en-us/download/details.aspx?id=50722
Some version information :
6.0.88.62 (2.0)
6.1.97.82 (2.0)
6.1.98.34 (2.1) <<< not work for me
6.1.98.46 (2.2)
Same problem with VBA Macros using MSCOMCTL.OCX.
Problem still unresolved with solutions like "reg/unreg mscomctl.ocx"
Used the Info above of Rumi.
Edited my *.dot file, search for #2.0#0, change it to #2.1#0
--> it worked
I had this problem and tried many different solutions. They didn't work for me although I think this error occurs for a couple of different reasons. My solution is in my answer to this question here:
https://stackoverflow.com/a/15785253/2240058
Its worth a try if nothing else is working for you.
This problem mysteriously appeared for me today. I hadn't done any Windows updates, so I don't know the cause.
This fixed it (in elevated command prompt):
regtlibv12.exe msdatsrc.tlb
For me, this solution worked like a charm:
http://home.pacific.net.hk/~edx/bin/readmeocx.txt
Fix these two lines like that:
Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; COMDLG32.OCX
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
Search the files (.vbp and .frm) for lines like this:
Begin ComctlLib.ImageList ILTree
Begin ComctlLib.StatusBar StatusBar1
Begin ComctlLib.Toolbar Toolbar1`
The lines may be like this:
Begin MSComctlLib.ImageList ILTree
Begin MSComctlLib.StatusBar StatusBar1
Begin MSComctlLib.Toolbar Toolbar1`
I recently put all my source on a windows 8 32 box. Had the issues loading mscomctl.ocx with existing projects.
I created a new project and add the common control (all). save the project and reloaded it no problem.
when you compare the project headers new vs old the old one uses reference=*\blah blah. I found removing this a replacing it with the Object={blah} sorted out the problem.
I continued to have problems after trying the things suggested here. In the end, it turned out that I had the wrong version of mscomctl.ocx in my SysWOW64 folder. I found the following versions kicking around:
Mar. 09, 2004 01:00 AM 1,081,616 mscomctl.ocx
Jun. 06, 2012 07:59 PM 1,070,152 mscomctl.ocx
Dec. 08, 2015 03:57 AM 1,070,232 MSCOMCTL.OCX
Getting the last one (1,070,232) solved this problem for me.
I had similar trouble, have a program running for last 10 years written in VB6, now client wanted to make some major modifications, and all my machines which are now windows 10; failed to open the project, it was always that nasty mscomctl.ocx error. I had done lot of things but could not solve the problem. Then I thought the easy way around, I downloaded the latest mscomctl (
Then opened a new project, added all the components like mscomctl, activx controls etc, saved it and opened this newly created project file in Notepad, then copied the exact details and replaced in the original project.... and bingo! The old project opened up normally without any fuss! I hope this experience will help someone.
In my case didn't work any solution above. Near to give up, removed any reference (using Arvo Bowen's fix.cmd file) and tried pasting mscomctl.ocx (version 6.1.97.86) in C:\Program Files (x86)\Microsoft Visual Studio\VB98 folder. It worked finally after more than 4 or 5 hours fighting for a solution.
I am trying to use this tutorial from MS to verify I can build a .cpp file from the command line on my system. I seem to be having problems with my VS Command Prompt. It cannot find cl.exe or the needed include files. I added C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin and C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE to my path so it would find cl.exe. Now my error is:
test.cpp(1) : fatal error C1034: iostream: no include path set
Isn't the whole point of the VS Command Prompt to setup all these environment vars for me? Why isn't it setting it up properly?
I'm not sure exactly what your problem is but you might want to do the following to help determine the actual cause.
You may have noticed that the VS command prompt shortcut is a bat file. The first line is
#echo off
Change it to
REM #echo off
Run it again and see if you get any errors. If you don't it may be in one of the processor specific batch files to know which one that is look for the call to other batch like this.
C:\Program Files\Microsoft Visual Studio 10.0\VC>call "C:\Program Files\Microsof
t Visual Studio 10.0\VC\bin\vcvars32.bat"
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
Again REM out the #echo off in the batch and then run it again and see what errors you get.
Update from comment
The error ERROR: Cannot determine the location of the VS Common Tools folder
means your missing the Environment Variable %VS100COMNTOOLS% which is usually set to
"c:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\"
You can simply add it back using system properties -> Advanced -> New (under system variables)
See this superuser question for more on environment variables
I just figured it out. Thanks to Conrad Frix for the debugging tip.
It is surely due to some lovely security policy I have here on my workstation. Running the shortcut as administrator works. My account is a local admin account, but the admins do all kinds of weird stuff to our machines here...sigh. So, much of our development has to happen by "elevating".
Note, I was able to change the shortcut to run as under administrative privileges by selecting Properties->Advanced->Run as administrator.
Microsoft's C++ compiler and linker seem to have an odd relationship with mspdb100.dll. When run from the IDE, of course, the compiler and linker work fine. When running either one from the command line, I get an error.
No problem, I located the DLL and copied it to the directory. Now the compiler works fine, but the linker dies.
I could solve the problem by adding "%VS10%\Common7\IDE" to my PATH, but for various reasons (performance, system purity, OCD, etc), I don't want to do that. Why is this setup so touchy, and is there anything else I can do to solve it?
try running path\to\VC\bin\vcvars32.bat from within your current shell first. This should ensure your command-line setup will match the IDE-setup.
This is not a permanent fix -- you need to do it every time you launch a new shell.
You could probably also find some way to add everything that's in that .bat permanently to the environment variables, but.... like you asked, why the heck doesn't the MS install do that already?
Add Microsoft Visual Studio 10.0\Common7\IDE to your path, and this issue will not exist any more. You will be able to build without running this silly batch file every time.
I noticed when I installed Microsoft Visual Studio 2010 Express that under the "Microsoft Visual Studio 2010 Express" folder in the Start Menu, there is a link to "Visual Studio Command Prompt (2010)", which sets up all the necessary environment variables when opened. That way you shouldn't have to edit you PATH variable.
This shortcut runs the following:
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
If it's not convenient to use the shortcut, perhaps you could learn something of use from investigating what this .bat file does?
I met same error,it is because we installed a vs2010 x86 version to a x64 system...
Open two folders:
C:\Windows\Microsoft.NET\Framework\v4.0.30319
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin
You will find two cvtres.exe. Righ click, select Properties, then Details. Delete the older version, and cmake will work well.
I hope this may help you.
Thanks to "zhoudongao" # http://bbs.csdn.net/topics/390121452?page=1#post-394768226.
I know this is a bit dated but if anyone's looking for a way to get compiler running from command line; here's what I did to get it running.
I'm using Win7 32bit and Visual Studio 2010. I created a small batch file in C:\Windows. open cmd prompt at C:\Windows as admin, then type the following:
copy con cl.bat
#"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\vcvars32" %1 %2 %3 %4 %5 %6
#"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\cl" %1 %2 %3 %4 %5 %6
then press f6 and hit enter again.
Obviously the path you will use is the install path to where you installed Visual Studio.
You now have working command line compiler from any location or directory in windows. To test this go to desktop and open cmd prompt as admin; I prefer to use Ctrl+Shift and right click then choose open command prompt here.
At command prompt type "cl" (without quotes) and hit enter. you will see a message "Setting enviroment for using Microsoft Visual Studio 2010 x86 tools"
type "cl" and hit enter again and you will get your compiler info. you're all set to compile.
enjoy!
Maybe it will help somebody...
I solved this problem by adding
PATH += %PATH_TO_VS_IN_YOUR_SYSTEM%/Common7/IDE;
to nvcc.profile.
Of course, %PATH_TO_VS_IN_YOUR_SYSTEM% is actual path to Visual Studio in your system.
Old, but maybe still valid:
For me "C:\Windows\System32" somehow got missing from the PATH variable.
Adding the missing folder to the path solved this error. See also VS2010 command prompt gives error : Cannot determine the location of the VS Common Tools folder
if you try to run the tools from the windows cmd.exe directly then you need to set the environments by running the vcvars32.bat file which will set the environment for you. instead you can run the visual studio command prompt which will run vcvars32.bat automatically. if you still have the problem then it's definitely the famous path variable problem.
make sure the "path" variable in the environment has the "c:\windows\system32\" value added to it , because the .bat file will need it to configure the VC tools.
this problem and the like usually happen because of installing many development platforms on the machine which might probably change the path variable.
check this..
https://schrievkrom.wordpress.com/2011/01/25/error-cannot-determine-the-location-of-the-vs-common-tools-folder/