Develop Reference

Checkout A Project With Git And Visual Studio

I recently started using Git with Visual Studio 2015 and I'm trying to modify the properties of an installer project. The issue is that it won't let me because the project isn't checked out and I don't see an option to check out the project with Git through Visual Studio. The only place I even see the mention of the words 'Check Out' is under branches and it's grayed out.

I'm having the same problem in VS2015. It seems to be an issue with the Installer Project extension. For some reason Visual Studio doesn't detect when you attempt to change the Setup Project file (with YourProject.vdproj), and doesn't automatically unlock it for you. I had the same problem with TFS, but in that case all you had to do is manually unlock the file, by right clicking on it. I've just migrated to Git, and the problem is still there, but now you can't unlock the file by right-clicking on it (since there is no explicit check-out in git).
I'm still looking into the problem, but the only solution I've come up with now, is making a quick manual edit of YourProject.vdproj in Notepad. Visual Studio WILL recognize that edit, and unlock the file for you. After that you can continue to use IDE to make changes to the Installer project.
Unfortunately, the problem comes back once you check in your changes, and try to modify the file again. You will once more have to manually edit it to force Visual Studio to unlock it for you.
EDIT: After spending a few hours on this, I finally came up with a proper fix, which I verified works on a few in-house projects. Here are the steps:
Open your solution file in notepad, and delete the following section: GlobalSection(TeamFoundationVersionControl)
Open the solution containing locked Setup Project in Visual Studio.
Go to Tools > Options > Source Control > Plug-in Selection, and pick 'None' from the dropdown.
Click Yes to the dialog that warns you the project will be closed.
Open the solution again, you will be prompted to permanently remove
source control bindings from the projects. Click Yes to that.
You can now go back to Tools > Options > Source Control > Plug-in
Selection and pick Git again.
At this point the problem is fixed, and you will be able to modify
your Setup Project without any issues.
I found that removing bindings is clearing the values of the following tags from the project files:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
Apparently SAK stands for 'Should Already Know'.

Here is a workaround I found,
Mark the project installer in the Solution explorer, And click "Save" (not save all).
For me it did the trick.
If it's still didn't help try to reopen VS and try the method again.
Cheers!

Open a command line, go to where you need to check it out, then issue the git checkout command? http://git-scm.com/docs/git-checkout

Like Eternal21 I encountered this problem when trying to modify an Installer project, this was in a VS2013 (rather than VS2015) project though and I could not see a GlobalSection(TeamFoundationVersionControl) in the solution file. However the following steps worked;
Go to Tools > Options > Source Control > Plug-in Selection, and pick 'None' from the dropdown.
Make the change required to the Installer project
Go back to Tools > Options > Source Control > Plug-in Selection and select Git again.
(and the Solution did not ask to be closed).

You need to create a new empty repo on your Git server first, then clone it to a folder on your local computer.
After that you will be able to add your project and check it in by adding it to the local folder.

I was able to work around this problem by simply editing the vdproj file (setup project file) manually in Notepad++ (you can use any text editor), making some temporary changes into it (type a character and backspace) and saving the file. This effectively checks out the project from GIT. Now you can come back to Visual Studio and make whatever changes you want.

I was able to use dotNETs suggestions and edit the vdproj file. Simply adding a character and removing didn't work, but making an actual edit did. Doing so triggered the check out for GIT. In my case I was attempting to change one of the Detected Dependencies exclude property to false and was able to do so while editing the vdproj file. Once I saved it then reopened Visual Studio the check was displayed on my installer and the change was already applied. I was able to make additional changes while checked out.
Once finished and I checked it in, I could no longer edit and needed to manually edit the file again to check out.

Visual Studio 2013 is running old code

