I am trying to follow examples from Gray Hat Hacking where 32 bit C programs are compiled in visual studio. My issue is that visual studio 2017 developer prompt opens with errors like the following
'type "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.isolation.ini"' is not recognized as an internal or external command,
operable program or batch file.
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
'dir "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\vsdevcmd\ext\*.bat" /b /a-d-h /on' is not recognized as an internal or external command,
operable program or batch file.
I also understand that I may have to add the location of cl in the environment variables and I may have to run the vcvarsall.bat file. I tried all these with no significant progress.
My objective is to compile and run 32 bit as well as 64 bit C programs on my 64 bit platform on visual studio. I would appreciate if anyone could help me with this issue.
For anyone who is running into the same problem, that I encountered. I found a solution to this problem, but I have no guarantee that this would work for everyone.
I must admit, configuring visual studio to run C programs is one heck of a job!!! One would go nuts trying to set up the right environment variables for a smooth execution of a C program. Once you install visual studio with the Build tools, the right SDKs (preferably the latest ones) and the latest VC++ toolset, the following environment variables will have to be set:
LIB
INCLUDE
PATH
Set these environment variables for both system and user (to be on the safe side) and if any file is missing, find its location (Most likely, their location would be in Windows Kits or somewhere within the Visual Studio folder. Expect some hunting!!!), then try to compile until it becomes successful.
If any one else has a better solution, I would request them to post it here!!!
Related
I'm going to use the HelixToolkit.SharpDX with VS2017 in my Windows 10 workstation, when I attempt to build the solution, it will prompt the Assertion Failed error with "No fxc.exe found".
I have checked the installation option, Windows SDK has been included, nand I have downloaded and install again, and I can see the fxc.exe in "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64" & "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86" folders, so it should be available for any windows version, but unfortunately, the same error reported.
However, I have also installed VS2017 in another Windows 7 machine, it works fine, and it has the fxc.exe in the same folder as my Windows 10 workstation, but it can be located by VS2017.
Is there any setting in VS2017 to locate the fxc.exe?
Or how can I fix this issue?
Copy fxc.exe in Bin\10.0.xxx\x86 to Bin\x86 to fix this issue. Because the HLSL compile tool hard coded the path.
One can find solution on helix toolkit github page.
Visual Studio 2017. Windows 10 SDK.
Missing fxc.exe issue with newest Windows 10 SDK:
Copy fxc.exe in C:\Program Files (x86)\Windows
Kits\10\Bin\10.0.xxx\x86 to C:\Program Files (x86)\Windows
Kits\10\bin\x86 to fix this issue. Because the HLSL compile tool hard
coded the path.
This seems to have been fixed in Visual Studio 2019 16.0.2, as of writing. Just have to make sure $(WindowsSDK_ExecutablePath) is pointing to the correct SDK directory and the build version that matches with the Targeted Platform in the Project Properties page.
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/a3032567-d8e7-4b01-81b7-0612047a6299/why-do-we-need-to-copypaste-fxcexe-from-bin100xxxxx0x86-to-binx86-directory-in-the?forum=windowssdk
Second post answered:
The executables that the C++ build process uses from the Windows SDK directory are MIDL.exe, MT.exe and RC.exe. If you digitally sign your executables then you will find signtool.exe here too. So I am kind of surprised that it finds some critical build tools correctly but others it fails to find.
My suggestion would be:
1) Verify that you are having this problem with your project in Visual Studio 2019 16.0.2 (the latest version at the time of writing) or Visual Studio 2019 Preview (16.1 Preview 1 at the time of writing). This is to check that if this has been found to be a bug, then it could have been fixed.
2) Create a completely new project. Without touching the project's executable path, try to create a sample that shows this behaviour. It doesn't need to be a full sample, just complete enough to show that Visual Studio fails to find fxc.exe.
3) If doing all of this shows that Visual Studio fails to find fxc.exe, then through Visual Studio 2019, report it as a bug.
But I will mention that a naïve test on my end shows that Visual Studio 2019 can compile HLSL shaders without any issues using the 18362, 17763 and 17134 SDKs. These were tested because these are the versions that I have installed.
I have visual studio 2012 and visual studio 2017 in one x64 PC.
I can see that i have two iisexpress folders one under program files(x86) and another under program files
the iisexpress folder under program files(x86) has no iisexpress.exe file
but iisexpress folder under program files has iisexpress.exe file
when running a dotnet core MVC project in visual studio. it complains there is no iisexpress.exe under program files(x86)
The only thing I can comment is that your IIS Express installation is broken. iisexpress.exe must present in both folders, so that you can run both 32 bit and 64 bit of the process.
You found a workaround, but the ultimate solution is probably reinstalling IIS 10 Express.
I am trying to run the code analysis of Visual Studio 2015 on my x64 VC++ project. However I get the following error:
Error C1250 Unable to load plug-in 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin\localespc.dll'
I am activating the x64 toolset of Visual Studio by running the batch script "vcvarsall.bat amd64" before I start the IDE. Visual Studio is run with the "/useenv" option afterwards.
When I check the VC++ environment variables, I can see that the following path is contained in the PATH variable:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64
How can I tell Visual Studio to use the code analyzer (localespc.dll) from there and not the x86 version which it apparently tries to use (according to the error message).
Thanks a lot for your help!
I was having the same issue with my 64-bit C++ projects. I discovered simply renaming/removing localespc.dll from VC\bin allowed the Code Analysis builds to succeed and still report analysis warnings. It seems if VS doesn't find this dll in the VC\bin directory then it won't add the compiler switch for /analyze:plugin but otherwise passes all the other switches required by the Code Analysis.
Set the following property in your project file: <PreferredToolArchitecture>x64</PreferredToolArchitecture>
This tells Visual Studio to use the 64-bit version of various tools, including code analysis. I found How to make Visual Studio use the native amd64 toolchain helpful on the topic.
Note that renaming localespc.dll no longer solves the problem with Visual Studio 2017. It seems that setting PreferredToolArchitecture is Microsoft's intended way to do this.
As the Visual Studio installer is new from Visual Studio 2017 version, I cannot located the Visual C++ component, explained here.
How do I proceed to get the vsvars32.bat in VS2017?
VS2017 suffers from very seriously brain-damaged install path location choices. Most damning dumb thing they did is to make the edition name (Professional, Enterprise, probably Community) part of the path. This makes it quite difficult to find tools back reliably from one machine to another.
There is one environment variable that I think can solve the problem, the VSAPPIDDIR variable stores the path to the folder where the IDE is installed (devenv.exe). So if you want to run vcvars32.bat from a build event then you'd use
call "%vsappiddir%..\..\VC\Auxiliary\Build\vcvars32.bat" x86
Note that it is vc, not vs, vsvars32.bat no longer exists. You could possibly favor the "Developer Command Prompt:
call "%vsappiddir%..\tools\vsdevcmd.bat"
But judging from your link, you actually want to run the editbin.exe utility:
"%vsappiddir%..\..\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86\editbin.exe" args...
The 14.10.25017 version number is no joy whatsoever either, no real insight in how that is going to change from one update to the next. It probably will.
I know the question is (well) answered, but I would like to share how I solved the problem hoping it will help people googling for a solution
#echo off
set INSTALLPATH=
if exist "%programfiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" (
for /F "tokens=* USEBACKQ" %%F in (`"%programfiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -version 15.0 -property installationPath`) do set INSTALLPATH=%%F
)
echo INSTALLPATH is "%INSTALLPATH%"
REM Save current dir for later
pushd %CD%
if NOT "" == "%INSTALLPATH%" (
call "%INSTALLPATH%\Common7\Tools\VsDevCmd.bat"
) else (
goto ERROR_NO_VS15
)
:WORK
REM Retrieve the working dir and proceed
popd
echo Doing work in %CD%
svcutil this_is_just_an_example
goto END
:ERROR_NO_VS15
echo Visual Studio 2017 Tools Not Available!
:END
echo Processing ends.
A small explanation of the above script.
vswhere.exe is a single-file, native executable you can download or redistribute with your build and deployment environments to locate Visual Studio or other products installed with the new installer for Visual Studio 2017 (from the vswhere wiki)
Starting with Visual Studio 15.2 (26418.1 Preview) vswhere.exe is installed in %ProgramFiles(x86)%\Microsoft Visual Studio\Installer (use %ProgramFiles% in a 32-bit program prior to Windows 10). This is a fixed location that will be maintained (as noted here)
This allows developers to query for several important features of a Visual Studio 2017 (and above) installation. Furthermore, the tool was designed to allow different flavors of Visual Studio (Community Edition, Professional, ...) to be installed on the same machine.
You can find several usage examples here.
As for the script, the first relevant part
if exist "%programfiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" (
for /F "tokens=* USEBACKQ" %%F in (`"%programfiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -version 15.0 -property installationPath`) do set INSTALLPATH=%%F
)
Queries vswhere for the installation Path of Visual Studio 2017 (-version 15.0) and sets a variable named INSTALLPATH.
It should be noted that on a 32 bits OS, you should use %programfiles% instead of %programfiles(x86)%.
Due to this issue, the script saves the current directory for later retrieval.
The script then proceeds to test the contents of the INSTALLPATH variable. If the variable is not empty, it appends "Common7\Tools\VsDevCmd.bat" to it (which is a well known relative path where one can find development tools for the corresponding Visual Studio installation). Otherwise, the script jumps to an error message and exits (you may opt to return a non-zero error code).
If all went well, you have now a full fledge Visual Studio development environment at your disposal.
The script now proceeds to retrieve the original directory and execute something, in this case a dummy call to svcutil.
Just change "vsvars32.bat" to "vsdevcmd.bat". This is compatible at least back to VS2015.
call "$(DevEnvDir)..\tools\vsdevcmd.bat"
editbin /largeaddressaware "$(TargetPath)"
Microsoft changes the vcvars32.bat to VsDevCmd.bat in VS 2017 link
I use vcvars32.bat in pré-build (project properties->build events), so for me, I've changed:
"$(DevEnvDir)..\..\VC\bin\vcvars32.bat"
to
$(DevEnvDir)\..\Tools\VsDevCmd.bat"
and it worked!
Edit:
In Visual Studio 15.9 the path was changed (as Fütemire said
in the comment), so I had to change:
$(DevEnvDir)\..\Tools\VsDevCmd.bat"
to:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat
*You can create an environment variable to store the path. I couldn't find an already defined.
None of the mentioned solutions worked for me. After getting my head warmed up from the "vsvars32.bat missing" error - I went through every single line and there was too 'svcutil.exe' was missing.
I thought of fixing that and it worked. I got the following path in my machine for SvcUtil.exe:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
I set the path in System Environment Variable and restarted my Visual Studio for just in case and it worked.
Hope this helps someone!
Edit:
Very Strange - it works when I have "Lightweight solution load" enabled. As soon I'ml disabling "Lightweight Solution Load" - it starts giving me same error!
In Visual Studio 2017 (inkl. C++ Build Tools installed) I do it in this manner in the post build events to check also for x86:
if not $(PlatformName) == x64 (
if exist "$(DevEnvDir)..\tools\vsdevcmd.bat" (
echo setting largeaddressaware to get 4gb access in 32 bit
call "$(DevEnvDir)..\tools\vsdevcmd.bat"
editbin /largeaddressaware "$(TargetPath)"
)
)
Main Problem
When I try to access the properties of a project in Visual Studio Express 2013 for Windows Desktop through Project -> ProjectName Properties, Visual Studio freezes completely without an error and I must end it through the Windows Task Manager.
I ran Visual Studio with /safemode enabled. This did provide some information by saying that "The 'Visual Studio Component Model Host Package' package did not load correctly."
It also produced a log file with some errors and warnings. Errors and warning entries in the log can be searched for with <type>Error</type> and <type>Warning</type> respectively. Additionally, opening the file in Internet Explorer seems to apply some styles to the file and makes it more readable.
Errors only - http://pastebin.com/295sX8kH
Full log - http://pastebin.com/KGspUgGs
The errors in the log seem to center around this Visual Studio Component Model Host Package. I tried searching for errors related to that, but did not find anything I thought was applicable to my situation.
The dll Microsoft.VisualStudio.ComponentModelHost.Implementation.dll is present in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PrivateAssemblies\
The dll Microsoft.Data.Entity.Design.DataSourceWizardExtension.dll is indeed missing from C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\DataDesign
Extra Info
I am using version 12.0.30723.00 Update 3 of Visual Studio and I am running Windows 7 Professional 64-bit 6.1 build 7601.
I have tried re-installing Visual Studio in order to to clear out any bad settings, but that did not seem to work.
I tried running Visual Studio with /resetskipkgs and /resetsettings, and neither of those worked.
Trying to open project properties in safe mode still froze Visual Studio.
Backstory
I am ultimately trying to setup an environment in which to develop OpenGL applications. I have some experience with it through following the Arc Synthesis tutorials, but I do not know how to operate outside of the specialized environment the tutorials provided.
Following the OpenGL Book setup instructions, I am told development will go more smoothly if I use the GLEW and freeGLUT libraries. In order to do so, I need to be able to link in extra files to a project. In Visual Studio, this is done through the project properties dialog, but I cannot access it due to the freezing problem.
I am not very familiar with the development process in C++, so I am wary of venturing outside of the IDE provided by Visual Studio, but I might just have to do that if this problem persists.