I am trying to compile XNABasics project in visual studio from this repository
https://code.google.com/p/kinect4bag/
But it gives me a error named:
Error 1 error MSB6006: "cmd.exe" exited with code 9009. C:\Program
Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 151 6 CGePhysics
and when i double click it redirects me to the page given below, i have checked the project properties does not have anything in custom build step and custom build tool area.
Just came across this thread now.
I had the exact same error. In my case, the swig.exe path that my project was looking for was wrong. My issue was fixed once i made sure the SWIG package was in the same path that my Project Properties' Macro was looking.
When I had this problem it was due to missing Direct X executable paths in the property manager. As suggested at this Stack Overflow thread: MSB6006: “cmd.exe” exited with code 9009
Upon inspecting my build log I found that 'fxc' is not recognized as an internal or external command which brought me to this solution: 'fxc.exe' is not recognized as an internal or external command
I went into my property manager to Microsoft.Cpp.Win32.user and added the proper DirectX SDK paths to Executables, Include, and Library (C:\Program Files\Microsoft DirectX SDK\Utilities\bin\x64, C:\Program Files\Microsoft DirectX SDK\Include, C:\Program Files\Microsoft DirectX SDK\Lib\x86 respectively)
This error shows that execution of a command in command line environment fails. You should view output logs(e.g., view->output in visual studio) and find this error. For example, following log illustrated that windows command cannot recognize 'make' syntax. So, I replaced it with 'nmake' and set PATH variable for it.
2> 'make' is not recognized as an internal or external command,
2> operable program or batch file.
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5): error MSB6006: "cmd.exe" exited with code 9009.
Related
I'm trying to publish my first test function to Azure functions. When I publish I get the error:
Publish has encountered an error.
Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.
A diagnostic log has been written to the following location:
"C:\Users\me\AppData\Local\Temp\tmp2C29.tmp"
The contest of that file say it was an unknown error, check the output log.
When I look at my output window I see this:
2>Unhandled Exception: System.IO.DirectoryNotFoundException: The path `D:\Dev\FunctionsTest-master\custom-binding\obj\Debug\netstandard2.0\PubTmp\Out\bin` does not exist. Unable to generate Azure Functions extensions metadata file.
2> at ExtensionsMetadataGenerator.ExtensionsMetadataGenerator.Generate(String sourcePath, String outputPath, Action`1 logger) in D:\src\gh.fabiocav\azure-functions-host\tools\ExtensionsMetadataGenerator\src\ExtensionsMetadataGenerator.Console\ExtensionsMetadataGenerator.cs:line 25
2> at ExtensionsMetadataGenerator.Console.Program.Main(String[] args) in D:\src\gh.fabiocav\azure-functions-host\tools\ExtensionsMetadataGenerator\src\ExtensionsMetadataGenerator.Console\Program.cs:line 28
2>Metadata generation failed.
I looked and the ...\PubTmp\Out\bin folder is not where it's being compiled. The actual folder is \PubTmp\Out\ (one folder higher).
I don't see any way of changing the folder location, I tried under properties of the function - build, but that path is the top level; not the final path.
I also don't see any way of selecting where the publish is looking for the compiled functions to publish.
How do I get these locations to be the same for the publish to work?
It appears that this was a bug in Visual Studio 2019. Patching to the current version took care of it.
I'm trying to reference the Microsoft ActiveX Data Objects 6.1 Library (ADODB) using the csc.exe C# compiler but I'm getting the error:
fatal error CS0009: Metadata file 'c:\Program Files\Common Files\system\ado\msado15.dll' could not be opened -- 'An attempt was made to load a program with an incorrect format. '
I have simplified the files to try tracking the problem.
Batch file Compile.bat:
#ECHO OFF
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\csc.exe -nologo -r:"C:\Program Files\Common Files\system\ado\msado15.dll" Code.cs
PAUSE >NUL
C# file Code.cs:
class Program {
static void Main() {
ADODB.Connection ADODBConnection = new ADODB.Connection();
System.Console.WriteLine((ADODBConnection == null).ToString());
}
}
I have tried copying the dll to the same folder and referencing it but got the same error.
I also have the compilers versions ...\v2.0.50727\csc.exe and ...\v3.5\csc.exe and the libraries versions msado20.tlb, msado21.tlb, msado25.tlb, msado26.tlb, msado27.tlb, msado28.tlb and msado60.tlb.
When I try the same on Visual Studio 2017 (.NET Framework 4 Console Application) it works. It creates ConsoleApp1\ConsoleApp1\obj\Debug\Interop.ADODB.dll and references that instead but I don't know where it gets it from. I have tried searching for it in different folders.
I found the file that Visual Studio uses from this thread (by searching online for Interop.ADODB.dll file location) and later this link:
C:\Program Files\Microsoft.NET\Primary Interop Assemblies\adodb.dll
Working Compile.bat:
#ECHO OFF
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\csc.exe -nologo -r:"%ProgramFiles%\Microsoft.NET\Primary Interop Assemblies\adodb.dll" Code.cs
PAUSE >NUL
I am trying to build the visual studio code and I get the following build error.
I searched for answers regarding the same topic. I already tried adding nuget.exe to Path variable. But nothing seems to work.
This is my error in the error list
MSB3073 The command "nuget.exe push -Source Application_Internal -ApiKey VSTS C:Users\Documents\LOCAL_NUGET_FEED\App.Util.*.*0.0.0*.nupkg" exited with code 9009
The corresponding line from csconfig file is
<Exec Command="NuGet.exe push -Source Application_Internal -ApiKey VSTS $(LOCAL_NUGET_FEED)\$(AssemblyName)*.*$(Version)*.nupkg " />
Any help would be much appreciated.
code 9009 : error code MSB3073
Agree with Klaus, 9009 in this situation means the nuget.exe can't be found during the build process. It seems that you have a MSBuild Exec task used to execute the nuget push command.
For msbuild exec task, it actually will call something like cmd.exe to execute the command. So if one command failed in Exec task or post-build-event, most of the time it indicates the command would fail in cmd.exe.
I already tried adding nuget.exe to Path variable
You can open cmd.exe and type nuget, if it displays many switchs about nuget.exe, it means your path variable is set well. But if it shows 'nuget' is not recognized as an internal or external command, it means you didn't add path of nuget.exe to Path Variable successfully. And that's why you got the 9009 in VS.
I Tried it, still getting the same error.
If the same error you mean is 9009, please check content above in #2. If the same error you mean is MSB3073, you need to check the error code, still code 9009 or xxx?
If you simply type nuget in cmd.exe and display many switches, then your path is set well. And I think the code 9009 will go away in VS if you rebuild the project. But it doesn't mean the MSB3073 error would go away. Only if nothing is wrong in your command NuGet.exe push -Source Application_Internal -ApiKey VSTS $(LOCAL_NUGET_FEED)\$(AssemblyName)*.*$(Version)*.nupkg the MSB3073 error would disappear.
For this situation, I mean the nuget.exe can be found. But it may have error when nuget.exe executed the push command, maybe the package not found, source invalid or what.
Note:
1.MSB3073 just means something is wrong with the command. (Perhaps not only one error in the command)
2.code 9009 means the nuget.exe is not found
So you may get MSB3073 and exited code 1 or what even after the nuget.exe can be found. At least for App.Util.*.*0.0.0*.nupkg, I think the nuget.exe didn't find your package.
Suggestion:
Please set the verbosity to Detailed and check the detailed log about why the build failed.
Some possibilities about why you get the MSB3073 after the code 9009 error go away(Examples for code 1):
I think you may get this error message for the wrong use of wildcard $(AssemblyName)*.*$(Version)*.
I'm trying to get a Xamarin Forms solution to build from the command line as part of a build script using the command dotnet build <solution.sln>. Most of the projects in the solution build; however, two projects fail with this error message: error MSB6006: "csc.exe" exited with code 1.(on Ubuntu) and error MSB6006: "csc.exe" exited with code 8. (on Mac).
I have running Ubuntu 18.04 (using Windows subsystem for Linux) and MacOS 10.13.6 on separate machines.
I have also tried to run dotnet build <solution.sln> from the windows command line which prints out this error message instead:
error MSB4062: The "XamarinLive.Build.XamarinLiveTask" task could not be loaded from the assembly C:\Users\Jason.nuget\packages\livexaml\2.1.22\build\XamarinLive.Build.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
However, the solution works and builds fine from within VS2017 (Version 15.9.7). I've tried scouring the binary log that is generated but I can't make much sense of it and there doesn't seem to be any obvious errors (on Ubuntu & Mac). Could the windows error message be related in some way?
The projects that are failing target netstandard 2.0 (The same as the projects that do build). The version returned by dotnet --version on all 3 environments is 2.1.504.
Any help would be greatly appreciated.
You need to use msbuild.exe instead of dotnet
build
for this situation.
msbuild.exe runs on full framework while dotnet buildruns on .NET Core, and most of the build tasks don't support that.
When you build them in VS,it actually calls the msbuild.exe to build the solution.So you can build it well by developer command prompt since it also calls the msbuild.exe.
For vs2017, you can find it in C:\Program Files (x86)\Microsoft Visual Studio\2017\Edition\MSBuild\15.0\Bin.
More details see Martin's answer from this similar issue. Thanks to his detailed description!
I need to do crash dump analysis for a .net exe using Windbg.
I read multiple blogs on MSDN to setup my Windbg but looks like it still has issues loading 'mscordacwks.dll'.
Upon running this command i get this:
Failed to load data access DLL, 0x80004005 Verify that 1) you have a
recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.
You can also run the debugger command .cordll to control the
debugger's load of mscordacwks.dll. .cordll -ve -u -l will do a
verbose reload. If that succeeds, the SOS command should work on
retry.
If you are debugging a minidump, you need to make sure that your
executable path is pointing to mscorwks.dll as well.
Here are quick details of my environment:
EXE is 32 -bit so using x86 debugger
In the following path: C:\Windows\Microsoft.NET\Framework\v2.0.50727 the two DLLs are located
:
->mscorwks.dll
->mscordacwks.dll file version: 2.0.50727.5485
Symbol path is : c:\debug\symbols
Debugging tools(i.e. Windbg installation) is located at: C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
Copied mscorwks.dll and mscordacwks.dll in this path and renamed to(as per some blog on MSDN) :
-> mscordacwks_x86_x86_2.0.50727.5485
-> mscorwks_x86_x86_2.0.50727.5485
Not sure if these names are correct or not.
Still it never worked.