I have searched and found other topics on this, but none of the solutions seem to work for me. Visual Studio is running old code in debug mode and release mode. If I go to the actual directory and launch the exe, it is the latest code. It is a XAML project.
Things I have tried:
1) Deleted bin and obj folders
2) Rebuilt solution
3) Cleaned solution
4) Made sure the project is set to build in Configuration Manager
Update: I tried adding a new configuration in Configuration Manager. The path is totally different, and it still running the old code. The exe built with the new config is the right code when I launch it manually, but it seems like visual studio is running a cached version of the exe.

Another gotcha I see a lot - be careful with shortcuts. If you are opening the solution via Recent Projects or another shortcut, try opening it via File -> Open or clicking on the solution file itself instead. I see a lot of developers looking at old code or the wrong branch because of this.
Can also try changing the assembly version number. Every once in awhile that will somehow make a difference.

I am not sure what exactly helped, but one thing is certain:
i marked .js file properties "Build action" as "Compile".
Tryed to deploy (got an error of course), and changed it back to "Content".
Rebuild, deploy, run debugger and FINALY it works on my current code.
The Error is back on my "new old" code
What i do is:
click "Continue", go to opened IE window with my page\site, press CTRL + F5,
and what i see?
My new current code inside VS debugger...
Error is gone

Visual Studio. Code changes don't do anything

Any changes I make to my code aren't doing anything. I've even tried putting lines in that I know will crash my program, and nothing. It just keep running the old version. It's even loading old versions of files I've edited and saved.
There a 3 projects in my solution. 2 are pure C#. 1 is a WinForms application.

It sometimes happens that some files "are being used by another process".
Close your solution and delete all "bin" and "obj" subfolders of all your projects that are included in the solution.
Then open your solution again, execute "Clean solution" and build it again.

Check this setting in Tools/Options, then under Projects and Solutions>Build and Run.
On Run, when build or deployment errors occur:
My personal preference is for this value to be 'Do not launch'. It will prevent Visual Studio from launching the "last successful build".

Try Ctrl+Shift+B. This will build your solution (not just a particular project). Other environments might build when you save but this needs to be explicit in Visual Studio.

Had issue with saving code changes on VS2017 (mac) Version 7.3 Preview (7.3 build 740)
Only way to get file changes to save was to do File > Save All
Doing File>Save would act like the file saved. But, when I opened the file again and no changes were saved.

Ok, you need to add more detail, but you may want to have a look at this answer:
How to enable/disable compile errors warning in Visual Studio

delete Published DLL From Bin
file names -
projectName.ddl
projectName.pdb
delete these two files and run project

