I have a small application, it launches properly without debugger and all the features work except one which uses IronOcr (package from NuGet package manager). When I try to use this feature the program just closes.
When I launch this application from within visual studio, everything works fine. No errors and all features work. I get the same result if I run it and attach the debugger to it afterwards. However if I run the exe by launching the exe /bin/release and do not attach the debugger it crashes when I try to use the feature involving IronOcr.
I tested this on a virtual machine, same results with/without debugger. I then tested it on a different computer (fresh install of windows only having VS installed) it gave me this error if debugger is attached:
System.IO.FileNotFoundException: 'Could not load file or assembly 'IronOcr, Version=2021.2.1.0, >Culture=neutral, PublicKeyToken=c2cbcea5ea3f6d8d' or one of its dependencies. The system cannot >find the file specified
I've spent the last few days looking up a reason for this but I have not found one so far that fixes the issue.
What is confusing me the most is:
I assume the error that causes the program to close is the same error that causes it to give this error on the different PC. When I run it through VS it has no issues (it finds the file?) but running it from the exe it cannot find the file. I'm not moving the exe, just running it where it is in the bin/release.
I'm hoping this program will be able to run as a standalone exe.
I am still relatively new to c# and VS, the error may be glaringly obvious, or I may be using the wrong words causing me to not find a solution.
probably a bit too late, but your problem certainly comes from the fact you're using the free licence of IronOCR. It seems that this one only works when the debugger is attached.
If you catch the exception, you get that message:
IronSoftware.Licenses.Exceptions.LicensingException: IronOcr must be
licensed for deployment outside of the Visual Studio development
environment. https://ironpdf.com/licensing
In my opinion this is too restrictive for proper evaluation, so I gave up trying to use it.
Make sure IronOcr.dll is exist at same directory as your executable file.
Try to execute your application from Bin/Debug and see if it runs ok or not.
Check to see if IronOcr.dll exist in Bin/Debug but does not exist in Bin/Release. if so then copy it from Bin/Debug to Bin/Release.
I have a visual studio 2010 solution file containing a number of project files. If I clean the solution using devenv then the clean completes successfully, however, if I use MSBuild, two of the project files fail to clean due to a missing dependency, error MSB3395. If I run Clean a second time, immediately after the failure, the clean completes without errors.
Our build using MSBuild succeeds.
Task "UnregisterAssembly" (TaskId:204) ...
...
error MSB3395: Cannot unregister assembly
"C:\Build\Dir\MyFile.dll". Could not load file or
assembly 'MyOtherFile, Version=10.0.0.414,
Culture=neutral, PublicKeyToken=266e457ed35afd03' or one of its
dependencies. The system cannot find the file specified.
[C:\Build\Dir\ProjFolder\MyFileProj.vbproj]
Yes, this assembly is a COM interop assembly and so the build registers the assembly. If I delete the UnmanagedRegistration.cache files associated with the two problem areas then the clean finishes without problems. However, these files are not unregistered and registry fills up with old COM registrations. I am not certain of the impact on future builds either.
I have read the article for VS2008 projects here https://blogs.msdn.microsoft.com/visualstudio/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe/
However, I don't think this applies in this case because this build process has been cleaning and building properly for months.
I have also read: https://www.experts-exchange.com/questions/26259422/msbuild-can't-clean-project-with-C-COM-component-dependant-on-other-NET-library.html. I attempted to clean the two different projects before cleaning the solution affected by this, but this too failed. e.g.,
msbuild ".\ProjDir\MyProj.csproj" /t:clean /p:configuration=Release /fl /flp:logfile=".\..\LogFiles\msbuildClean.log";verbosity=diagnostic
I have tried reverting to a previous SVN revision before the problem began to show but I still get the same error. My build machines are on Virtual Machines, and I even tried reverting the build machine to a snapshot prior to the problem showing up, but still the error would show up.
I have been at this for two weeks now, and my only recourse is to use devenv to clean the solution, which is very slow. My only idea at this time is that when using msbuild that dependencies for COM interfaces are not handled correctly for a clean but I have no idea how to fix the problem.
I can reproduce the problem using the VS2010 CMD Prompt. Below is an example cmd line that I use
msbuild "A Solution.sln" /t:clean /p:Configuration=Release /fl /flp:logfile=".\..\LogFiles\msbuildClean.log";verbosity=diagnostic
msbuild "A Solution.sln" /t:build /p:Configuration=Release /fl /flp:logFile=".\..\LogFiles\msbuildBuild.log";verbosity=diagnostic
Within the vbproj files there are PropertyGroups with a Release configuration condition. All of these include <RegisterForComInterop>true</RegisterForComInterop>. If I set this value to false, then the error goes away because there isn't anything to unregister. However, I need the .tlb files in order to compile our vb6 project.
So, are there any problems for me to just set this to false and then use Regasm to register the assemblies post build, and unregister before a clean? Does anyone have any ideas why MSBuild would suddenly have problems with this process when for months the build has run successfully?
Thanks.
UPDATE
If I use msbuild to clean the first problem project, this clean works
successfully.
The second project however fails to clean properly
When cleaning the first project, ProjA, it also removes dependent
files from other projects, ProjB.
When I clean the second problem project, ProjC, it also has dependencies on ProjB.dll, and this file is missing.
QUESTION
- How do I keep MSBuild from removing files required by other projects?
In the end I have to go with stijn's answer.
I never did find the cause - something in the msbuild clean process seems to delete the files required to unregister an assembly.
I had tried to create a msbuild task to unregister the assemblies first, but that too failed.
In the end I coded a Powershell script that searched a path for *.unmanagedregistration.cache files. I then can determine the .dll file name from the unmanagedregistration.cache file and then once the code runs regasm /unregister, it will remove the file.
Just perform the clean as administrator. If using visual studio, open it as administrator and it should perform the clean action.
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 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