Related
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.
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:\projectpath\project.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:\windows\system32\xcopy.exe /Y C:\projectpath\project.config C:\compilepath\
Instead of just:
xcopy.exe /Y C:\projectpath\project.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 spaces\ABCDEF\xcopy.exe" /Y C:\projectpath\project.config C:\compilepath\
Note that this example with regards to spaces is not tested.
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.
It happens when you are missing some environment settings for using Microsoft Visual Studio x86 tools.
Therefore, try adding as a first command in your post-build steps:
For Visual Studio 2010 use:
call "$(DevEnvDir)..\Tools\vsvars32.bat"
As #FlorianKoch mentioned in comments, for VS 2017 use:
call "$(DevEnvDir)..\Tools\VsDevCmd.bat"
It should be placed before any other command.
It will set environment for using Microsoft Visual Studio x86 tools.
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 Name\File To Copy.ext" "$(TargetDir)" /R /Y /I
Had the same variable after changing PATH variable from Environmental Variables in Win 7. Changing back to default helped.
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.
My exact error was
The command "iscc /DConfigurationName=Debug "C:\Projects\Blahblahblah\setup.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 Files\Inno Setup 5 (x86)\" to the system environment variable "path"
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"
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:\Windows\System32. Once the Path environment variable allowed XCopy to get resolved at DOS prompt, Visual Studio built my solution well.
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.
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.
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.
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)\packages\NUnit.Runners.2.6.2\tools\nunit" "$(TargetPath)"
or if you're using the console:
"$(SolutionDir)\packages\NUnit.Runners.2.6.2\tools\nunit-console" "$(TargetPath)"
This fixed the issue for me.
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.
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.
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 fixed this by simply restarting Visual Studio - I had just run dotnet tool install xxx in a console window and VS hadn't yet picked up the new environment variables and/or path settings that were changed, so a quick restart fixed the issue.
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 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)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1249,5): error MSB3073: The command "cmd /c C:\GitRepos\main\ServiceInterfaces\DEV.Config\PreBuild.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.
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)\wix\wixscript.bat" $(VersionNumber) $(VersionNumberShort)"
ContinueOnError="false"
IgnoreExitCode="false"
WorkingDirectory="$(MSBuildProjectDirectory)\wix" />
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
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.
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.
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.
Happened with a colleague. If development environment is windows and visual studio project is on C: drive.. Than make sure that visual studio is run with administrator right..
simply right click and 'Run as administrator'. You can also go to the properties of visual studio project -> Advance -> and enable 'Run as administrator'.
I had the same error caused by my post build script and I tried to run the script line by line in the command prompt. Finally I found out the root cause is I did not populate the missing information in the .nuspec file, i.e. replacing all the variables between $ and $ with the actual value, e.g. replacing $author$ with my name
Check the Output tab carefully.
That should reveal the issue reason.
(E.g. in my case it was related to a comment: '#' is not recognized as an internal or external command, operable program or batch file.)
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.
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)
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.
I've read around many questions but I've not been able to find the right answer for me.
As I try to compile a project in VS2012 I have this result:
The command "....\tools\bin\nuget pack Packages\Lib.Html.nuspec - OutputDirectory ....\bin\Zip\Packages -NoPackageAnalysis" exited with code 1.
I looked for the line of code in my .csproj file, where the error should be, and there is:
<Exec Command="$(ProjectDir)..\..\tools\bin\nuget pack $(ProjectDir)Packages\Lib.Html.nuspec -OutputDirectory $(OutputPath)Packages -NoPackageAnalysis" />
What am I doing wrong?
[EDIT]
Launching the Debug of that project and ignoring "building errors", I have a new alert:
"Visual Studio cannot start debugging because the debug target '[project.exe path]' is missing.
Please build the project and retry, or set OutputPath and AssemblyName properties appropriately to point at the correct location for the target assembly."
The first step is figuring out what the error actually is. In order to do this expand your MsBuild output to be diagnostic. This will reveal the actual command executed and hopefully the full error message as well
Tools -> Options
Projects and Solutions -> Build and Run
Change "MsBuild project build output verbosity" to "Diagnostic".
Right click project -> Properties -> Build Events
Remove the text in Post-build event command line text block
For me : I have a white space in my path's folder name G:\Other Imp Projects\Mi.....
Solution 1 :
Remove white space from folder
Example: Other Imp Projects ->> Other_Imp_Projects
Solution 2:
add Quote ("") for your path.
Example: mkdir "$(ProjectDir)$(OutDir)Configurations" //see double quotes
Try to open Visual Studio as admin.
For me, in VS 2013, I had to get rid of missing references under References in the UI project (MVC). Turns out, the ones missing were not referenced.
I know this is too late for sure, but, this could help someone as well.
In my case, i found that the source file is being used by another process which was restricting from copying to the destination. I found that by using command prompt ( just copy paste the post build command to the command prompt and executed gave me the error info).
Make sure that you can copy from the command prompt,
This builds on the answer from JaredPar... and is for VS2017. The same "Build and Run" options are present in Visual Studio 2017.
I was getting, The command "chmod +x """ exited with code 1
In the build output window, I searched for "Error" and found a few errors in the same general area. I was able to click on a link in the build output, and found that the error involved this entry in the .targets file:
<Target Name="ChmodChromeDriver" BeforeTargets="BeforeBuild" Condition="'$(WebDriverPlatform)' != 'win32'">
<Exec Command="chmod +x "$(ChromeDriverSrcPath)"" />
</Target>
In the build output, I also found a more detailed error message that essentially stated that it couldn't find Selenium.WebDriver.ChromeDriver v2.36 in the packages folder it was looking in. I checked the project's NuGet packages, and version 2.36 was indeed in the list of installed packages. I did find the package files for 2.36, and changed the attributes on the folder, subfolders and files from "Read Only" to "Read/Write". Built, but same failure. Sometimes "updating" to a different version of the package and then updating back to the original can fix this type of error. So I "updated" the reference in Manage NuGet packages to 2.37, built, failed, then "updated" back to 2.36, built, and the build succeeded without the "chmod +x" error message.
The project I was building was based on a Visual Studio Project template for Appium test tooling, template name "Develop_Automated_Test".
Check your paths:
If you are using a separate build server for TFS (most likely), make sure that all your paths in the .csproj file match the TFS server paths. I got the above error when checking in the *.csproj file when it had references to my development machine paths and not the TFS server paths.
Remove multi-line commands: Also, try and remove multi-line commands into single-line commands in xml as a precaution. I had the following xml in the *.proj that caused issues in TFS:
<Exec Condition="bl.."
Command=" Blah...
..." </Exec>
Changing the above xml to this worked:
<Exec Condition="bl.." Command=" Blah..." </Exec>
I had the same issue. Tried all the above answers. It was actually complained about a .dll file. I clean the project in Visual Studio but the .dll file still remains, so I deleted in manually from the bin folder and it worked.
Hope this helps someone, but I had prebuild events and post build events and it kept complaining about a file called "Microsoft.Common.CurrentVersion.targets" "The target "CoreBuild" does not exist in the project".
Here's what I did to resolve it:
close the project
delete the .suo file (it regenerates)
Asked a team member to provide a copy of that file (Microsoft.Common.CurrentVersion.targets) - mine was different - I took his.
It compiled - good to go.
I must have wrecked that file somehow.
There was no syntax error in my batch file and it ran fine on a cmd prompt outside VS.
So finally, I added
exit 0
to return a success code explicitly at the end of my batch file and it started working.
For me the output file (.dll) of the same version already existed so I guess it was having trouble overwriting. Even though it has never done it before. Anyways, deleting the existing file and running Rebuild fixed it for me.
If the previous method wouldn't have fixed it, my next check would have been to check if the path length was causing it. So would have change the target folder to somewhere close like the Desktop so that the path isnt too long.
Hint: Search for "Exec Command=" in your project
In my case I found following tag in "Microsoft.Extensions.ApiDescription.Server.targets" file, I remarked the line and it worked for me:
<Exec Command="$(_Command)" LogStandardErrorAsError="true" />
I have a WebApplication which contains reference to WCF services.
While building using Visual Studio 2010, Build fails without any error or warning. However building the .csproj using MsBuild is successful.
Can't figure out what should I try in Visual Studio, to resolve / diagnose the issue. Can you please help out?
I find out that the build has been failing,
From text displayed in status Bar.
From output window:
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
The output tab includes configuration details.
------ Build started: Project: <projectName here> Configuration: Debug Any CPU
I noticed that if "Build + Intellisense" is selected in the Error List, it causes the error messages to be swallowed.
Change this option to "Build Only", and all error messages will be displayed:
I don't know if this is a bug in Visual Studio or what, but it certainly revealed hidden error messages that were the key to pinpointing the failure for me.
Some, like Richard J Foster, have suggested increasing the "MSBuild project build output verbosity" setting to "Diagnostic" (the highest possible option), but this didn't solve the problem for me, as Visual Studio appeared to be suppressing the error message(s) themselves.
As an alternative, you may try to use the raw output messages from the "Output" tab, which haven't been filtered by Visual Studio. Either do an in-place search for the strings "error" and/or "failed", or copy all of the output to your favorite text editor and do a search there.
To ensure that the Output window appears each time you do a build, you can go to Tools → Options → Projects and Solutions → General, and ensure that the option "Show Output Window when build starts" is checked.
As an additional troubleshooting step, it is also possible to build the project from the PowerShell command line by running dotnet build. This will show you the complete build output, including any errors that Visual Studio may be hiding.
I just ran into a similar situation. In my case, a custom action (from the MSBuildVersioning package available on Nuget.org - http://www.nuget.org/packages/MSBuildVersioning/) which appeared in the csproj file's BeforeBuild target was failing without triggering any error message in the normal place.
I was able to determine this by setting the "MSBuild project build output verbosity" (in the latest Visual Studio's Tools tab [Path: Tools > Options > Build and Run]) to "Diagnostic" as shown below. This then showed that the custom action (in my case HgVersionFile) was what had failed.
Here are some things that you can try:
If your solution contains more than one project, try building each project one at a time. (You may even want to try opening each project independently of the solution.)
If applicable, ensure that all of your projects (including dependencies and tests) target the same version of the .NET Framework. (Thanks to user764754 for this suggestion!)
Tip: Check Tools → Extension and Updates to ensure that your packages are up-to-date.
Ensure that all dependency projects are built to target the same platform as your main project.
Try restarting Visual Studio.
As suggested by Bill Yang, try running Visual Studio as Administrator, if you aren't already. (If you are already running Visual Studio as Administrator, perhaps try the opposite?)
Try restarting your computer.
Try "Rebuild All".
Run "Clean Solution", then remove your *vspscc* and *vssscc* files, restart Visual Studio, and then "Rebuild All".
As suggested by Andy, close Visual Studio, delete the .suo file, and restart Visual Studio.
As suggested by Arun Prasad E S, close Visual Studio, delete the .vs folder in your solution directory, and then re-open Visual Studio. (This folder is auto-generated by Visual Studio and contains cache, configuration settings, and more. More details can be found in these questions: Visual Studio - Deleting .vs folder and https://stackoverflow.com/q/48897191.)
As suggested by MrMalith, close Visual Studio, delete the obj folder in your solution directory, clear your temporary folder, and then re-open Visual Studio.
Delete the hidden .vs folder & restart Visual Studio. That worked for me.
I want to expand on Sasse's answer. I had to target the correct version of .NET to resolve the problem.
One project was giving me an error:
"The type or namespace name 'SomeNamespace' does not exist in the namespace 'BeforeSomeNamespace' (are you missing an assembly reference?)".
There was no error in the Error List window but the assembly had a yellow warning sign under "References".
I then saw that the referencing project targeted 4.5.1 and the referenced project 4.6.1. Changing 4.6.1 to 4.5.1 allowed the overall build to succeed.
Nothing was working for me so I deleted the .suo file, restarted VS, cleaned the projected, and then the build would work.
I tried many things like restarting Visual Studio, cleaning and rebuilding the solution, restarting the PC, etc., but none of them worked for me. I was finally able to solve the problem by doing the following:
First of all, make sure all the projects in your solution (including tests) are targeting the same .NET version. Then:
Save pending changes in the project and close Visual Studio
Find the exact location from file explorer and find "obj" file and open it,
Then, delete all the included files (some files won't remove, it doesn't matter, just skip them).
Use run command (by pressing Windows Key + R) and type "%temp%" and press enter to find temporary files.
Finally, delete them all.
On other possibility is that Visual Studio needs to run as Administrator, this might be related to deploying to local IIS server or other deployment need.
Just for the sake of completion and maybe helping someone encountering the same error again in the future, I was using Mahapps metro interface and changed the XAML of one window, but forgot to change the partial class in the code-behind. In that case, the build failed without an error or warning, and I was able to find it out by increasing the verbosity of the output from the settings:
In my case (VS 2019 v16.11.20), disabling Text Editor->C#->Advanced->Enable 'pull' diagnostics in the options solved the issue.
Double check for _underscore.aspx pages in your project.
I had a page and code-behind:
`myPage.aspx` and `myPage.aspx.vb`
when building the project, I'd get errors on the .aspx.vb page stating that properties defined on the .aspx page didn't exist, even though the page itself would build fine and there were NO OTHER ERRORS showing in the output (even with diagnostic level build output).
I then came across a page in the project that was named the same thing but with an underscore: _myPage.aspx - not sure where it came from, I deleted it, and the solution built fine.
I have 2 machines that have the Express version of C# on them.
On one, I can build my solution and my build events execute perfectly. On the other, no matter what is put in the event it always fails. The build output has "C:\Documents in not a valid path" or something to that effect, and points to the line in Microsoft.Common.targets that contains Exec WorkingDirectory="$(OutDir)" whether it is a pre or post build event. I have deleted the targets file along with some of the MSBuild files and then repaired .Net hoping that would fix the problem, but no luck.
Any suggestions on what to do next?
Edit: This is the error that I am getting.
"E:\Programs\Visual Studio 2008\Projects\Work\Brandcode Manager....\Tools\Versioner.exe" "E:\Programs\Visual Studio 2008\Projects\C_Sharp\kjCommonFunctions\kjCommonFunctions\Properties\AssemblyInfo.cs"
'C:\Documents' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the path specified.
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(895,9): error MSB3073: The command ""E:\Programs\Visual Studio 2008\Projects\Work\Brandcode Manager....\Tools\Versioner.exe" "E:\Programs\Visual Studio 2008\Projects\C_Sharp\kjCommonFunctions\kjCommonFunctions\Properties\AssemblyInfo.cs"" exited with code 1.
At a guess I would say it is missing quotes somewhere - ie folders with spaces in the name, assuming the actual path is in C:\Documents and Settings\... but would need to see the real build output and the path of your solution file to give a definative answer
Here's what I ended up figuring out.
The username for the autologon account for the computer I was using (generic logon for our shared laptops) included an ampersand (&). I think that may have been causing the problems. When I created another account on that laptop and then compiled from there both my pre & post-build events worked.
KJ
Two machines. Both with .NET 3.5 and the VS 2008 VC++ SP1 redistributables
A single exe which uses two signed DLLs, one in C++/CLI and one in C#
The exe loads and runs fine on one machine.
On the other, I get "Strong Name Validation Failed" on the C++ executable (HRESULT 0x8013141A)
Any ideas?
Open the command prompt as administrator and enter following commands:
reg DELETE "HKLM\Software\Microsoft\StrongName\Verification" /f
reg ADD "HKLM\Software\Microsoft\StrongName\Verification\*,*" /f
reg DELETE "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification" /f
reg ADD "HKLM\Software\Wow6432Node\Microsoft\StrongName\Verification\*,*" /f
Open the command prompt as administrator and enter the following command:
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\sn.exe" -Vr <dllpath>
Pay attention that the argument are case sensitive.
Source with more details: http://blogs.msdn.com/b/keithmg/archive/2012/03/20/strong-name-validation-failed-exception-from-hresult-0x8013141a.aspx
You must use the 64-bit version of sn.exe on a 64-bit machine. (C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\sn.exe)
Is the one the code runs on a "development" machine where you might have run "sn.exe -Vr AssemblyName.dll" at some stage which would allow you to use a delay signed assembly as if it were fully signed. When you transfer the delay signed assembly to another machine and run it, it will fail strong name validation because it is not fully signed.
In my case, I had the same issue with Visual Studio 2015 and I already had signed the assembly.
I fixed it by this way: Right click on the project which causes the issue -> "Properties" -> "Build" -> Change the value of the "Platform target" field.
I had to change it from Any CPU to x86 but I guess that in function of the project and the library which is failing, you should change its value to x64.
The SN.EXE is Missing in Newer versions of Visual Studio. In Visual studio 2012,
we must use "Developer command prompt for Visual studio 2012". Then Run the command "sn".
Syntax: sn -Vr *,2d58152b8e842be2
where "2d58152b8e842be2" is the public key token shown in the Error message. Somehow this alone did not solve my problem.
If someone can't find 64-bit version of sn.exe, check here:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\sn.exe
You might be able to bypass this on development by going into the project settings -> Signing -> and unchecking "Sign the assembly".
I ran into this today while debugging against a source code copy of the Entity Framework.
I encountered this today and stumbled across http://timgeerts.blogspot.co.uk/2009/08/strong-name-validation-failed.html, which seems to be the solution.
Option 1) Turn off code coverage (in VS 2010, go to Test Settings -› Data and Diagnostics -› Untick the "Enabled" box next to Code Coverage).
Option 2) Add the signing key file to the code coverage configuration (in VS 2010, go to Test Settings -› Data and Diagnostics -› select Code Coverage and click on "Configure" at the top. This corresponds to the "keyFile" attribute for the CodeCoverage tag in the .testsettings file.)
In VS 2012, code coverage is enabled by default. It can be disabled through a .runsettings file with an appropriate exclusion. See http://msdn.microsoft.com/en-us/library/jj159530.aspx for more information and a sample file. For option 2, although there doesn't seem to be an explicit setting available in the .runsettings file, the right thing seems to happen automatically with regard to signing (YMMV). However, if you're referencing a VS 2010 .testsettings file then it will need editing as above.
Right-click on Project → Properties → Build tab → Platform Target → Select "x64"
I am working with VS.Net Ultimate 2012
and this solution helped me:
Right click on Project-> properties-> Build Tab-> switch Generate serialization assembly to off-> done
I fixed this by going to the Build menu (top pane) and say "Rebuild xxxProject.plugin" for that specific project only, contrary to building the entire solution.