I had the same problem (Visual studio 2015 is not noticing my modifications in C# XAML files).
Problem solved by deleting 2 'debug' subfolders. One in the bin folder and one in the obj folder.

I met the same problem. the code changes is not saved.(you can see from the edit it is in Yellow color. e.g. indicating changes). SAVE and BUILD will not let it save the changes. i have to wait sometime, then it could possibly save success..

Deleting the whole project and the corresponding folder from local and check out the solution again. This worked for me=> VS2017

I solved the problem like this:
1. I closed the program
2. I opened the folder that contains the file (.csproj) and opened it with Visual Studio.
Next, I chose the folder to run the command as in the image

Had the same problem. Turns out I had moved a project folder. Even when opening the solution from the moved folder and editing and saving this source code, VS 2019 was building and running a different instance of the program with the same name. Go to File-> Save yourproject.cs as..and manually walk back through the directory structure to find the instance VS is actually running. Hope this helps.

also check another option in Tools>Build and Run>Only build startup project & dependencies if you have more than 1 nested dependency, especially when using Prism or any other reflection-based frameworks that prevent "dependency detection". Also, make sure you're in the editor when using shortcuts like Ctrl+S (Save) or Ctrl+Shift+S (Save all)

Go to this location:
C:\Users\<your_system>\AppData\Local\Microsoft\VisualStudio\<studio_version>
Then remove all files and start Visual Studio.

this was the error , no changes made after build.

the source file is different from when the module was built

This is driving me crazy.
I have a rather large project that I am trying to modify. I noticed earlier that when I typed DbCommand, visual studio did not do any syntax highlighting on it, and I am using using System.Data.Common.
Even though nothing was highlighted, the project seemed to be running fine in my browser. So I decided to run the debugger to see if things were really working as they should be.
Every time the class that didn't do the highlighting is called I get the "the source file is different from when the module was built" message.
I cleaned the solution and rebuilt it several times, deleted tmp files, followed all the directions here Getting "The source file is different from when the module was built.", restarted the web server and still it tells me the source files are different when they clearly are not.
I cannot test any of the code I have written today because of this.
How can the source be different than the binary when I just complied
it?
Is there any way to knock some sense into visual studio, or am
I just missing something?

I got this issue running a console app where the source that was different was the source that had the entry-point (static void Main). Deleting the bin and obj directories and doing a full rebuild seemed to correct this, but every time I made a code change, it would go out-of-date again.
The reason I found for this was:
I had checked "Only build startup projects and dependencies on Run" (Tools -> Options -> Projects and Solutions -> Build and Run)
In Configuration Manager, my start-up project didn't have "Build" checked
(For #2 -> accessible via the toolbar under the 'Debug/Release' drop down list.)

I was just having this same problem, my projects were all in the same solution so they were using Project to Project references, so as one changed the others should have been updated. However it was not the case, I tried to build, rebuild, close VS2010, pulled a new copy from our source control. None of this worked, what I finally ended up trying was right clicking on the project and rebuilding each project individually. That updated the .dlls and .pdb files so I could debug through.
The issue here is that your dll and or your pdb files are not in sync.

Follow these steps
Just delete the bin directory from the project where the DLL is generated.
Re-build the project.
Remove reference from the project that make reference to the DLL.
Include again the reference.
Enjoy.

In addition to these answers I had the same issue while replacing new DLLs with old ones because of the wrong path. If you are still getting this error you may not refer the wrong path for the DLLs. Go to IIS manager and click the website which uses your DLLs. On the right window click Advanced Settings and go to path of the Physical Path folder on File Explorer and be sure that you are using this folder to replace your DLLs.

Some things for you to check:
Have you double checked your project references?
Do you have a Visual Studio started web server still running? Check the system tray and look for a page with a cog icon (you may have more than one):
(source: msdn.com)
Right click and close/exit it. You may have more than one. Can you debug your changes now?
Are you running the debug version but have only built the release version (or vice versa)?
Did the compile actually succeed? I know I've clicked through the "there were errors, do you want to continue anyway?" message a couple of times without realising.

With web services, the problem can be caused by using the Visual Studio "View in Browser" command. This places the service's DLL and PDB files in the bin and obj folders. When stepping into the web service from a client, somehow Visual Studio uses the PDB in the bin (or obj) folder, but it uses the DLL in the project's output build folder. There are a couple workarounds:
Try deleting the DLL and PDB files in the web service bin and obj files.
Try clicking "View in Browser" in Visual Studio.
If you previously got the source file mismatch error, Visual Studio might have added the filename to a black list. Check your solution properties. Choose "Common Properties -> Debug Source Files" on the left side of the dialog box. If your web service source files appear in the field "Do not look for these source files", delete them.

Unload the project that has the file that is causing the error.
Reload the project.
Fixed

I just had this issue.
I tried all the above, but only this worked:
delete the .pdb file for the solution.
delete the offending .obj files (for the file being reported out of sync)
build the solution.
This fixed the issue for all builds moving forward for me.

In Visual Studio 2017 deleting the hidden .vs folder in the resolved this issue for me.

This is how I fixed the problem in Visual Studio 2010:
1) Change the 'Solutions Configurations' option from "Debug" to "Release"
2) Start debugging
3) Stop debugging and switch the 'Solutions Configurations' option back to "Debug"
This worked for me. Step 3 is optional - it was working fine when I changed it to "Release" but I wanted to change it back.

