What does “exited with code 9009” mean during this build?
What does this error message mean? What could I do to correct this issue?
AssemblyInfo.cs exited with code 9009
The problem is probably happening as part of a post-build step in a .NET solution in Visual Studio.
.net visual-studio
add a comment |
What does this error message mean? What could I do to correct this issue?
AssemblyInfo.cs exited with code 9009
The problem is probably happening as part of a post-build step in a .NET solution in Visual Studio.
.net visual-studio
could it possibly be this http://support.microsoft.com/kb/908268
– MaLio
Aug 29 '09 at 17:04
7
The OP isn't coming back to fix this problem, but it has a lot of answers and a lot of Google juice. So, let's try to infer the problem?
– Anthony Mastrean
Mar 15 '12 at 15:04
12
The Output Window gave me some insight into this problem which i was also having
– hanzolo
Oct 9 '12 at 18:21
add a comment |
What does this error message mean? What could I do to correct this issue?
AssemblyInfo.cs exited with code 9009
The problem is probably happening as part of a post-build step in a .NET solution in Visual Studio.
.net visual-studio
What does this error message mean? What could I do to correct this issue?
AssemblyInfo.cs exited with code 9009
The problem is probably happening as part of a post-build step in a .NET solution in Visual Studio.
.net visual-studio
.net visual-studio
edited Mar 15 '12 at 15:04
Anthony Mastrean
14.3k1982146
14.3k1982146
asked Aug 29 '09 at 16:31
dgo
could it possibly be this http://support.microsoft.com/kb/908268
– MaLio
Aug 29 '09 at 17:04
7
The OP isn't coming back to fix this problem, but it has a lot of answers and a lot of Google juice. So, let's try to infer the problem?
– Anthony Mastrean
Mar 15 '12 at 15:04
12
The Output Window gave me some insight into this problem which i was also having
– hanzolo
Oct 9 '12 at 18:21
add a comment |
could it possibly be this http://support.microsoft.com/kb/908268
– MaLio
Aug 29 '09 at 17:04
7
The OP isn't coming back to fix this problem, but it has a lot of answers and a lot of Google juice. So, let's try to infer the problem?
– Anthony Mastrean
Mar 15 '12 at 15:04
12
The Output Window gave me some insight into this problem which i was also having
– hanzolo
Oct 9 '12 at 18:21
could it possibly be this http://support.microsoft.com/kb/908268
– MaLio
Aug 29 '09 at 17:04
could it possibly be this http://support.microsoft.com/kb/908268
– MaLio
Aug 29 '09 at 17:04
7
7
The OP isn't coming back to fix this problem, but it has a lot of answers and a lot of Google juice. So, let's try to infer the problem?
– Anthony Mastrean
Mar 15 '12 at 15:04
The OP isn't coming back to fix this problem, but it has a lot of answers and a lot of Google juice. So, let's try to infer the problem?
– Anthony Mastrean
Mar 15 '12 at 15:04
12
12
The Output Window gave me some insight into this problem which i was also having
– hanzolo
Oct 9 '12 at 18:21
The Output Window gave me some insight into this problem which i was also having
– hanzolo
Oct 9 '12 at 18:21
add a comment |
29 Answers
29
active
oldest
votes
Did you try to give the full path of the command that is running in the pre- or post-build event command?
I was getting the 9009 error due to a xcopy
post-build event command in Visual Studio 2008.
The command
"xcopy.exe /Y C:projectpathproject.config C:compilepath"
exited with code 9009.
But in my case it was also intermittent. That is, the error message persists until a restart of the computer, and disappears after a restart of the computer. It is back after some remotely related issue I am yet to discover.
However, in my case providing the command with its full path solved the issue:
c:windowssystem32xcopy.exe /Y C:projectpathproject.config C:compilepath
Instead of just:
xcopy.exe /Y C:projectpathproject.config C:compilepath
If I do not have the full path, it runs for a while after a restart, and then stops.
Also as mentioned on the comments to this post, if there are spaces in full path, then one needs quotation marks around the command. E.g.
"C:The folder with spacesABCDEFxcopy.exe" /Y C:projectpathproject.config C:compilepath
Note that this example with regards to spaces is not tested.
41
I also received the 9009 error on post and pre build events. Checking the Output tab in Visual Studio shows the problem. In my case I was trying to access a path containing a space
– Phil Hale
May 2 '11 at 15:04
15
I had a similar problem to this, but it was the result of spaces in the folder names. Putting the paths in quotes ("$(SolutionDir)packagesNUnit.2.5.10.11092tools"nunit-console "$(TargetPath)"
) resolved it.
– Justin Morgan
Nov 18 '11 at 19:50
1
I encountered a similar issue with a pre-build event that used a Java applet to pre-compile JS and CSS...turns out we had neglected to put the Java Runtime on the server.
– saluce
May 11 '12 at 19:29
2
Is it possible that thePATH
environment variable gets lost somehow? I get this error every now and then. I havenpm install
setup as a pre-build event, and initially it works (so I presume everything is setup), but then randomly it will stop working during the day (generally when switching between solutions / branches I believe), and it will no longer know aboutnpm
. Restarting VS 'fixes' it... meaning myPATH
is setup correctly, but seems to get up by VS. If there was a way to view the env variables from inside VS I could confirm this.
– jamiebarrow
Oct 7 '14 at 9:32
1
If you want to protect your build from crashing in different environments, let's say, windows installed on D:, use environment vars in conjunction of @thehhv answer:%systemroot%System32xcopy ...
– Dorival
Jul 10 '15 at 21:29
|
show 7 more comments
Error Code 9009 means error file not found. All the underlying reasons posted in the answers here are good inspiration to figure out why, but the error itself simply means a bad path.
1
My issue with file not found was the reference in the csproj file was $(PROGRAMFILES)Microsoft SDKsTypeScripttsc and had to be $(PROGRAMFILES)Microsoft SDKsTypeScript1.0tsc
– RHAD
Jul 10 '14 at 8:41
It's always good to actually answer the question posed.
– gdbj
Sep 19 '17 at 14:45
Thanks for actually answering the first question.
– AntonK
Jan 24 '18 at 0:00
add a comment |
It happens when you are missing some environment settings for using Microsoft Visual Studio 2010 x86 tools.
Therefore, try adding as a first command in your post-build steps:
call "$(DevEnvDir)..Toolsvsvars32.bat"
It should be placed before any other command.
It will set environment for using Microsoft Visual Studio 2010 x86 tools.
6
What the.... This really helped! Thanks man! +1
– Marcel
Apr 20 '12 at 12:57
3
Could you help me out - where and into which file do i have to add the linecall "$(DevEnvDir)..Toolsvsvars32.bat"
? Thanks
– surfmuggle
Oct 16 '12 at 19:40
2
I had to add an entry to myPath
environment variable. Check the Output window for more information.
– paqogomez
Dec 6 '13 at 5:19
Caution. This will fail on many build servers: blogs.clariusconsulting.net/kzu/devenvdir-considered-harmful
– George Mauer
Sep 24 '14 at 19:36
2
Thank you, for x64 bit toolchain I solved like so: "$(DevEnvDir)..VCvcvarsall.bat"
– codekiddy
Jan 26 '15 at 21:59
|
show 2 more comments
Most probably you have space in your resultant path.
You can work around this by quoting the paths, thus allowing spaces. For example:
xcopy "$(SolutionDir)Folder NameFile To Copy.ext" "$(TargetDir)" /R /Y /I
9
+1 - This is exactly the problem I was having. A command in my post-build worked when I built the project locally, but failed when it was built on the build server. I just placed the command between double quotes to fix it. Thanks.
– sheikhjabootie
Sep 29 '11 at 3:14
So is it reasonable to speculate that error 9009 is "file not found"..? Personally, I think the question "what is MSBuild error 9009?" should be perfectly fine as a stand-alone question, but directed to Microsoft!
– The Dag
Jul 1 '13 at 14:48
add a comment |
Had the same variable after changing PATH variable from Environmental Variables in Win 7. Changing back to default helped.
add a comment |
I have had the error 9009 when my post build event script was trying to run a batch file that did not exist in the path specified.
add a comment |
If the script actually does what it needs to do and it's just Visual Studio bugging you about the error you could just add:
exit 0
to the end of you script.
3
hiding any potential error should not be the way to go
– igelineau
Jan 9 '17 at 17:05
I agree this should not be masked
– AltF4_
Apr 11 '17 at 14:13
add a comment |
I caused this error to happen when I redacted my Path environment variable. After editing, I accidentally added Path=
to the beginning of the path string. With such a malformed path variable, I was unable to run XCopy at the command line (no command or file not found), and Visual Studio refused to run post-build step, citing error with code 9009.
XCopy commonly resides in C:WindowsSystem32. Once the Path environment variable allowed XCopy to get resolved at DOS prompt, Visual Studio built my solution well.
add a comment |
Check the spelling. I was trying to call an executable but had the name misspelled and it gave me the exited with code 9009
message.
1
To that add a check for the existence of the executable on your system at all.
– Joshua Drake
Dec 5 '13 at 15:42
add a comment |
My exact error was
The command "iscc /DConfigurationName=Debug "C:ProjectsBlahblahblahsetup.iss"" exited with code 9009.
9009 means file not found, but it actually couldn't find the "iscc" part of the command.
I fixed it by adding ";C:Program FilesInno Setup 5 (x86)"
to the system environment variable "path"
add a comment |
Another variant:
today I call python interpreter from cron in win32 and take ExitCode (%ERRORLEVEL%) 9009, because system account used by cron don't have path to Python directory.
add a comment |
In my case I had to "CD" (Change Directory) to the proper directory first, before calling the command, since the executable I was calling was in my project directory.
Example:
cd "$(SolutionDir)"
call "$(SolutionDir)build.bat"
This fixed the problem for me running Visual Studio's devenv.exe, but you don't need to specify the folder the second time, just'call build.bat will do
– FrinkTheBrave
May 6 '17 at 7:44
add a comment |
The problem in my case occurred when I tried to use a command on the command-line for the Post-build event in my Test Class Library. When you use quotation marks like so:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit" "$(TargetPath)"
or if you're using the console:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit-console" "$(TargetPath)"
This fixed the issue for me.
add a comment |
Also, make sure there are no line breaks in the post build event editing window on your project. Sometimes copying the xcopy command from the web when it's multi-line and pasting it into VS will cause a problem.
Although jesse makes a good point about not having line breaks in the middle of an xcopy command, note that in the general case it is valid to have line breaks in this field; each line should be interpreted as its own command.
– RJFalconer
Jan 15 '13 at 17:12
add a comment |
I added "> myFile.txt" to the end of the line in the pre-build step and then inspected the file for the actual error.
add a comment |
For me, disk space was low, and files that couldn't be written were expected to be present later. Other answers mentioned missing files (or misnamed/improperly referenced-by-name files)--but the root cause was lack of disk space.
add a comment |
Yet another variant of file not found, because of spaces in the path. In my case in the msbuild script. I needed to use HTML style " strings within the exec command.
<!-- Needs quotes example with my Buildscript.msbuild file -->
<Exec Command=""$(MSBuildThisFileDirectory)wixwixscript.bat" $(VersionNumber) $(VersionNumberShort)"
ContinueOnError="false"
IgnoreExitCode="false"
WorkingDirectory="$(MSBuildProjectDirectory)wix" />
add a comment |
Same as the other answers, in my case it was because of the missing file. To know what is the missing file, you can go to the output window and it will show you straight away what went missing.
To open the output window in Visual Studio:
- Ctrl+Alt+O
- View > Output
add a comment |
This is pretty basic, I had this problem, and embarrassing simple fail.
Application use Command line arguments, I removed them and then added them back. Suddenly the project failed to build.
Visual Studio -> Project Properties -> verify that you use 'Debug' tab (not 'Build Events' tab) -> Command Line Arguments
I used the and Post/Pre-build text area, which was wrong this case.
add a comment |
For me it happened after upgrade nuget packages from one PostSharp version to next one in a big solution (~80 project).
I've got compiler errors for projects that have commands in PreBuild events.
'cmd' is not recognized as an internal or external command, operable program or batch file.
C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1249,5): error MSB3073: The command "cmd /c C:GitReposmainServiceInterfacesDEV.ConfigPreBuild.cmd ServiceInterfaces" exited with code 9009.
PATH variable was corrupted becoming too long with multiple repeated paths related to PostSharp.Patterns.Diagnostics.
When I closed Visual Studio and opened it again, the problem was fixed.
add a comment |
My solution was just simple as: have you tried turning it off and on again? So I restarted the computer and the issue was gone.
add a comment |
I also ran into this 9009
problem when facing an overwrite situation.
Basically, if the file already exists and you have not specified the /y
switch (which automatically overwrites) this error can happen when run from a build.
add a comment |
tfa's answer has been downvoted, but actually can cause this issue.
Thanks to hanzolo, I looked in the output window and found the following:
3>'gulp' is not recognized as an internal or external command,
3>operable program or batch file.
3>D:dev<filepath>Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009.
After running npm install -g gulp
, I stopped getting this error. If you're getting this error in Visual Studio, check the output window and see if the issue is an unset environment variable.
add a comment |
Actually I noticed that for some reason the %windir% environment variable sometimes get erased. What worked for me was re-set the windir environment variable to c:windows, restart VS, and that's it. That way you prevent having to modify the solution files.
add a comment |
At least in Visual Studio Ultimate 2013, Version 12.0.30723.00 Update 3, it's not possible to separate an if/else statement with a line break:
works:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local) else (echo server)
doesn't work:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local)
else (echo server)
add a comment |
Yet another reason:
If your pre-build event references another projects bin path and you see this error when running msbuild, but not Visual Studio, then you have to manually arrange the projects in the *.sln file (with a text editor) so that the project you are targeting in the event is built before the event's project. In other words, msbuild uses the order that projects are listed in the *.sln file whereas VS uses knowledge of project dependencies. I had this happen when a tool that creates a database to be included in a wixproj was listed after the wixproj.
add a comment |
I think in my case there were russian symbols in path (all projects were in user folder). When I put solution in another folder (directly on disk), everything became ok.
add a comment |
My solution was to create a copy of the file and add a step to the build task to copy my file over the original.
add a comment |
You need to make sure you have installed grunt globally
add a comment |
protected by Community♦ Jul 20 '12 at 10:06
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
29 Answers
29
active
oldest
votes
29 Answers
29
active
oldest
votes
active
oldest
votes
active
oldest
votes
Did you try to give the full path of the command that is running in the pre- or post-build event command?
I was getting the 9009 error due to a xcopy
post-build event command in Visual Studio 2008.
The command
"xcopy.exe /Y C:projectpathproject.config C:compilepath"
exited with code 9009.
But in my case it was also intermittent. That is, the error message persists until a restart of the computer, and disappears after a restart of the computer. It is back after some remotely related issue I am yet to discover.
However, in my case providing the command with its full path solved the issue:
c:windowssystem32xcopy.exe /Y C:projectpathproject.config C:compilepath
Instead of just:
xcopy.exe /Y C:projectpathproject.config C:compilepath
If I do not have the full path, it runs for a while after a restart, and then stops.
Also as mentioned on the comments to this post, if there are spaces in full path, then one needs quotation marks around the command. E.g.
"C:The folder with spacesABCDEFxcopy.exe" /Y C:projectpathproject.config C:compilepath
Note that this example with regards to spaces is not tested.
41
I also received the 9009 error on post and pre build events. Checking the Output tab in Visual Studio shows the problem. In my case I was trying to access a path containing a space
– Phil Hale
May 2 '11 at 15:04
15
I had a similar problem to this, but it was the result of spaces in the folder names. Putting the paths in quotes ("$(SolutionDir)packagesNUnit.2.5.10.11092tools"nunit-console "$(TargetPath)"
) resolved it.
– Justin Morgan
Nov 18 '11 at 19:50
1
I encountered a similar issue with a pre-build event that used a Java applet to pre-compile JS and CSS...turns out we had neglected to put the Java Runtime on the server.
– saluce
May 11 '12 at 19:29
2
Is it possible that thePATH
environment variable gets lost somehow? I get this error every now and then. I havenpm install
setup as a pre-build event, and initially it works (so I presume everything is setup), but then randomly it will stop working during the day (generally when switching between solutions / branches I believe), and it will no longer know aboutnpm
. Restarting VS 'fixes' it... meaning myPATH
is setup correctly, but seems to get up by VS. If there was a way to view the env variables from inside VS I could confirm this.
– jamiebarrow
Oct 7 '14 at 9:32
1
If you want to protect your build from crashing in different environments, let's say, windows installed on D:, use environment vars in conjunction of @thehhv answer:%systemroot%System32xcopy ...
– Dorival
Jul 10 '15 at 21:29
|
show 7 more comments
Did you try to give the full path of the command that is running in the pre- or post-build event command?
I was getting the 9009 error due to a xcopy
post-build event command in Visual Studio 2008.
The command
"xcopy.exe /Y C:projectpathproject.config C:compilepath"
exited with code 9009.
But in my case it was also intermittent. That is, the error message persists until a restart of the computer, and disappears after a restart of the computer. It is back after some remotely related issue I am yet to discover.
However, in my case providing the command with its full path solved the issue:
c:windowssystem32xcopy.exe /Y C:projectpathproject.config C:compilepath
Instead of just:
xcopy.exe /Y C:projectpathproject.config C:compilepath
If I do not have the full path, it runs for a while after a restart, and then stops.
Also as mentioned on the comments to this post, if there are spaces in full path, then one needs quotation marks around the command. E.g.
"C:The folder with spacesABCDEFxcopy.exe" /Y C:projectpathproject.config C:compilepath
Note that this example with regards to spaces is not tested.
41
I also received the 9009 error on post and pre build events. Checking the Output tab in Visual Studio shows the problem. In my case I was trying to access a path containing a space
– Phil Hale
May 2 '11 at 15:04
15
I had a similar problem to this, but it was the result of spaces in the folder names. Putting the paths in quotes ("$(SolutionDir)packagesNUnit.2.5.10.11092tools"nunit-console "$(TargetPath)"
) resolved it.
– Justin Morgan
Nov 18 '11 at 19:50
1
I encountered a similar issue with a pre-build event that used a Java applet to pre-compile JS and CSS...turns out we had neglected to put the Java Runtime on the server.
– saluce
May 11 '12 at 19:29
2
Is it possible that thePATH
environment variable gets lost somehow? I get this error every now and then. I havenpm install
setup as a pre-build event, and initially it works (so I presume everything is setup), but then randomly it will stop working during the day (generally when switching between solutions / branches I believe), and it will no longer know aboutnpm
. Restarting VS 'fixes' it... meaning myPATH
is setup correctly, but seems to get up by VS. If there was a way to view the env variables from inside VS I could confirm this.
– jamiebarrow
Oct 7 '14 at 9:32
1
If you want to protect your build from crashing in different environments, let's say, windows installed on D:, use environment vars in conjunction of @thehhv answer:%systemroot%System32xcopy ...
– Dorival
Jul 10 '15 at 21:29
|
show 7 more comments
Did you try to give the full path of the command that is running in the pre- or post-build event command?
I was getting the 9009 error due to a xcopy
post-build event command in Visual Studio 2008.
The command
"xcopy.exe /Y C:projectpathproject.config C:compilepath"
exited with code 9009.
But in my case it was also intermittent. That is, the error message persists until a restart of the computer, and disappears after a restart of the computer. It is back after some remotely related issue I am yet to discover.
However, in my case providing the command with its full path solved the issue:
c:windowssystem32xcopy.exe /Y C:projectpathproject.config C:compilepath
Instead of just:
xcopy.exe /Y C:projectpathproject.config C:compilepath
If I do not have the full path, it runs for a while after a restart, and then stops.
Also as mentioned on the comments to this post, if there are spaces in full path, then one needs quotation marks around the command. E.g.
"C:The folder with spacesABCDEFxcopy.exe" /Y C:projectpathproject.config C:compilepath
Note that this example with regards to spaces is not tested.
Did you try to give the full path of the command that is running in the pre- or post-build event command?
I was getting the 9009 error due to a xcopy
post-build event command in Visual Studio 2008.
The command
"xcopy.exe /Y C:projectpathproject.config C:compilepath"
exited with code 9009.
But in my case it was also intermittent. That is, the error message persists until a restart of the computer, and disappears after a restart of the computer. It is back after some remotely related issue I am yet to discover.
However, in my case providing the command with its full path solved the issue:
c:windowssystem32xcopy.exe /Y C:projectpathproject.config C:compilepath
Instead of just:
xcopy.exe /Y C:projectpathproject.config C:compilepath
If I do not have the full path, it runs for a while after a restart, and then stops.
Also as mentioned on the comments to this post, if there are spaces in full path, then one needs quotation marks around the command. E.g.
"C:The folder with spacesABCDEFxcopy.exe" /Y C:projectpathproject.config C:compilepath
Note that this example with regards to spaces is not tested.
edited Dec 2 '15 at 9:22
Jeroen
36.7k24130210
36.7k24130210
answered Feb 17 '10 at 15:12
thehhvthehhv
2,87111918
2,87111918
41
I also received the 9009 error on post and pre build events. Checking the Output tab in Visual Studio shows the problem. In my case I was trying to access a path containing a space
– Phil Hale
May 2 '11 at 15:04
15
I had a similar problem to this, but it was the result of spaces in the folder names. Putting the paths in quotes ("$(SolutionDir)packagesNUnit.2.5.10.11092tools"nunit-console "$(TargetPath)"
) resolved it.
– Justin Morgan
Nov 18 '11 at 19:50
1
I encountered a similar issue with a pre-build event that used a Java applet to pre-compile JS and CSS...turns out we had neglected to put the Java Runtime on the server.
– saluce
May 11 '12 at 19:29
2
Is it possible that thePATH
environment variable gets lost somehow? I get this error every now and then. I havenpm install
setup as a pre-build event, and initially it works (so I presume everything is setup), but then randomly it will stop working during the day (generally when switching between solutions / branches I believe), and it will no longer know aboutnpm
. Restarting VS 'fixes' it... meaning myPATH
is setup correctly, but seems to get up by VS. If there was a way to view the env variables from inside VS I could confirm this.
– jamiebarrow
Oct 7 '14 at 9:32
1
If you want to protect your build from crashing in different environments, let's say, windows installed on D:, use environment vars in conjunction of @thehhv answer:%systemroot%System32xcopy ...
– Dorival
Jul 10 '15 at 21:29
|
show 7 more comments
41
I also received the 9009 error on post and pre build events. Checking the Output tab in Visual Studio shows the problem. In my case I was trying to access a path containing a space
– Phil Hale
May 2 '11 at 15:04
15
I had a similar problem to this, but it was the result of spaces in the folder names. Putting the paths in quotes ("$(SolutionDir)packagesNUnit.2.5.10.11092tools"nunit-console "$(TargetPath)"
) resolved it.
– Justin Morgan
Nov 18 '11 at 19:50
1
I encountered a similar issue with a pre-build event that used a Java applet to pre-compile JS and CSS...turns out we had neglected to put the Java Runtime on the server.
– saluce
May 11 '12 at 19:29
2
Is it possible that thePATH
environment variable gets lost somehow? I get this error every now and then. I havenpm install
setup as a pre-build event, and initially it works (so I presume everything is setup), but then randomly it will stop working during the day (generally when switching between solutions / branches I believe), and it will no longer know aboutnpm
. Restarting VS 'fixes' it... meaning myPATH
is setup correctly, but seems to get up by VS. If there was a way to view the env variables from inside VS I could confirm this.
– jamiebarrow
Oct 7 '14 at 9:32
1
If you want to protect your build from crashing in different environments, let's say, windows installed on D:, use environment vars in conjunction of @thehhv answer:%systemroot%System32xcopy ...
– Dorival
Jul 10 '15 at 21:29
41
41
I also received the 9009 error on post and pre build events. Checking the Output tab in Visual Studio shows the problem. In my case I was trying to access a path containing a space
– Phil Hale
May 2 '11 at 15:04
I also received the 9009 error on post and pre build events. Checking the Output tab in Visual Studio shows the problem. In my case I was trying to access a path containing a space
– Phil Hale
May 2 '11 at 15:04
15
15
I had a similar problem to this, but it was the result of spaces in the folder names. Putting the paths in quotes (
"$(SolutionDir)packagesNUnit.2.5.10.11092tools"nunit-console "$(TargetPath)"
) resolved it.– Justin Morgan
Nov 18 '11 at 19:50
I had a similar problem to this, but it was the result of spaces in the folder names. Putting the paths in quotes (
"$(SolutionDir)packagesNUnit.2.5.10.11092tools"nunit-console "$(TargetPath)"
) resolved it.– Justin Morgan
Nov 18 '11 at 19:50
1
1
I encountered a similar issue with a pre-build event that used a Java applet to pre-compile JS and CSS...turns out we had neglected to put the Java Runtime on the server.
– saluce
May 11 '12 at 19:29
I encountered a similar issue with a pre-build event that used a Java applet to pre-compile JS and CSS...turns out we had neglected to put the Java Runtime on the server.
– saluce
May 11 '12 at 19:29
2
2
Is it possible that the
PATH
environment variable gets lost somehow? I get this error every now and then. I have npm install
setup as a pre-build event, and initially it works (so I presume everything is setup), but then randomly it will stop working during the day (generally when switching between solutions / branches I believe), and it will no longer know about npm
. Restarting VS 'fixes' it... meaning my PATH
is setup correctly, but seems to get up by VS. If there was a way to view the env variables from inside VS I could confirm this.– jamiebarrow
Oct 7 '14 at 9:32
Is it possible that the
PATH
environment variable gets lost somehow? I get this error every now and then. I have npm install
setup as a pre-build event, and initially it works (so I presume everything is setup), but then randomly it will stop working during the day (generally when switching between solutions / branches I believe), and it will no longer know about npm
. Restarting VS 'fixes' it... meaning my PATH
is setup correctly, but seems to get up by VS. If there was a way to view the env variables from inside VS I could confirm this.– jamiebarrow
Oct 7 '14 at 9:32
1
1
If you want to protect your build from crashing in different environments, let's say, windows installed on D:, use environment vars in conjunction of @thehhv answer:
%systemroot%System32xcopy ...
– Dorival
Jul 10 '15 at 21:29
If you want to protect your build from crashing in different environments, let's say, windows installed on D:, use environment vars in conjunction of @thehhv answer:
%systemroot%System32xcopy ...
– Dorival
Jul 10 '15 at 21:29
|
show 7 more comments
Error Code 9009 means error file not found. All the underlying reasons posted in the answers here are good inspiration to figure out why, but the error itself simply means a bad path.
1
My issue with file not found was the reference in the csproj file was $(PROGRAMFILES)Microsoft SDKsTypeScripttsc and had to be $(PROGRAMFILES)Microsoft SDKsTypeScript1.0tsc
– RHAD
Jul 10 '14 at 8:41
It's always good to actually answer the question posed.
– gdbj
Sep 19 '17 at 14:45
Thanks for actually answering the first question.
– AntonK
Jan 24 '18 at 0:00
add a comment |
Error Code 9009 means error file not found. All the underlying reasons posted in the answers here are good inspiration to figure out why, but the error itself simply means a bad path.
1
My issue with file not found was the reference in the csproj file was $(PROGRAMFILES)Microsoft SDKsTypeScripttsc and had to be $(PROGRAMFILES)Microsoft SDKsTypeScript1.0tsc
– RHAD
Jul 10 '14 at 8:41
It's always good to actually answer the question posed.
– gdbj
Sep 19 '17 at 14:45
Thanks for actually answering the first question.
– AntonK
Jan 24 '18 at 0:00
add a comment |
Error Code 9009 means error file not found. All the underlying reasons posted in the answers here are good inspiration to figure out why, but the error itself simply means a bad path.
Error Code 9009 means error file not found. All the underlying reasons posted in the answers here are good inspiration to figure out why, but the error itself simply means a bad path.
answered Mar 16 '14 at 5:29
Chris MoschiniChris Moschini
26.6k14123161
26.6k14123161
1
My issue with file not found was the reference in the csproj file was $(PROGRAMFILES)Microsoft SDKsTypeScripttsc and had to be $(PROGRAMFILES)Microsoft SDKsTypeScript1.0tsc
– RHAD
Jul 10 '14 at 8:41
It's always good to actually answer the question posed.
– gdbj
Sep 19 '17 at 14:45
Thanks for actually answering the first question.
– AntonK
Jan 24 '18 at 0:00
add a comment |
1
My issue with file not found was the reference in the csproj file was $(PROGRAMFILES)Microsoft SDKsTypeScripttsc and had to be $(PROGRAMFILES)Microsoft SDKsTypeScript1.0tsc
– RHAD
Jul 10 '14 at 8:41
It's always good to actually answer the question posed.
– gdbj
Sep 19 '17 at 14:45
Thanks for actually answering the first question.
– AntonK
Jan 24 '18 at 0:00
1
1
My issue with file not found was the reference in the csproj file was $(PROGRAMFILES)Microsoft SDKsTypeScripttsc and had to be $(PROGRAMFILES)Microsoft SDKsTypeScript1.0tsc
– RHAD
Jul 10 '14 at 8:41
My issue with file not found was the reference in the csproj file was $(PROGRAMFILES)Microsoft SDKsTypeScripttsc and had to be $(PROGRAMFILES)Microsoft SDKsTypeScript1.0tsc
– RHAD
Jul 10 '14 at 8:41
It's always good to actually answer the question posed.
– gdbj
Sep 19 '17 at 14:45
It's always good to actually answer the question posed.
– gdbj
Sep 19 '17 at 14:45
Thanks for actually answering the first question.
– AntonK
Jan 24 '18 at 0:00
Thanks for actually answering the first question.
– AntonK
Jan 24 '18 at 0:00
add a comment |
It happens when you are missing some environment settings for using Microsoft Visual Studio 2010 x86 tools.
Therefore, try adding as a first command in your post-build steps:
call "$(DevEnvDir)..Toolsvsvars32.bat"
It should be placed before any other command.
It will set environment for using Microsoft Visual Studio 2010 x86 tools.
6
What the.... This really helped! Thanks man! +1
– Marcel
Apr 20 '12 at 12:57
3
Could you help me out - where and into which file do i have to add the linecall "$(DevEnvDir)..Toolsvsvars32.bat"
? Thanks
– surfmuggle
Oct 16 '12 at 19:40
2
I had to add an entry to myPath
environment variable. Check the Output window for more information.
– paqogomez
Dec 6 '13 at 5:19
Caution. This will fail on many build servers: blogs.clariusconsulting.net/kzu/devenvdir-considered-harmful
– George Mauer
Sep 24 '14 at 19:36
2
Thank you, for x64 bit toolchain I solved like so: "$(DevEnvDir)..VCvcvarsall.bat"
– codekiddy
Jan 26 '15 at 21:59
|
show 2 more comments
It happens when you are missing some environment settings for using Microsoft Visual Studio 2010 x86 tools.
Therefore, try adding as a first command in your post-build steps:
call "$(DevEnvDir)..Toolsvsvars32.bat"
It should be placed before any other command.
It will set environment for using Microsoft Visual Studio 2010 x86 tools.
6
What the.... This really helped! Thanks man! +1
– Marcel
Apr 20 '12 at 12:57
3
Could you help me out - where and into which file do i have to add the linecall "$(DevEnvDir)..Toolsvsvars32.bat"
? Thanks
– surfmuggle
Oct 16 '12 at 19:40
2
I had to add an entry to myPath
environment variable. Check the Output window for more information.
– paqogomez
Dec 6 '13 at 5:19
Caution. This will fail on many build servers: blogs.clariusconsulting.net/kzu/devenvdir-considered-harmful
– George Mauer
Sep 24 '14 at 19:36
2
Thank you, for x64 bit toolchain I solved like so: "$(DevEnvDir)..VCvcvarsall.bat"
– codekiddy
Jan 26 '15 at 21:59
|
show 2 more comments
It happens when you are missing some environment settings for using Microsoft Visual Studio 2010 x86 tools.
Therefore, try adding as a first command in your post-build steps:
call "$(DevEnvDir)..Toolsvsvars32.bat"
It should be placed before any other command.
It will set environment for using Microsoft Visual Studio 2010 x86 tools.
It happens when you are missing some environment settings for using Microsoft Visual Studio 2010 x86 tools.
Therefore, try adding as a first command in your post-build steps:
call "$(DevEnvDir)..Toolsvsvars32.bat"
It should be placed before any other command.
It will set environment for using Microsoft Visual Studio 2010 x86 tools.
answered Apr 3 '12 at 9:07
HRKoderHRKoder
1,09188
1,09188
6
What the.... This really helped! Thanks man! +1
– Marcel
Apr 20 '12 at 12:57
3
Could you help me out - where and into which file do i have to add the linecall "$(DevEnvDir)..Toolsvsvars32.bat"
? Thanks
– surfmuggle
Oct 16 '12 at 19:40
2
I had to add an entry to myPath
environment variable. Check the Output window for more information.
– paqogomez
Dec 6 '13 at 5:19
Caution. This will fail on many build servers: blogs.clariusconsulting.net/kzu/devenvdir-considered-harmful
– George Mauer
Sep 24 '14 at 19:36
2
Thank you, for x64 bit toolchain I solved like so: "$(DevEnvDir)..VCvcvarsall.bat"
– codekiddy
Jan 26 '15 at 21:59
|
show 2 more comments
6
What the.... This really helped! Thanks man! +1
– Marcel
Apr 20 '12 at 12:57
3
Could you help me out - where and into which file do i have to add the linecall "$(DevEnvDir)..Toolsvsvars32.bat"
? Thanks
– surfmuggle
Oct 16 '12 at 19:40
2
I had to add an entry to myPath
environment variable. Check the Output window for more information.
– paqogomez
Dec 6 '13 at 5:19
Caution. This will fail on many build servers: blogs.clariusconsulting.net/kzu/devenvdir-considered-harmful
– George Mauer
Sep 24 '14 at 19:36
2
Thank you, for x64 bit toolchain I solved like so: "$(DevEnvDir)..VCvcvarsall.bat"
– codekiddy
Jan 26 '15 at 21:59
6
6
What the.... This really helped! Thanks man! +1
– Marcel
Apr 20 '12 at 12:57
What the.... This really helped! Thanks man! +1
– Marcel
Apr 20 '12 at 12:57
3
3
Could you help me out - where and into which file do i have to add the line
call "$(DevEnvDir)..Toolsvsvars32.bat"
? Thanks– surfmuggle
Oct 16 '12 at 19:40
Could you help me out - where and into which file do i have to add the line
call "$(DevEnvDir)..Toolsvsvars32.bat"
? Thanks– surfmuggle
Oct 16 '12 at 19:40
2
2
I had to add an entry to my
Path
environment variable. Check the Output window for more information.– paqogomez
Dec 6 '13 at 5:19
I had to add an entry to my
Path
environment variable. Check the Output window for more information.– paqogomez
Dec 6 '13 at 5:19
Caution. This will fail on many build servers: blogs.clariusconsulting.net/kzu/devenvdir-considered-harmful
– George Mauer
Sep 24 '14 at 19:36
Caution. This will fail on many build servers: blogs.clariusconsulting.net/kzu/devenvdir-considered-harmful
– George Mauer
Sep 24 '14 at 19:36
2
2
Thank you, for x64 bit toolchain I solved like so: "$(DevEnvDir)..VCvcvarsall.bat"
– codekiddy
Jan 26 '15 at 21:59
Thank you, for x64 bit toolchain I solved like so: "$(DevEnvDir)..VCvcvarsall.bat"
– codekiddy
Jan 26 '15 at 21:59
|
show 2 more comments
Most probably you have space in your resultant path.
You can work around this by quoting the paths, thus allowing spaces. For example:
xcopy "$(SolutionDir)Folder NameFile To Copy.ext" "$(TargetDir)" /R /Y /I
9
+1 - This is exactly the problem I was having. A command in my post-build worked when I built the project locally, but failed when it was built on the build server. I just placed the command between double quotes to fix it. Thanks.
– sheikhjabootie
Sep 29 '11 at 3:14
So is it reasonable to speculate that error 9009 is "file not found"..? Personally, I think the question "what is MSBuild error 9009?" should be perfectly fine as a stand-alone question, but directed to Microsoft!
– The Dag
Jul 1 '13 at 14:48
add a comment |
Most probably you have space in your resultant path.
You can work around this by quoting the paths, thus allowing spaces. For example:
xcopy "$(SolutionDir)Folder NameFile To Copy.ext" "$(TargetDir)" /R /Y /I
9
+1 - This is exactly the problem I was having. A command in my post-build worked when I built the project locally, but failed when it was built on the build server. I just placed the command between double quotes to fix it. Thanks.
– sheikhjabootie
Sep 29 '11 at 3:14
So is it reasonable to speculate that error 9009 is "file not found"..? Personally, I think the question "what is MSBuild error 9009?" should be perfectly fine as a stand-alone question, but directed to Microsoft!
– The Dag
Jul 1 '13 at 14:48
add a comment |
Most probably you have space in your resultant path.
You can work around this by quoting the paths, thus allowing spaces. For example:
xcopy "$(SolutionDir)Folder NameFile To Copy.ext" "$(TargetDir)" /R /Y /I
Most probably you have space in your resultant path.
You can work around this by quoting the paths, thus allowing spaces. For example:
xcopy "$(SolutionDir)Folder NameFile To Copy.ext" "$(TargetDir)" /R /Y /I
edited Aug 30 '17 at 18:01
Cody Gray♦
195k35382471
195k35382471
answered Aug 13 '10 at 5:05
NileshChauhanNileshChauhan
4,36622442
4,36622442
9
+1 - This is exactly the problem I was having. A command in my post-build worked when I built the project locally, but failed when it was built on the build server. I just placed the command between double quotes to fix it. Thanks.
– sheikhjabootie
Sep 29 '11 at 3:14
So is it reasonable to speculate that error 9009 is "file not found"..? Personally, I think the question "what is MSBuild error 9009?" should be perfectly fine as a stand-alone question, but directed to Microsoft!
– The Dag
Jul 1 '13 at 14:48
add a comment |
9
+1 - This is exactly the problem I was having. A command in my post-build worked when I built the project locally, but failed when it was built on the build server. I just placed the command between double quotes to fix it. Thanks.
– sheikhjabootie
Sep 29 '11 at 3:14
So is it reasonable to speculate that error 9009 is "file not found"..? Personally, I think the question "what is MSBuild error 9009?" should be perfectly fine as a stand-alone question, but directed to Microsoft!
– The Dag
Jul 1 '13 at 14:48
9
9
+1 - This is exactly the problem I was having. A command in my post-build worked when I built the project locally, but failed when it was built on the build server. I just placed the command between double quotes to fix it. Thanks.
– sheikhjabootie
Sep 29 '11 at 3:14
+1 - This is exactly the problem I was having. A command in my post-build worked when I built the project locally, but failed when it was built on the build server. I just placed the command between double quotes to fix it. Thanks.
– sheikhjabootie
Sep 29 '11 at 3:14
So is it reasonable to speculate that error 9009 is "file not found"..? Personally, I think the question "what is MSBuild error 9009?" should be perfectly fine as a stand-alone question, but directed to Microsoft!
– The Dag
Jul 1 '13 at 14:48
So is it reasonable to speculate that error 9009 is "file not found"..? Personally, I think the question "what is MSBuild error 9009?" should be perfectly fine as a stand-alone question, but directed to Microsoft!
– The Dag
Jul 1 '13 at 14:48
add a comment |
Had the same variable after changing PATH variable from Environmental Variables in Win 7. Changing back to default helped.
add a comment |
Had the same variable after changing PATH variable from Environmental Variables in Win 7. Changing back to default helped.
add a comment |
Had the same variable after changing PATH variable from Environmental Variables in Win 7. Changing back to default helped.
Had the same variable after changing PATH variable from Environmental Variables in Win 7. Changing back to default helped.
answered Jun 19 '12 at 9:07
Radomir SzewczykRadomir Szewczyk
11112
11112
add a comment |
add a comment |
I have had the error 9009 when my post build event script was trying to run a batch file that did not exist in the path specified.
add a comment |
I have had the error 9009 when my post build event script was trying to run a batch file that did not exist in the path specified.
add a comment |
I have had the error 9009 when my post build event script was trying to run a batch file that did not exist in the path specified.
I have had the error 9009 when my post build event script was trying to run a batch file that did not exist in the path specified.
answered Jun 16 '11 at 3:34
SleepyBoBosSleepyBoBos
8761815
8761815
add a comment |
add a comment |
If the script actually does what it needs to do and it's just Visual Studio bugging you about the error you could just add:
exit 0
to the end of you script.
3
hiding any potential error should not be the way to go
– igelineau
Jan 9 '17 at 17:05
I agree this should not be masked
– AltF4_
Apr 11 '17 at 14:13
add a comment |
If the script actually does what it needs to do and it's just Visual Studio bugging you about the error you could just add:
exit 0
to the end of you script.
3
hiding any potential error should not be the way to go
– igelineau
Jan 9 '17 at 17:05
I agree this should not be masked
– AltF4_
Apr 11 '17 at 14:13
add a comment |
If the script actually does what it needs to do and it's just Visual Studio bugging you about the error you could just add:
exit 0
to the end of you script.
If the script actually does what it needs to do and it's just Visual Studio bugging you about the error you could just add:
exit 0
to the end of you script.
answered May 4 '11 at 8:06
hakksorhakksor
7691613
7691613
3
hiding any potential error should not be the way to go
– igelineau
Jan 9 '17 at 17:05
I agree this should not be masked
– AltF4_
Apr 11 '17 at 14:13
add a comment |
3
hiding any potential error should not be the way to go
– igelineau
Jan 9 '17 at 17:05
I agree this should not be masked
– AltF4_
Apr 11 '17 at 14:13
3
3
hiding any potential error should not be the way to go
– igelineau
Jan 9 '17 at 17:05
hiding any potential error should not be the way to go
– igelineau
Jan 9 '17 at 17:05
I agree this should not be masked
– AltF4_
Apr 11 '17 at 14:13
I agree this should not be masked
– AltF4_
Apr 11 '17 at 14:13
add a comment |
I caused this error to happen when I redacted my Path environment variable. After editing, I accidentally added Path=
to the beginning of the path string. With such a malformed path variable, I was unable to run XCopy at the command line (no command or file not found), and Visual Studio refused to run post-build step, citing error with code 9009.
XCopy commonly resides in C:WindowsSystem32. Once the Path environment variable allowed XCopy to get resolved at DOS prompt, Visual Studio built my solution well.
add a comment |
I caused this error to happen when I redacted my Path environment variable. After editing, I accidentally added Path=
to the beginning of the path string. With such a malformed path variable, I was unable to run XCopy at the command line (no command or file not found), and Visual Studio refused to run post-build step, citing error with code 9009.
XCopy commonly resides in C:WindowsSystem32. Once the Path environment variable allowed XCopy to get resolved at DOS prompt, Visual Studio built my solution well.
add a comment |
I caused this error to happen when I redacted my Path environment variable. After editing, I accidentally added Path=
to the beginning of the path string. With such a malformed path variable, I was unable to run XCopy at the command line (no command or file not found), and Visual Studio refused to run post-build step, citing error with code 9009.
XCopy commonly resides in C:WindowsSystem32. Once the Path environment variable allowed XCopy to get resolved at DOS prompt, Visual Studio built my solution well.
I caused this error to happen when I redacted my Path environment variable. After editing, I accidentally added Path=
to the beginning of the path string. With such a malformed path variable, I was unable to run XCopy at the command line (no command or file not found), and Visual Studio refused to run post-build step, citing error with code 9009.
XCopy commonly resides in C:WindowsSystem32. Once the Path environment variable allowed XCopy to get resolved at DOS prompt, Visual Studio built my solution well.
answered Jan 2 '14 at 16:23
GregCGregC
6,12623958
6,12623958
add a comment |
add a comment |
Check the spelling. I was trying to call an executable but had the name misspelled and it gave me the exited with code 9009
message.
1
To that add a check for the existence of the executable on your system at all.
– Joshua Drake
Dec 5 '13 at 15:42
add a comment |
Check the spelling. I was trying to call an executable but had the name misspelled and it gave me the exited with code 9009
message.
1
To that add a check for the existence of the executable on your system at all.
– Joshua Drake
Dec 5 '13 at 15:42
add a comment |
Check the spelling. I was trying to call an executable but had the name misspelled and it gave me the exited with code 9009
message.
Check the spelling. I was trying to call an executable but had the name misspelled and it gave me the exited with code 9009
message.
answered Jun 6 '12 at 20:17
MarkMark
1,36812042
1,36812042
1
To that add a check for the existence of the executable on your system at all.
– Joshua Drake
Dec 5 '13 at 15:42
add a comment |
1
To that add a check for the existence of the executable on your system at all.
– Joshua Drake
Dec 5 '13 at 15:42
1
1
To that add a check for the existence of the executable on your system at all.
– Joshua Drake
Dec 5 '13 at 15:42
To that add a check for the existence of the executable on your system at all.
– Joshua Drake
Dec 5 '13 at 15:42
add a comment |
My exact error was
The command "iscc /DConfigurationName=Debug "C:ProjectsBlahblahblahsetup.iss"" exited with code 9009.
9009 means file not found, but it actually couldn't find the "iscc" part of the command.
I fixed it by adding ";C:Program FilesInno Setup 5 (x86)"
to the system environment variable "path"
add a comment |
My exact error was
The command "iscc /DConfigurationName=Debug "C:ProjectsBlahblahblahsetup.iss"" exited with code 9009.
9009 means file not found, but it actually couldn't find the "iscc" part of the command.
I fixed it by adding ";C:Program FilesInno Setup 5 (x86)"
to the system environment variable "path"
add a comment |
My exact error was
The command "iscc /DConfigurationName=Debug "C:ProjectsBlahblahblahsetup.iss"" exited with code 9009.
9009 means file not found, but it actually couldn't find the "iscc" part of the command.
I fixed it by adding ";C:Program FilesInno Setup 5 (x86)"
to the system environment variable "path"
My exact error was
The command "iscc /DConfigurationName=Debug "C:ProjectsBlahblahblahsetup.iss"" exited with code 9009.
9009 means file not found, but it actually couldn't find the "iscc" part of the command.
I fixed it by adding ";C:Program FilesInno Setup 5 (x86)"
to the system environment variable "path"
answered Oct 16 '14 at 22:17
scwscw
2,91262242
2,91262242
add a comment |
add a comment |
Another variant:
today I call python interpreter from cron in win32 and take ExitCode (%ERRORLEVEL%) 9009, because system account used by cron don't have path to Python directory.
add a comment |
Another variant:
today I call python interpreter from cron in win32 and take ExitCode (%ERRORLEVEL%) 9009, because system account used by cron don't have path to Python directory.
add a comment |
Another variant:
today I call python interpreter from cron in win32 and take ExitCode (%ERRORLEVEL%) 9009, because system account used by cron don't have path to Python directory.
Another variant:
today I call python interpreter from cron in win32 and take ExitCode (%ERRORLEVEL%) 9009, because system account used by cron don't have path to Python directory.
answered Dec 24 '09 at 9:18
Denis BarmenkovDenis Barmenkov
2,13511218
2,13511218
add a comment |
add a comment |
In my case I had to "CD" (Change Directory) to the proper directory first, before calling the command, since the executable I was calling was in my project directory.
Example:
cd "$(SolutionDir)"
call "$(SolutionDir)build.bat"
This fixed the problem for me running Visual Studio's devenv.exe, but you don't need to specify the folder the second time, just'call build.bat will do
– FrinkTheBrave
May 6 '17 at 7:44
add a comment |
In my case I had to "CD" (Change Directory) to the proper directory first, before calling the command, since the executable I was calling was in my project directory.
Example:
cd "$(SolutionDir)"
call "$(SolutionDir)build.bat"
This fixed the problem for me running Visual Studio's devenv.exe, but you don't need to specify the folder the second time, just'call build.bat will do
– FrinkTheBrave
May 6 '17 at 7:44
add a comment |
In my case I had to "CD" (Change Directory) to the proper directory first, before calling the command, since the executable I was calling was in my project directory.
Example:
cd "$(SolutionDir)"
call "$(SolutionDir)build.bat"
In my case I had to "CD" (Change Directory) to the proper directory first, before calling the command, since the executable I was calling was in my project directory.
Example:
cd "$(SolutionDir)"
call "$(SolutionDir)build.bat"
answered May 3 '13 at 20:09
Mathias Lykkegaard LorenzenMathias Lykkegaard Lorenzen
6,9701871142
6,9701871142
This fixed the problem for me running Visual Studio's devenv.exe, but you don't need to specify the folder the second time, just'call build.bat will do
– FrinkTheBrave
May 6 '17 at 7:44
add a comment |
This fixed the problem for me running Visual Studio's devenv.exe, but you don't need to specify the folder the second time, just'call build.bat will do
– FrinkTheBrave
May 6 '17 at 7:44
This fixed the problem for me running Visual Studio's devenv.exe, but you don't need to specify the folder the second time, just'call build.bat will do
– FrinkTheBrave
May 6 '17 at 7:44
This fixed the problem for me running Visual Studio's devenv.exe, but you don't need to specify the folder the second time, just'call build.bat will do
– FrinkTheBrave
May 6 '17 at 7:44
add a comment |
The problem in my case occurred when I tried to use a command on the command-line for the Post-build event in my Test Class Library. When you use quotation marks like so:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit" "$(TargetPath)"
or if you're using the console:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit-console" "$(TargetPath)"
This fixed the issue for me.
add a comment |
The problem in my case occurred when I tried to use a command on the command-line for the Post-build event in my Test Class Library. When you use quotation marks like so:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit" "$(TargetPath)"
or if you're using the console:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit-console" "$(TargetPath)"
This fixed the issue for me.
add a comment |
The problem in my case occurred when I tried to use a command on the command-line for the Post-build event in my Test Class Library. When you use quotation marks like so:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit" "$(TargetPath)"
or if you're using the console:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit-console" "$(TargetPath)"
This fixed the issue for me.
The problem in my case occurred when I tried to use a command on the command-line for the Post-build event in my Test Class Library. When you use quotation marks like so:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit" "$(TargetPath)"
or if you're using the console:
"$(SolutionDir)packagesNUnit.Runners.2.6.2toolsnunit-console" "$(TargetPath)"
This fixed the issue for me.
edited Nov 21 '14 at 17:31
perlyking
382412
382412
answered May 15 '13 at 14:52
pdvriespdvries
1,1952818
1,1952818
add a comment |
add a comment |
Also, make sure there are no line breaks in the post build event editing window on your project. Sometimes copying the xcopy command from the web when it's multi-line and pasting it into VS will cause a problem.
Although jesse makes a good point about not having line breaks in the middle of an xcopy command, note that in the general case it is valid to have line breaks in this field; each line should be interpreted as its own command.
– RJFalconer
Jan 15 '13 at 17:12
add a comment |
Also, make sure there are no line breaks in the post build event editing window on your project. Sometimes copying the xcopy command from the web when it's multi-line and pasting it into VS will cause a problem.
Although jesse makes a good point about not having line breaks in the middle of an xcopy command, note that in the general case it is valid to have line breaks in this field; each line should be interpreted as its own command.
– RJFalconer
Jan 15 '13 at 17:12
add a comment |
Also, make sure there are no line breaks in the post build event editing window on your project. Sometimes copying the xcopy command from the web when it's multi-line and pasting it into VS will cause a problem.
Also, make sure there are no line breaks in the post build event editing window on your project. Sometimes copying the xcopy command from the web when it's multi-line and pasting it into VS will cause a problem.
answered Jan 5 '12 at 20:27
jesse pjesse p
311
311
Although jesse makes a good point about not having line breaks in the middle of an xcopy command, note that in the general case it is valid to have line breaks in this field; each line should be interpreted as its own command.
– RJFalconer
Jan 15 '13 at 17:12
add a comment |
Although jesse makes a good point about not having line breaks in the middle of an xcopy command, note that in the general case it is valid to have line breaks in this field; each line should be interpreted as its own command.
– RJFalconer
Jan 15 '13 at 17:12
Although jesse makes a good point about not having line breaks in the middle of an xcopy command, note that in the general case it is valid to have line breaks in this field; each line should be interpreted as its own command.
– RJFalconer
Jan 15 '13 at 17:12
Although jesse makes a good point about not having line breaks in the middle of an xcopy command, note that in the general case it is valid to have line breaks in this field; each line should be interpreted as its own command.
– RJFalconer
Jan 15 '13 at 17:12
add a comment |
I added "> myFile.txt" to the end of the line in the pre-build step and then inspected the file for the actual error.
add a comment |
I added "> myFile.txt" to the end of the line in the pre-build step and then inspected the file for the actual error.
add a comment |
I added "> myFile.txt" to the end of the line in the pre-build step and then inspected the file for the actual error.
I added "> myFile.txt" to the end of the line in the pre-build step and then inspected the file for the actual error.
answered Aug 30 '13 at 13:19
PhilipPhilip
1285
1285
add a comment |
add a comment |
For me, disk space was low, and files that couldn't be written were expected to be present later. Other answers mentioned missing files (or misnamed/improperly referenced-by-name files)--but the root cause was lack of disk space.
add a comment |
For me, disk space was low, and files that couldn't be written were expected to be present later. Other answers mentioned missing files (or misnamed/improperly referenced-by-name files)--but the root cause was lack of disk space.
add a comment |
For me, disk space was low, and files that couldn't be written were expected to be present later. Other answers mentioned missing files (or misnamed/improperly referenced-by-name files)--but the root cause was lack of disk space.
For me, disk space was low, and files that couldn't be written were expected to be present later. Other answers mentioned missing files (or misnamed/improperly referenced-by-name files)--but the root cause was lack of disk space.
answered Jul 11 '14 at 0:41
ErikEErikE
33.9k14117162
33.9k14117162
add a comment |
add a comment |
Yet another variant of file not found, because of spaces in the path. In my case in the msbuild script. I needed to use HTML style &quot; strings within the exec command.
<!-- Needs quotes example with my Buildscript.msbuild file -->
<Exec Command=""$(MSBuildThisFileDirectory)wixwixscript.bat" $(VersionNumber) $(VersionNumberShort)"
ContinueOnError="false"
IgnoreExitCode="false"
WorkingDirectory="$(MSBuildProjectDirectory)wix" />
add a comment |
Yet another variant of file not found, because of spaces in the path. In my case in the msbuild script. I needed to use HTML style &quot; strings within the exec command.
<!-- Needs quotes example with my Buildscript.msbuild file -->
<Exec Command=""$(MSBuildThisFileDirectory)wixwixscript.bat" $(VersionNumber) $(VersionNumberShort)"
ContinueOnError="false"
IgnoreExitCode="false"
WorkingDirectory="$(MSBuildProjectDirectory)wix" />
add a comment |
Yet another variant of file not found, because of spaces in the path. In my case in the msbuild script. I needed to use HTML style &quot; strings within the exec command.
<!-- Needs quotes example with my Buildscript.msbuild file -->
<Exec Command=""$(MSBuildThisFileDirectory)wixwixscript.bat" $(VersionNumber) $(VersionNumberShort)"
ContinueOnError="false"
IgnoreExitCode="false"
WorkingDirectory="$(MSBuildProjectDirectory)wix" />
Yet another variant of file not found, because of spaces in the path. In my case in the msbuild script. I needed to use HTML style &quot; strings within the exec command.
<!-- Needs quotes example with my Buildscript.msbuild file -->
<Exec Command=""$(MSBuildThisFileDirectory)wixwixscript.bat" $(VersionNumber) $(VersionNumberShort)"
ContinueOnError="false"
IgnoreExitCode="false"
WorkingDirectory="$(MSBuildProjectDirectory)wix" />
answered Jun 27 '16 at 14:26
Ben ButzerBen Butzer
406715
406715
add a comment |
add a comment |
Same as the other answers, in my case it was because of the missing file. To know what is the missing file, you can go to the output window and it will show you straight away what went missing.
To open the output window in Visual Studio:
- Ctrl+Alt+O
- View > Output
add a comment |
Same as the other answers, in my case it was because of the missing file. To know what is the missing file, you can go to the output window and it will show you straight away what went missing.
To open the output window in Visual Studio:
- Ctrl+Alt+O
- View > Output
add a comment |
Same as the other answers, in my case it was because of the missing file. To know what is the missing file, you can go to the output window and it will show you straight away what went missing.
To open the output window in Visual Studio:
- Ctrl+Alt+O
- View > Output
Same as the other answers, in my case it was because of the missing file. To know what is the missing file, you can go to the output window and it will show you straight away what went missing.
To open the output window in Visual Studio:
- Ctrl+Alt+O
- View > Output
answered Jun 8 '17 at 4:04
Marvin Glenn LacunaMarvin Glenn Lacuna
94611022
94611022
add a comment |
add a comment |
This is pretty basic, I had this problem, and embarrassing simple fail.
Application use Command line arguments, I removed them and then added them back. Suddenly the project failed to build.
Visual Studio -> Project Properties -> verify that you use 'Debug' tab (not 'Build Events' tab) -> Command Line Arguments
I used the and Post/Pre-build text area, which was wrong this case.
add a comment |
This is pretty basic, I had this problem, and embarrassing simple fail.
Application use Command line arguments, I removed them and then added them back. Suddenly the project failed to build.
Visual Studio -> Project Properties -> verify that you use 'Debug' tab (not 'Build Events' tab) -> Command Line Arguments
I used the and Post/Pre-build text area, which was wrong this case.
add a comment |
This is pretty basic, I had this problem, and embarrassing simple fail.
Application use Command line arguments, I removed them and then added them back. Suddenly the project failed to build.
Visual Studio -> Project Properties -> verify that you use 'Debug' tab (not 'Build Events' tab) -> Command Line Arguments
I used the and Post/Pre-build text area, which was wrong this case.
This is pretty basic, I had this problem, and embarrassing simple fail.
Application use Command line arguments, I removed them and then added them back. Suddenly the project failed to build.
Visual Studio -> Project Properties -> verify that you use 'Debug' tab (not 'Build Events' tab) -> Command Line Arguments
I used the and Post/Pre-build text area, which was wrong this case.
answered Dec 8 '14 at 12:03
Niike2Niike2
6551720
6551720
add a comment |
add a comment |
For me it happened after upgrade nuget packages from one PostSharp version to next one in a big solution (~80 project).
I've got compiler errors for projects that have commands in PreBuild events.
'cmd' is not recognized as an internal or external command, operable program or batch file.
C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1249,5): error MSB3073: The command "cmd /c C:GitReposmainServiceInterfacesDEV.ConfigPreBuild.cmd ServiceInterfaces" exited with code 9009.
PATH variable was corrupted becoming too long with multiple repeated paths related to PostSharp.Patterns.Diagnostics.
When I closed Visual Studio and opened it again, the problem was fixed.
add a comment |
For me it happened after upgrade nuget packages from one PostSharp version to next one in a big solution (~80 project).
I've got compiler errors for projects that have commands in PreBuild events.
'cmd' is not recognized as an internal or external command, operable program or batch file.
C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1249,5): error MSB3073: The command "cmd /c C:GitReposmainServiceInterfacesDEV.ConfigPreBuild.cmd ServiceInterfaces" exited with code 9009.
PATH variable was corrupted becoming too long with multiple repeated paths related to PostSharp.Patterns.Diagnostics.
When I closed Visual Studio and opened it again, the problem was fixed.
add a comment |
For me it happened after upgrade nuget packages from one PostSharp version to next one in a big solution (~80 project).
I've got compiler errors for projects that have commands in PreBuild events.
'cmd' is not recognized as an internal or external command, operable program or batch file.
C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1249,5): error MSB3073: The command "cmd /c C:GitReposmainServiceInterfacesDEV.ConfigPreBuild.cmd ServiceInterfaces" exited with code 9009.
PATH variable was corrupted becoming too long with multiple repeated paths related to PostSharp.Patterns.Diagnostics.
When I closed Visual Studio and opened it again, the problem was fixed.
For me it happened after upgrade nuget packages from one PostSharp version to next one in a big solution (~80 project).
I've got compiler errors for projects that have commands in PreBuild events.
'cmd' is not recognized as an internal or external command, operable program or batch file.
C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1249,5): error MSB3073: The command "cmd /c C:GitReposmainServiceInterfacesDEV.ConfigPreBuild.cmd ServiceInterfaces" exited with code 9009.
PATH variable was corrupted becoming too long with multiple repeated paths related to PostSharp.Patterns.Diagnostics.
When I closed Visual Studio and opened it again, the problem was fixed.
answered Apr 23 '16 at 12:12
Michael FreidgeimMichael Freidgeim
13.4k689113
13.4k689113
add a comment |
add a comment |
My solution was just simple as: have you tried turning it off and on again? So I restarted the computer and the issue was gone.
add a comment |
My solution was just simple as: have you tried turning it off and on again? So I restarted the computer and the issue was gone.
add a comment |
My solution was just simple as: have you tried turning it off and on again? So I restarted the computer and the issue was gone.
My solution was just simple as: have you tried turning it off and on again? So I restarted the computer and the issue was gone.
answered Oct 24 '16 at 20:32
krzyszt0fdkrzyszt0fd
717
717
add a comment |
add a comment |
I also ran into this 9009
problem when facing an overwrite situation.
Basically, if the file already exists and you have not specified the /y
switch (which automatically overwrites) this error can happen when run from a build.
add a comment |
I also ran into this 9009
problem when facing an overwrite situation.
Basically, if the file already exists and you have not specified the /y
switch (which automatically overwrites) this error can happen when run from a build.
add a comment |
I also ran into this 9009
problem when facing an overwrite situation.
Basically, if the file already exists and you have not specified the /y
switch (which automatically overwrites) this error can happen when run from a build.
I also ran into this 9009
problem when facing an overwrite situation.
Basically, if the file already exists and you have not specified the /y
switch (which automatically overwrites) this error can happen when run from a build.
answered Aug 29 '17 at 18:32
Travis VromanTravis Vroman
628
628
add a comment |
add a comment |
tfa's answer has been downvoted, but actually can cause this issue.
Thanks to hanzolo, I looked in the output window and found the following:
3>'gulp' is not recognized as an internal or external command,
3>operable program or batch file.
3>D:dev<filepath>Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009.
After running npm install -g gulp
, I stopped getting this error. If you're getting this error in Visual Studio, check the output window and see if the issue is an unset environment variable.
add a comment |
tfa's answer has been downvoted, but actually can cause this issue.
Thanks to hanzolo, I looked in the output window and found the following:
3>'gulp' is not recognized as an internal or external command,
3>operable program or batch file.
3>D:dev<filepath>Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009.
After running npm install -g gulp
, I stopped getting this error. If you're getting this error in Visual Studio, check the output window and see if the issue is an unset environment variable.
add a comment |
tfa's answer has been downvoted, but actually can cause this issue.
Thanks to hanzolo, I looked in the output window and found the following:
3>'gulp' is not recognized as an internal or external command,
3>operable program or batch file.
3>D:dev<filepath>Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009.
After running npm install -g gulp
, I stopped getting this error. If you're getting this error in Visual Studio, check the output window and see if the issue is an unset environment variable.
tfa's answer has been downvoted, but actually can cause this issue.
Thanks to hanzolo, I looked in the output window and found the following:
3>'gulp' is not recognized as an internal or external command,
3>operable program or batch file.
3>D:dev<filepath>Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009.
After running npm install -g gulp
, I stopped getting this error. If you're getting this error in Visual Studio, check the output window and see if the issue is an unset environment variable.
answered Mar 27 '18 at 15:54
R. SalisburyR. Salisbury
1,3621014
1,3621014
add a comment |
add a comment |
Actually I noticed that for some reason the %windir% environment variable sometimes get erased. What worked for me was re-set the windir environment variable to c:windows, restart VS, and that's it. That way you prevent having to modify the solution files.
add a comment |
Actually I noticed that for some reason the %windir% environment variable sometimes get erased. What worked for me was re-set the windir environment variable to c:windows, restart VS, and that's it. That way you prevent having to modify the solution files.
add a comment |
Actually I noticed that for some reason the %windir% environment variable sometimes get erased. What worked for me was re-set the windir environment variable to c:windows, restart VS, and that's it. That way you prevent having to modify the solution files.
Actually I noticed that for some reason the %windir% environment variable sometimes get erased. What worked for me was re-set the windir environment variable to c:windows, restart VS, and that's it. That way you prevent having to modify the solution files.
answered Jul 30 '14 at 12:42
Charles FCharles F
995
995
add a comment |
add a comment |
At least in Visual Studio Ultimate 2013, Version 12.0.30723.00 Update 3, it's not possible to separate an if/else statement with a line break:
works:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local) else (echo server)
doesn't work:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local)
else (echo server)
add a comment |
At least in Visual Studio Ultimate 2013, Version 12.0.30723.00 Update 3, it's not possible to separate an if/else statement with a line break:
works:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local) else (echo server)
doesn't work:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local)
else (echo server)
add a comment |
At least in Visual Studio Ultimate 2013, Version 12.0.30723.00 Update 3, it's not possible to separate an if/else statement with a line break:
works:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local) else (echo server)
doesn't work:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local)
else (echo server)
At least in Visual Studio Ultimate 2013, Version 12.0.30723.00 Update 3, it's not possible to separate an if/else statement with a line break:
works:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local) else (echo server)
doesn't work:
if '$(BuildingInsideVisualStudio)' == 'true' (echo local)
else (echo server)
answered Jun 10 '15 at 12:59
it-freelancer-magazin.deit-freelancer-magazin.de
13313
13313
add a comment |
add a comment |
Yet another reason:
If your pre-build event references another projects bin path and you see this error when running msbuild, but not Visual Studio, then you have to manually arrange the projects in the *.sln file (with a text editor) so that the project you are targeting in the event is built before the event's project. In other words, msbuild uses the order that projects are listed in the *.sln file whereas VS uses knowledge of project dependencies. I had this happen when a tool that creates a database to be included in a wixproj was listed after the wixproj.
add a comment |
Yet another reason:
If your pre-build event references another projects bin path and you see this error when running msbuild, but not Visual Studio, then you have to manually arrange the projects in the *.sln file (with a text editor) so that the project you are targeting in the event is built before the event's project. In other words, msbuild uses the order that projects are listed in the *.sln file whereas VS uses knowledge of project dependencies. I had this happen when a tool that creates a database to be included in a wixproj was listed after the wixproj.
add a comment |
Yet another reason:
If your pre-build event references another projects bin path and you see this error when running msbuild, but not Visual Studio, then you have to manually arrange the projects in the *.sln file (with a text editor) so that the project you are targeting in the event is built before the event's project. In other words, msbuild uses the order that projects are listed in the *.sln file whereas VS uses knowledge of project dependencies. I had this happen when a tool that creates a database to be included in a wixproj was listed after the wixproj.
Yet another reason:
If your pre-build event references another projects bin path and you see this error when running msbuild, but not Visual Studio, then you have to manually arrange the projects in the *.sln file (with a text editor) so that the project you are targeting in the event is built before the event's project. In other words, msbuild uses the order that projects are listed in the *.sln file whereas VS uses knowledge of project dependencies. I had this happen when a tool that creates a database to be included in a wixproj was listed after the wixproj.
answered Jul 8 '15 at 17:56
NovaterataNovaterata
2,161927
2,161927
add a comment |
add a comment |
I think in my case there were russian symbols in path (all projects were in user folder). When I put solution in another folder (directly on disk), everything became ok.
add a comment |
I think in my case there were russian symbols in path (all projects were in user folder). When I put solution in another folder (directly on disk), everything became ok.
add a comment |
I think in my case there were russian symbols in path (all projects were in user folder). When I put solution in another folder (directly on disk), everything became ok.
I think in my case there were russian symbols in path (all projects were in user folder). When I put solution in another folder (directly on disk), everything became ok.
answered Aug 19 '15 at 12:31
Dmitriy DokshinDmitriy Dokshin
545419
545419
add a comment |
add a comment |
My solution was to create a copy of the file and add a step to the build task to copy my file over the original.
add a comment |
My solution was to create a copy of the file and add a step to the build task to copy my file over the original.
add a comment |
My solution was to create a copy of the file and add a step to the build task to copy my file over the original.
My solution was to create a copy of the file and add a step to the build task to copy my file over the original.
answered Jul 21 '17 at 22:08
johnrizzo1johnrizzo1
313
313
add a comment |
add a comment |
You need to make sure you have installed grunt globally
add a comment |
You need to make sure you have installed grunt globally
add a comment |
You need to make sure you have installed grunt globally
You need to make sure you have installed grunt globally
answered Dec 14 '17 at 11:57
tfatfa
383311
383311
add a comment |
add a comment |
protected by Community♦ Jul 20 '12 at 10:06
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
could it possibly be this http://support.microsoft.com/kb/908268
– MaLio
Aug 29 '09 at 17:04
7
The OP isn't coming back to fix this problem, but it has a lot of answers and a lot of Google juice. So, let's try to infer the problem?
– Anthony Mastrean
Mar 15 '12 at 15:04
12
The Output Window gave me some insight into this problem which i was also having
– hanzolo
Oct 9 '12 at 18:21