I have developed an C#, ASP.NET web application in a Windows 7 machine using Visual Studio 2012. Now i had imported the entire project into VS 2017 running on windows 10 machine, and when i try to enter the debugging mode to analyze my code it shows the following error:
I guess the project configurations are conflicting hence it throws this error.
Any suggestions??
The same error happens when Visual Studio solution has selected the wrong Startup Project. The bold project is the designated startup project.
Go to the Solution Explorer > Right click on the correct project and select "Set as StartUp Project" in the context menu.
I also got this error. I ultimately got to know that I was not selecting .sln file.
In VS, you should select .sln file and it automatically loads the complete project structrue is what I learnt.
Selecting .sln file worked for me
These errors are mostly because you are not selecting the .sln or solution file. In your solution explorer tree, double click the solution file and then build and run.
This runs contrary to a users intuition that simply opening a file and running it would work. Consider it a poor user interface. Jet Brains Rider, for instance, does not have this issue.
Change Targeting Platforms with the Configuration Manager and Build the project then try to debug it.I hope this will help you.
Don't export the project folder. upload the .sln file.
It will work.
DLLs cannot be ran/debugged directly. You have to specify host application in the
Configuration Properties>Debugging>Command and then let it load the DLL by itself.
You will most likely need to copy the DLL to the directory searchable by the host application e.g. its root or ./plugins folder.
In the Configuration Properties>Build Events>Post-Build Event>Command Line simply enter something like:
copy "$(TargetPath)" "$(HOST_APP)\plugins"
The Startup Item needs to be a .exe file. It's looking at BusinessLayer.dll because BusinessLayer is currently the Startup Project.
First, build the solution. Then, set the Solution Explorer to folder view and find the .exe in one of you project's /bin folders. Right click on it and set it to the Startup Item.
Finally, click the play button in Visual Studio top bar.
EDIT: Basically the same as Thomas' answer, but I'm pointing out that the "correct project" is the one with the .exe file. I would have commented on his answer, but I have less than 50 rep right now.
I have a .NET solution with several different projects. Each of them I have now set up via the AWS Toolkit so I can just right click and hit "Redeploy to AWS..." but what I would like to do create a script (PowerShell maybe?) that builds and deploys all of my projects automatically.
I know there is a CLI version of the AWS Toolkit called awsdeploy.exe but it doesn't seem like that will perform the compilation and archiving of a project like the AWS Toolkit plugin does.
How do I mimic this behavior?
So I'm currently tackling this question at work, with partial success. What I have found is that you can do the packaging with msbuild, and then deploy with awsdeploy.
For example, if I have a visual studio solution call bas, with two projects, foo and bar, and I want to deploy bar, then I first package bar with msbuild.
msbuild bar/bar.csproj /t:Package /p:PackageLocation=barPackage.zip
This should create a package call barPackage.zip under the bar directory. If you don't find it, look at the msbuild output as it should let you know where it was created.
Now that we have the package, we can deploy. Awsdeploy needs a configuration file. It's just a file that contains key value pairs of the form "key = value". There is an example file in a directory called Samples\, in the same directory where the awsdeploy.exe is located.
If you are using visual studio there is an option for creating the config file while deploying to aws.
More info: http://docs.aws.amazon.com/AWSToolkitVS/latest/UserGuide/tkv-deployment-tool.html#deployment-tool-configuration-file-format
Let's assume we have a configuration file called deployConfig.txt then we can call awsdeploy like so
awsdeploy /r deployConfig.txt
Note that the /r is for redeploy. This assumes that you already have an environment running.
If you don't want to put credential inside the file, you can also do.
awsdeploy /r /DAWSAccessKey=stuff /DAWSSecretKey=stuff deployCon
In general anything we don't want on the file we can specify on the command like by adding /Dsomething=stuff. As you can see above to specify AWSSecretKey we do /DAWSSecretKey=stuff.
The visual studio generated file does not list the location of the package so what I've been doing is
awsdeploy /r /DAWSAccessKey=stuff /DAWSSecretKey=stuff /DDeploymentPackage=bar/bar.zip deployConfig.txt
This almost works for me. But sadly it doesn't quite do the trick. It deploys the package, and I can see the environment trying to load it but fails at some point. I don't know why it's failing to load it. It loads it fine when I deploy it from visual studio.
This is how we're handling it. All of this runs on our CI server:
Step 1 - build web deploy package with msbuild:
msbuild website.csproj /t:WebPublish /p:WebPublishMethod=Package
/p:DesktopBuildPackageLocation=website.zip /p:Configuration=Release
/p:DeployIisAppPath="Default Web Site"
Step 2 - deploy with awsdeploy:
awsdeploy.exe /DAWSAccessKey=**** /DAWSSecretKey=**** /r config.txt
config.txt:
DeploymentPackage = .\website.zip
AWSProfileName = ******
Region = us-east-1
Template = ElasticBeanstalk
UploadBucket = ***********
Application.Name = ***********
Environment.Name = ***********
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 used the editbin /LARGEADDRESSAWARE command to change my .NET C# exe so that it can address memory > 2 GB. This works fine and I can run the dumpbin command to verify that it's been modified successfully.
I then proceed to create a .msi package that includes this exe. When I run this .msi on a windows 7 target machine it successfully installs the exe. But now if I run dumpbin on the same exe that got installed on the target machine is shows that it is no longer supporting memory > 2 GB.
What is causing this? Is is the process of building .msi or the running of .msi on the target machine?
Whatever is going wrong here, it surely has something to do with you doing this by hand. Let the build system do this for you. Project + Properties, Build Events tab. Paste this into the "Post-build event command line" box:
set pathsave=%path%
set path=$(devenvdir);$(devenvdir)..\..\vc\bin
editbin.exe /nologo /largeaddressaware "$(targetfilename)"
set path=%pathsave%
There are several issues with editbin to set the LARGEADDRESSAWARE flag in an msbuild post build step.
EditBin x32 does not run outside of VS command prompt because mspdb100.dll is not found. Why should you care? Well if you run a TFS build workflow msbuild is NOT called from a VS command prompt. This will cause issues ...
You can fix this one by using the one in bin\amd64\editbin.exe but then you can build your exe only on a x64 build machine.
If you patch the final file at $(TargetPath) then it will work but if you rebuild your project and you have set Inputs and Outputs for your task then it will not run again.
This is an issue because during a rebuild the exe from the intermediate folder is copied again to the final location which was not patched.
This is still not it. Because if you did strong name your exe you need to re-sign it to make the strong name valid again. It will run on you dev machine because most of the time dev machines have disabled strong name verification but it will fail to run on customer machines.
Finally your task will look like this:
<Target Name="AfterBuild" BeforeTargets="CopyFilesToOutputDirectory" Inputs="$(IntermediateOutputPath)$(TargetFileName)" Outputs="$(IntermediateOutputPath)largaddessaware.tmp">
<Exec Command="xxxxxbin\amd64\EditBin.exe /LARGEADDRESSAWARE "$(IntermediateOutputPath)$(TargetFileName)""/>
<Exec Command="sn -Ra "$(IntermediateOutputPath)$(TargetFileName)" "$(AssemblyOriginatorKeyFile)""/>
<Touch AlwaysCreate="true" Files="$(IntermediateOutputPath)largaddessaware.tmp"/>
</Target>
We need to patch the executable before CopyFiletoOutputDirectory has run otherwise we will patch the intermediate file after the unpatched file has already been copied to the ouptut folder. The final file cannot be patched because this target will not run when the exe has not changed to prevent breaking the incremental build.
This is a classic example of a simple task (set one bit in the PE header) which is quite difficult to get right. It is (nearly) never as easy as it might look like at the beginning.
I thinks in the end I found that the Installer was picking my exe from a different path than the one I was using to update using editbin post build command. I added this line in my post build command of my exe
copy "$(targetpath)" "$(ProjectDir)\obj\x86\release"
So the entire post build command looks like this
set pathsave=%path%
set path=$(devenvdir);$(devenvdir)..\..\vc\bin
editbin.exe /nologo /largeaddressaware "$(targetpath)"
copy "$(targetpath)" "$(ProjectDir)\obj\x86\release"
set path=%pathsave%
Thanks