My solution:
I had included an existing project from a different solution in a new solution file.
I did not notice that when the existing project was rebuilt, it was putting the final output into the NEW solution's output directory. I had a linker path defined to look into the OLD solution's output directory.
Switching my project to search in the new solution's output directory fixed this issue for me.

I had this problem, and it turns out I was running my console application as a windows application. Switching the output type back to console fixed the issue.

I had the same problem. To fix it I used the "Release Mode" to debug in VS2013. Which is sufficient for me, because I'm working in a node js\c++ addon.

My problem was that I had two projects in my solution. The second one was a test project used to call the first one. I had picked the path to the references from the bin folder's release folder.
So whenever I made a change to the first project's code and rebuilt it, it would update the dlls in the debug folder but the calling project was pointing to the release folder, giving me the error, "the source file is different from when the module was built."
Once I deleted the reference to the main project's dll in the release folder and set it to the dll in the debug folder, the issue went away.

In my case, the #Eliott's answer doesn't work.
To solve this problem I had Exclude/Include From Project my deficient file, andalso Clean and Rebuild the solution.
After these actions, my file with my last modifications and the debugger are restored.
I hope this help.

solution:-
the problem is:-
if your some projects in a solution , refer to some other projects,
then sometimes the dll of some projects, will not update automatically, whenever you build the solution,
some projects will have previous build dlls, not latest dlls
you have to go manually and copy the dll of latest build project into referenced project

I was using Visual Studio 2013 and I had an existing project under source control.
I had downloaded a fresh copy from source control to a new directory.
After making changes to the fresh copy, when building I received the error in question.
My solution:
1) Open Documents\IISExpress\config\applicationhost.config
2) Update virtualDirectory node with directory to the fresh copy and save.

My problem was that I had a webservice in the project and I changed the build path.
Restoring the default build path solved my issue.

I had this same problem and I followed the majority of the guidance in the other answers posted here, nothing seemed to work for me.
I eventually opened IIS and recycled the application pool for my web application. I have IIS version 8.5.9600, I right-clicked my web application, then: Deploy > Recycle > Recycle application pool > OK.
That seems to have fixed it, breakpoints now being hit as expected. I think that doing this along with deleting the bin and obj folders helped my situation.
Good luck!

I know this is an old question but I just had the same problem and wanted to post here in case it helps someone else. I got a new computer and the IT dept merged my old computer with the new one. When I set up TFS, I mapped a different local path than what I was previously using, to an additional internal drive. The old path still existed from the merged data on my hard drive so I could still build and run. My IIS paths were also pointing to the old directory. Once I updated IIS to the correct path, I was able to debug just fine. I also deleted the old directory for good measure.

I also experienced that. I just open the obj folder on the project and then open the debug folder delete the .pdb file and that's all.

This error also happens if you try to make changes to a source file that is not part of the project.
I was debugging a method from a .dll of another one of my projects, where Visual Studio had quite helpfully loaded the source because the .dll had been built on the same machine and it knew the path to the source. Obviously, changing such a file isn't going to do anything unless you rebuild the referenced project.

Delete all breakpoints.
Rebuild.
Done

At Visual Studio 2015, using C++, what fixed for me the the source file is different from when the module was built problem was
restart Visual Studio.

Check if the location you pointed to using mex() in Matlab is correct (contains lib and obj files which are modified to the last date you compiled the library in Visual studio).
If this is not the case:
Make sure you are compiling Visual studio in a mode that saves .lib files :
properties -> Config properties -> General -> Config type -> static library
properties -> Config properties -> General -> Target extension=.lib (instead of exe)
Make sure the output and intermediate directories match the Matlab directory in
properties -> Config properties -> General -> Output directory
properties -> Config properties -> General -> Intermediate directory

I get this issue when debugging sometimes w/ Visual Studio but when the application is served by IIS. (we have to develop in this form for some complicated reasons that have to do with how the original developer setup this project.)
When I change the file and rebuild, that fixes it a lot of the time. I know that sounds silly, but I was just trying to debug some code to see why it's doing something weird when I haven't changed it in a while, and I tried a dozen things from this page, but it was fixed just by changing the file..

