We Keep Coding

Visual Studio 13 doesn't build all changes

I'm using Visual Studio 2013 Professional, C# settings.
For some reason, when I hit "build", it won't build all the changes I made. Only when I rebuild or clean and build, my changes are compiled correctly (of course).
Even when I just set a breakpoint and build, it says the breakpoint can't be hit.
I know I can just reset F6 to execute a rebuild, but because I have a big solution, this would always take about 10-15 seconds, even for the smallest changes..
I know this is a problem many people have faced, and there are some steps suggested to fix it. These don't work in my case though.
Yes, I've set "On run, when projects are out of date" to "Always build" or "Prompt to build", both didn't work.
Yes, I've checked the build configurations manager that all projects are checked to build.
I have a feeling that it's still something in my settings..
Because a few weeks ago I was still using Visual Studio 2012, and I had the same problem. Now in my company, I got VS13, and because of some specific settings they used my VS12 settings file to maintain them.
Only one other person in our IT-department has that problem, so the general company settings are not the problem. I can't recall changing anything on my own though..
So, did anybody find another way to solve this problem besides the 2 tips I listed above ?

I think you are working in a team and you are not aloud to make these changes.
http://msdn.microsoft.com/en-us/library/hh561430.aspx

I spent ages messing with project and environment settings without sucess. For me I fixed this problem by selecting configuration manager from the debug/release dropdown and ensuring that the build checkbox was ticked.
After this it appears to build as and when needed.
HTH
Paul

Uncheck: Options > Project And Solutions > Build And Run > "Only build startup project and dependencies on run"

Locking files when building in Visual Studio 2010

Hello there, Stackoverflow.
Recently, when I've been programming in Visual Studio 2010, I've been getting the problem with VS locking the bin/Debug/(ProjectName).exe file when trying to build and gives me the error below after trying to build the project 10 times:
Unable to copy file "obj\x86\Debug\TileEngine.exe" to "bin\x86\Debug\TileEngine.exe". The process cannot access the file 'bin\x86\Debug\TileEngine.exe' becuase it is being used by another process.
The problem appears when I edit the source and then try to Debug.
I've checked using different programs, and the only program using the file is Visual Studio.
If I wait for about 10 minutes before trying to build, it seems to work properly, but when trying different things, it isn't good needing to wait 10 minutes before trying something.
I've tried different solutions both on this site as well as everywhere I can find on Google.
Some solutions I've found, but haven't worked for me
Solution 1 - Using a pre-build script
In some different questions here on Stackoverflow, I've found one solution being that you go into Project Properties > Build Events and then in the Pre-build event command line add:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
This made it possible for me to build the project one more time than I usually could, but when editing the code again, and then building, the same error appeared.
Note: Trying to build a release instead of a debug build seems to break the pre-build script and it exits with the code '1', which seems to make VS unable to build properly. Removing the pre-build script makes it work like "normal" again, still with the same error though.
Solution 2 - Running Visual Studio as Administrator
This is another solution I've found, but havent worked either for me, so I assume that Visual Studio already have all the permissions required and running as Administrator doesn't actually make any difference.
Solution 3 - Changing the AssemblyVersion
In this question, Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debug, I found another solution that included changing the AssemblyVersion, in the Properties\AssemblyInfo.cs file, to "2.0.0.0".
This, however, haven't made any difference whatsoever for me.
Solution 4 - Closing UserControl designers before building
According to some different answers here and there on the Internet, Visual Studio apparently uses the built project executable to render the UserControl designer(?). In my case, this is probably not it, though, since I use XNA mostly and it doesn't use the UserControl designer.
Solution 5 - Cleaning up resources when application quits
This might be a solution that I have failed to implement properly. I'm just thinking though, that if this is the solution, how come I haven't been required to do it before. I assume XNA unloads everything that gets loaded through the Content pipeline, therefore this solution wouldn't' make any real sense.
If there is anyone that is able to spread some light on this issue, it would be really awesome, as it is stopping me from programming anything really, because I don't like waiting for 10 minutes because I've made a 2 second change all the time.

I've run into this problem a few times myself.
Mine might not be from the same cause as yours, but I'll tell you what went wrong with me and how I fixed it, hopefully it'll be helpful to you.
Basically, my program never fully exited properly, even when it appeared to. It would continue to run, and thus continue to lock down the file.
A quick dirty fix I used initially (and a way to prove if this is the case) is:
Open Task Manager (Ctrl-Alt-Del)
Click Processes tab
Look for your program's name (TileEngine.exe)
Note: There will probably be name_vshost.exe (TileEngine_vshost.exe) That's a VisualStudio thing, ignore that, it's not relevant.
If you find it, it means your program hasn't actual exited fully.
If it's there, click on it and press "End Process"
So if it's there, then for some reason, your program didn't shut down, like mine did.
Often, this is from a thread being launched and forgotten, or an Async task that never completes, or something like that.
Make sure in your OnExiting(..) void function that you kill all running threads.
If your program is still running despite best attempts to close all threads and other blockers, you can use the very dirty bad method:
In OnExiting(...) run the code "System.Diagnostics.Process.GetCurrentProcess().Kill();" - this will taskmanager-style forceshutdown the current process... this is only as an emergency I-can't-make-it-work-any-other-way method.