In my case, the problem was that the debugger exe path was pointing to a net5.0 bin folder. I am using net6.0, so I should've updated the exe path back when I updated the target framework. Works fine now.

Debug-> start without debugging.
This option worked for me. Hope this helps!

Unable to copy a file from obj\Debug to bin\Debug

I have a project in C# and I get this error every time I try to compile the project:
(Unable to copy file "obj\Debug\Project1.exe" to "bin\Debug\Project1.exe". The process cannot access the file 'bin\Debug\Project1.exe' because it is being used by another process.)
So I have to close the process from the task manager. My project is only one form and there is no multi-threading.
What is the solution (without restarting VS or killing the process)?

This should work.
Go to your project properties.
Inside Build Events, under Pre-build event command line, add these two lines of code:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

#Udpate: Since the time I was first posting this 'answer', I tend to another explanation to the problem. The issue since than happened more and more often outside of Visual Studio also - while trying to copy an .exe file from one folder to another. While in the first place Windows did not allow to copy(!) an .exe file (it was first asking me for administrative rights but refused to copy it afterwards anyway) it still showed up in the explorer. But after a while - without any further action taken, it disappeared magically. Just like the problem in the question always seems to solve itself after a while. So i assume, the problem is more related to a delayed deletion of the project output file and less a buggy VS. I apologize for any unjustified suspicion. :|
This gives the search for a solution a complete different direction, I guess. Did find that link and will update on any progress:
https://superuser.com/questions/234569/windows-7-delayed-file-delete
========================================================================
This is a known bug in VS. I discovered it very often - mostly in VS2010 (with/without SP1). Several "solutions" are recommended. Some of them, which kind of helped for me:
Delete the .suo file in your project dir. Eventually need to create your whole solution from scratch.
Close any Windows Form Designers may remain open.
Use a prebuild script, which deletes the target from the output dir.
Disable the VS hosting process.
None of these really fixes the bug. But it may brings the VS back to a usable state - until a true solution is provided by MS (if ever will).
http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/cea5e4b2-5b33-453c-bffb-8da9f1a1fa4a
http://social.msdn.microsoft.com/Forums/en/vbide/thread/cd12f3c7-de96-4353-adce-23975e30933f

I can confirm this bug exists in VS 2012 Update 2 also.
My work-around is to:
Clean Solution (and do nothing else)
Close all open documents/files in the solution
Exit VS 2012
Run VS 2012
Build Solution
I don't know if this is relevant or not, but my project uses "Linked" in class files from other projects - it's a Silverlight 5 project and the only way to share a class that is .NET and SL compatible is to link the files.
Something to consider ... look for linked files across projects in a single solution.

This is happening because [yourProjectName].exe process is not closing after finishing debugging.
There are two solutions to this problem.
Every time you make change to application, Go to Task Manager -> Processes -> [yourProjectName].exe, end this process. You have to end this process every time you make changes to system.
Add a exit button in your application to exit window and add these line to click event
System.Diagnostics.Process.GetCurrentProcess().Kill();
Application.Exit();

If you look in the obj directory, and you don't see your .exe, it's possible that Avast! or other antivirus is deleting it. I would actually see the .exe show up and then disappear. As soon as I turned off Avast!, problem solved.
VS2010 throwing "Could not copy the file "obj\x86\Debug\[file].exe" because it was not found."

The real problem isn't the error you're getting; it's that the application isn't cleaning up after itself.
It's either holding on to references, not freeing resources, or something else that's causing the process to not end when it's being told to close. Fix up that issue and this problem will resolve itself. We can't really help you with that unless you post your code (and at this point, if you need help with that, you should start a new question).

I had to go into windows explorer and delete the bin/debug folder as well as the obj/debug folders. Then I cleaned & rebuilt the project.

Close your project
Delete bin folder
i find it work, :)

Rename the assembly to a different name to solve this issue.

After seeing a similar error in visual studios 2012 out of no where. I have found that that going to the root folder of the project and right clicking on it I unchecked read only and this error went away. Apparently TFS sometimes will made a folder read only. Hopefully this will help anyone with a similar issue. Thanks

This happened to me at VS 2010 and Win 7..
Case :
I can not Rebuild with Debug Configuration manager, but I can rebuild with Release Configuration manager
What I have tried:
Check my account type at control panel - user account --> My Account is Administrator
Set the bin folder not read only
Add security at bin folder to Everyone
stop the iis server
Stop antivirus, check ridiculous running program using task manager and ProcessExplorer
run VS as administrator
If All that way is still not working.
Then, the last way to try:
close solution
close visual studio
start - shutdown
press power button to turn on the computer
login to your account which has administrator previlege at user type
reopen solution
rebuild
that way working. All people call this way as Reset Computer

Mine got solved by:
Clean solution
Close all processes depending on VS (Current instances).
Rebuild

I had same problem, after read your answers , went to Task Manager and searched for app.exe because i believe maybe it doesn't close .
And found it , select it and do END TASK .my problem solved.

Before rebuild the solution, clear the project, stop the IIS and open the "bin" folder property. Uncheck the Read-only Attribute in general tab then rebuild.

I found that ending all msbuild.exe tasks (in Task Manager) fixed the issue with VS2012.

I struggeled with this since years.
I finally downloaded LockHunter to find out who locked the file.
In my case it was MBAM.
Once I added my project's directory to MBAMs exclusion list, I didn't have this problem anymore.

I too had the same issue. I resolved it
Closed my VS, then in Task Manager, End tasks like Microsoft VisualStudio WCF Tools, MSBuild.exe
Then open VS and clean and rebuild.

No matter what the cause of this problem is, the only working solution for me is the following:
Go to Your-Project-Properties -> Application tab(first tab) -> Change the Assembly name.
This way your app creates a new assembly file each time you change the assembly name.
Finally, after you finish to develop, you can delete all those extra assembly files and just keep the last one (main one). Non of the other solutions worked for me, except this one.

Run Visual Studio as Administrator

We recently experienced this on a WinPhone 8 project, in VS 2012 Update 2.
Inexplicably, the cause was using the Tuple type. Removing the code that used a Tuple the problem went away. Add the code back the problem returned.

This will Sound crazy, when ever i build the project the error will be displayed and the avast antivirus will show it as malicious attempt and the project does not run.i just simply disable my antivirus and build my solution again the missing .EXE file has been Created and the project has been successfully executed.
Or you can try this
Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debug

I solved this by killing XDesProc which had a handle on the DLL it couldn't delete.

Well i have the same problem, my way to fix it was to stop and disable the "application experience" service in Windows.

Not a direct answer to your question..
One scenario when this can come is listed below -
If your application is under Debugging process - say by "Attach to Process" debugging, this error may come

If this error was encountered, you can proceed as the following
End the msbuild.exe task
End the explorer.exe task
Run the explorer.exe task again

for me it was the antivirus. Just add visual studio project or entire parent folder to Antivirus exclusion list or you can also add file extension as exclusion and this method worked for me in visual studio 2010/2012

Solution1:
Close the project.
Delete the bin folder.
Open the project.
Build the project.
Solution2:
Add the following code in pre-build event:
attrib -r $(OutDir)*..\* /s
This command line code will remove the ready-only attribute of "bin" folder. Now visual studio can easily delete and copy new dlls.

A very simple solution is to open the Task Manager (CTRL + ALT + DELETE), go to Processes tab and search by name the processes with your project name that are still running. Kill all the processes and go on ! :)

after day with search and build and rebuild i found that you just need to turn off turn on the visual studio its look like it catch the service in different thread

My Visual studio 2019 suddenly stops and restarts and then when i run project this error comes.
I resolve this issue by going into my project folder and delete bin and obj folder
Then clean and rebuild my project. This resolve my issue.