I think I found the solution myself.
In the Project Properties, "Enable the Visual Studio hosting process" wasn't checked. Checking it seems to have fixed the problems, at least for now.
Got reminded of it from mcmonkey4eva's post. So thanks for that =)
And thanks for the other replied I've got. Stackoverflow is awesome!

Have you checked if any files are being blocked by your firewall? When I switched to the full version of Avast I find I have to disable the File System Shield It loves to remove my executable files when I try to run my visual studio projects.
I had problems when upgrading to VS2012 Professional. (SDK, .Net, Visual C++ Redistributable package)
ENSURE ALL OF THESE ARE COMPATIBLE WITH THE CURRENT VERSION OF VS YOU ARE USING
What I did, was I ended up uninstalling EVERYTHING that was associated with both Visual Studio downloads. If you are able to remove and save your project files elsewhere and then bring them back. Go through all your program files to see if there is anything hidden in the wrong folder and check your C drive.
Which meant downloading and reinstalling (fresh):
I think if you clean out your program files, it should be ok. I wouldn't recommend going into your register unless you are very sure of what you are doing. IF you have already made changes to the register then we'll have a look at that and other options (if this doesn't solve your problem).

Try removing the readonly check from your solution by unchecking at the folder level.

I ran into this problem and in my case was due to having bin included in the solution; as soon as I excluded the bin folder from my solution the problem went away.

Nothing helped, not prebuild commands, neither designers closing, but I figured out a way that helped me, just changing from debug to release and vice-versa releases locked files and you can delete them without closing the IDE.

I regularly get this problem if I switch from Debug to Release and then immediately F5 to compile. Crazy as it sounds, waiting for, say, one minute after switching between modes will prevent this.
If it's locked, the only solution is to close Visual Studio and re-open.

I solved this problem organizing my resources on solution. I noticed this error when I put some images on my application at the same solution folder.
So,
I'd removed all images and resources from app, save without it.
Moved the images to outside Solution folder.
Open the solution and add this images again, using "Import" button at controls.
If you will try this, remember to do with Application Icon, on Project Settings.
Now, everything is working fine for me.
I hope it helps.

You need to disable Windows Indexer as it locks up the file
Follow this Guide how to disable

In my case the problem seem to be caused by the remote debugger. It starts on local machine when you compile with "x64" option. Try to change the project setting (properties/buid) until you reach the final version.

Change Build Platform target from x86 to Any CPU.

Check In: Operation not performed Could not find file *.csproj.vspscc

I am having issues with check in my code files because of some changes I have made to the project and solution. I have renamed project files, added different project files in the solution and added many files in the existing project.
Now I am getting an error while checking in the code.
The error details are:
Check In: Operation not performed Could not find file
'....Console.csproj.vspscc'.
How do I create a vspscc file if it does not get created on its own?
Any help would be great and thanks in advance.

This looks pretty stupid on my part. I restarted my Visual Studio and I could perform the check in because Visual Studio created the vspscc file when it opened the projects and solution.
Answering my own question as fast as possible so nobody else prints my own negligence before me.
And for anybody who needs an answer as how to create a vspscc file, restart the visual studio IDE

I have also seen this in another situation (VS2012) where a simple restart didn't do the trick.
I had a number of new projects which I had added to an existing solution but in the wrong place. Undoing and re-adding seemed to be fine until check-in, where it complained that the newly added projects and related .vspscc files could not be found. It was looking for them in the original location rather than where they are now.
Resolution was to go to the Source Control Explorer, which still had check-in items against these files in their original (but non-existing) locations, as well as the files in their correct locations. Selecting these errant references and "Undo pending Changes" for these files did resolve the issue.

I'd try using File/SourceControl/ChangeSourceControl dialog and unbind (if necessary) then rebind the project to TFS to recreate the .csproj.vspscc.

I removed projects and have same issue, so my solution was to re-create the same projects with same name, then remove them cleanly :-) I hope this helps

I had a similar problem, but in my case I Visual Studio/TFS couldn't fine the .csproj file. Anyway, with the help of a colleague I was able to determine that the issue was within TFS itself. TFS may have a different view of your source code than Visual Studio does. I had created the wrong type of project (I'll call it Proj1) and deleted it from within VS. Then created the correct project type, which I'll call Proj2. When I when to check it into TFS it complained about Prog1.csproj, which confused me because I couldn't see it within VS. What I learned was that you have to go into TFS's Source Control Explorer. From there you'll see how TFS sees things. Sure enough, there was Proj1.csproj (and some other related files to Proj1). What I had to do within Source Control Explorer was undo the pending check-in's of those files and folders which I didn't want to check in and no longer existed anyway. Then TFS was happy and I could perform the check-in.

SpecFlow: "Step bindings are still being analyzed. Please wait."

I keep getting the same message whenever I right click a scenario and "Generate Step Definitions" or "Go To Step Definition".
It worked the first time I tried, but it hasn't since.
I've filed a bug report, but in the mean time, anyone know how to solve this?

Over five years later and I'm getting the same problem... Here is the solution that worked for me:
Close the solution in Visual Studio.
Go to your temp directory in Windows Explorer (enter %temp% in the location bar).
Delete the 'specflow-blah-blah.cache' file.
Reload the solution in Visual Studio, rebuild the solution and give SpecFlow a bit of time to sort itself out.

ive gotten this issue before, we have about 800 SF tests in one of our projects and when we first load it can sometimes take quite a lot of time for it to load up. For me its always sorted itself out eventually.
Another thing to try would be to upgrade to 1.9 which came out a few days ago, it may have improved performance.

Although I'm using the last (1.9.2) I had the same problem. Re-opening VS2010 solved the issue.

I've found a work around for this problem; close the solution and delete the .SOU file. Re-opening the solution then re-creates this file and the SpecFlow context menu options then work.

I got the the same issue when I moved external assemblies to specflow.json file from app.config
1) Turned out that I got an assembly reference which didn't even have specflow nugets.
2) I renamed one assembly, but for some reasons the old name wasn't replaces in AssemblyInfo.cs file. I changed it manually, cleaned the project. Cleaned the specflow cache (see previous answers how to do this) and it worked.
So, check if all the references and assembly names are correct.
Cheers
P.S. Don't forget to setup "Copy to Output Directory" option for specflow.json :D

If you are still unable to force the steps to bind, but just need to get to the definition of a given step:
Place a breakpoint on the first step of the scenario
Debug test
Step into the function (F11 by default)
There you are! VS navigation may not work but the debugger knows the way:)
I get this may not be a direct solution to the original issue with steps not binding, but I think it gets where the OP wanted to go...

The root cause of this issue is your code has poor performance and that cause the slowness and hangs your Visual Studio or due to low performance of code Visual studio moves in unresponsive state.
The solution is improve the performance of your code. You need to optimize your code in all the possible ways:
Use less inputs in each step
Use less parameters in your parametrized methods
Avoid unnecessary loops
Divide the number parameters into more methods if taking more than 5 parameters. It will improve the performance.
Divide the input values into more sub-step or separate steps, it will improve the performance and speed of the code.
Use switch case instead of if else statements if there are more cases.
Free up the occupied memory if the reference variables or objects are no more of use.
Read data from external sources and store them into objects or lists locally and minimize make it one time read from external source once and access the values copied locally in the lists or any other objects/variables.
Close or quite the external files or call to them after use.
Hope this is the best way to improve the performance of code and this issue will not happen for sure and your steps bindings and definition will be more smooth and easy.

We fixed it like this:
close Visual studio
Deleted the obj and bin folders under the project(s),
open Visual studio again.
rebuild
After that the .feature files "came back to life"

no breakpoints can be set VS2010?

This is happening to me very often. When I am working in Visual Studio 2010 and say I make a code change, then build... Both my existing breakpoints become disabled / and or cannot be set and I also cannot set new breakpoints. Does anyone have a solution for this? It is very annoying. So far the only way I have been able to get around this is to restart Visual Studio which can take 5 to 8 minutes to reindex everything or to try rebuilding individual projects in my solution. My solution consists of several DLLs which make up the entire program.

Check that you have the dependencies set correctly in your projects. I know my breakpoints will become disabled if the code is "out of date". If you don't have the dependencies set up right, then when the updated code is rebuilt it will not rebuild all of the related code which will then leave those modules "out of date".
Since this is VS 2010, the dependencies are on the project not on the solution (you can add solution dependencies, but project dependencies will carry over into a new solution so it is the better way to go when possible).

This issue is caused when you having your Configuration Manager settings set to Release rather than Debug.
In Visual Studios select Build from the menu, then Configuration Manager.
In the next dialog select your project, then locate the drop down menu near the top left corner titled "Active solution configuration:" Make sure it is set to Debug.
That should fix the problem.

As it turns out the post.build file contained numerous conditions for whether or not it should copy several DLLs to a target directory... Since I didn't have time to pick through the xml for these actions I just used a bash script to copy the files after building. No need to get complicated... Otherwise, the formal solution involves setting conditions for allowing the DLLs to be overwritten/copied after compile or not.
I find the Visual Studio post.build file concept a little excessive since in the end it will make little difference whether a dll is overwritten with a freshly compiled version, yet, if you make code changes, compile, and it doesn't copy to the target directory you end up running your app with an out of date DLL and you are not testing with the recent code change..! Others have even implemented the post.build file complete with xml and goto statements...! Leave it to Microsoft to complicate the build & debug process...

Alternatively, if your code is under version control start afresh by checking out the head revision, do another clean and rebuild and start debugging again.
This for whatever reason enabled me to insert breakpoints in my VS 2010 C# project once again, whereas no amount of fannying around with properties, configurations etc got rid of my phantom breakpoint problem.

The best solution I found for this was to quit my Windows job and get another job as a Mac Developer where we use Xcode.! What a huge difference.! I sure haven't seen that breakpoints problem again.!