Related
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.
I am using Visual Studio 2012 and it was working all fine until I started observing some funny behavior. When I open my code it shows red Underlines which we usually see when there is an error in our code. Surprisingly, the code compiles all fine. I have made following observations that are not normal at all.
Red underlines in the code
While cleaning or building the solution no error.
Red underlines go away for some time after I build/clean the solution, but they come back eventually.
Because of this, my IntelliSense stopped working.
I can not right click on any component and go to its definition.
Any ideas?
Visual Studio 2017, Visual Studio 2019, Visual Studio 2022:
Closing Visual Studio and removing the .vs folder located in the solution directory worked for my C# projects.
This folder has a hidden attribute. You may need to change View settings to show hidden files in File Explorer.
Delete the contents of the temporary ASP.NET folder and then rebuild. It'll either be in your user folder (for IIS Express - \AppData\Local\Temp\Temporary ASP.NET Files) or the Windows directory (for IIS - C:\Windows\Microsoft.Net\Framework\vx.xx\Temporary ASP.NET Files)
Paths are off the top of my head and may not be correct
For me, this issue got fixed when I unloaded and reloaded the project again.
I had this issue and it was related to ReSharper.
Solution steps for me:
Disable ReSharper
VisualStudio\Tools\Options\ReSharper Ultimate\General\Suspend Now
Build Solution
(Ctrl + Shift + B)
Re-enable ReSharper
VisualStudio\Tools\Options\ReSharper Ultimate\General\Resume Now
Just had this problem while working with a solution created in Visual Studio 2012 but running in 2013. I closed Visual Studio, deleted all \bin and \obj directories and the problem was gone.
I had this problem after resolving some conflicts from Subversion (SVN). The solution has several projects in it and I resolved some conflicts in a few different projects. I did a menu Build → Clean Solution followed by a men Build → Rebuild Solution and everything was good again.
Do you have any plugins installed, like ReSharper? I had an issues with a bad plugin.
Try running Visual Studio in safe mode, to prevent plugins from running.
devenv /Safemode
If you are using ReSharper like me, you may delete ReSharper cache following by this link: Configure Caches
To specify the location for caches:
Open the Environment → General page of ReSharper options.
Use the Save solution caches in to select the location for cache files:
User local settings folder to store them in the following directory: %LOCALAPPDATA%\JetBrains\Transient
4.System TEMP folder to store them in the following directory: %TEMP%\ReSharperCache
Solution folder to store them in the root folder of the current solution
Custom folder to choose a custom location for ReSharper cache files.
Click Save to apply the modifications and let ReSharper choose where to save them, or save the modifications to a specific settings layer using the Save To drop-down list. For more information, see managing and sharing ReSharper settings.
Reopen your solution for the changes to take effect.
What works for me is deleting the IntelliSense indexfile.
The IntelliSense-file is in the same directory as you solution.
It's filename is SolutionName.sdf
Just delete this file, open you solution again, and IntelliSense will start rebuilding its indexfile. After that the problem will be gone.
In Visual Studio 2013 I solved this problem by deleting all of my obj and bin folders across all projects. The issue was probably due to solution configurations that I had deleted, but I hadn't been cleaned up properly, as doing a menu Build → Clean Solution doesn't remove the old outputs from the obj and bin folders.
This worked for me in Visual Studio Enterprise 2017:
Navigate to Tools > Options > Text Editor > JavaSCript/TypeScript > Linting > General
deselect "Enable ESLint"
I've run into this as well and was able to return Visual Studio to its normal state by doing the following -
Identify the project where the red lined code comes from
Remove the "red line" project from the references where it is being used (ProjectName\References - right click, add references, and uncheck the "red line" project)
Build (you should get errors now)
Readd the project reference that was just removed
Build again
The red lines should be removed and the project should build!
Steps that work
Open the solution and do a rebuild all
Close the solution
Open solution and do a clean
Close solution
Open solution and do a rebuild all
Close and then open the solution. It should be good. This works for me every time
Be careful deleting some of these settings files as you will lose saved debug settings, etc. And it may do more damage than you realize.
I have found recently it is easy to solve this by switching from Debug to Release in the dropdown to left of the Play Button. Then switching back from Release to Debug.
I had the same problem with lots of red lines in several *cpp source files. Though the code compiled perfectly. None of the other solutions worked for me.
Changing the order of #include lines of a *.cpp-file could make the red lines disappear - and reappear with the restored order.
Then I noticed a header file was included twice in a single *.cpp file. I removed the second one and - everything was fine.
Including a header file twice in the same *.cpp file seems to be no problem to the compiler but to the IntelliSense part.
Simply refresh the project/solution. It will get resolved.
I ran into this problem with the latest Visual Studio 2017.
Also the debug version of my program was running painfully slow.
I deleted the Solution file .sln and created a new one.
I had a similar problem when I was seeing lot of red squiggles in a couple of files. I tried all answers proposed previously, but nothing seemed to work.
The moment I started browsing through the classes, structures in other files for which complaining files had references, the problem disappeared. It seemed IntelliSense was not able to resolve dependencies on its own for some reason.
For me, I had at one time enabled fusion logging to debug some assembly dependency errors (fuslogvw from a CMD prompt). That was months ago and I had been experiencing much slower build times (5-7 minutes) since then.
I had also forgotten entirely that I had left them enabled. These logs were my bottleneck and disabling them has made iterating much faster.
In my case with Visual Studio 2017, I have many "red lines" shown below all symbols defined in a third-party library, but my project can actually build without problems. I have tried all suggested solutions (like delete the .VS folder, restart Visual Studio, etc.), but none of them working.
Finally, I fixed it and this is how: I open my application project's property page, then go to C/C++ → General → Additional Include Directories, which is the place I put all needed third-party library header paths.
I delete all the path (but save them somewhere), click "Ok" to confirm. Then I come back to the same setting, paste those paths back, click "Ok" to confirm, and then all those "red lines" disappear.
I have VS2019 with ReSharper, and ran into this issue.
What worked for me was:
Go to the ReSharper >> Options menu
Go to the General tab (should be the default)
Press the "Clear caches" button
Close all instances of Visual Studio (2019)
Restart Visual Studio
Using VS2022 without Resharper when this problem occurred, tried several things, this did help me in the end:
Close Visual Studio
Delete folder .vs in the Solution folder
Go to folder %USERPROFILE%\AppData\Roaming\Microsoft\VisualStudio\
Delete all folders whose names start with 17.
Reopen Visual Studio
More specific subfolders could exist that might be enough to delete, but I had no issues after deleting all of it. AFAIK these only contains user session data, temporary files and/or cache files that can be downloaded again or recreated as needed.
Found this solution:
Close Visual Studio (ensure devenv.exe is not present in the Task Manager).
Delete the %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\xx\ComponentModelCache directory.
Restart Visual Studio.
I have had this problem for months and have finally fixed it. Closing Visual Studio and removing the .vs folder located in the solution directory did not work for me.
There was an assemblyIdentity tag in the web.config file which was referencing a library that was not in my references folder. I removed this tag, cleaned, closed and reopened, and the problem was fixed.
Check each of the assemblyIdentity tags in your web.config file and check them against the references folder in solution explorer
Remove any assemblyIdentity tags, including the parent dependentAssembly tag for any which aren't listed in your references folder.
Clean the solution
Close and reopen the solution
Deleting .vs folder did the trick for me.
for me this works:-
Open the Command Palette ctrl+⇧+p
Then type: reload Window.
Deleting all the folders which start with "asp.xxx" worked for me. You can reach these folders by:
(C:\Windows\Microsoft.Net\Framework\vx.xx\Temporary ASP.NET Files)
Hover over the word that has the red underline squibble. A mini dialog box will appear. Click on 'Quick fix' and then click on 'Disable error squibble'.
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!
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.
I've got a Visual Studio C# project which is under version control (SVN).
I've always commited and updated the project without any problems. But a couple of hours ago Visual Studio throws the following error when I try to launch/rebuild the project:
Files has invalid value "<<<<<<<
.mine". Illegal characters in path.
I don't know how to fix this problem. What should I do?
That happens when svn encounters a conflict: You changed a file, the file on the server was changed and it cannot (easily) be merged automatically. You need to decide what is the correct solution now.
Subversion just adds the diff into your source file (and creates files next to it, called OriginalName.mine (unchanged) and OriginalName.rsomething (unchanged, server version)).
Fix the conflict and tell subversion that this is resolved.
just delete the obj folder and it will worked fine.
Remove the code that shouldn't be in the file throwing the error and remove the the three files with extensions .mine, .<somerevision> and .<some_other_revision>. svn updated files that now contain 'conflicts' and you need to resolve these conflicts by hand. Usually this means you edited a file, someone else edited the same file and checked in changes and you didn't pay attention when checking out the changed file.
Delete every thing you have in obj folder .
Remove your obj folder from svn version control . Because on every build it get updated and when other developer commit changes to solution SVN is unable to marge obj folder files and raise error
Files has invalid value "<<<<<<< .mine". Illegal characters in path.
Please read the Basic Usage chapter in the subversion book. It has a section about Merging conflicts by hand which explains the conflict markers you're seeing.
Removing the debug folders worked for me (see comment-not answer above).
I got this after moving 12 folders from one section of svn to a new section. So if you get this after moving a project and the error does not point to an actual file, this is likely your issue.
If you have AnkhSVN or VisualSVN installed resolving this is most likely as easy as right clicking the file in the solution explorer and selecting edit conflict.
This will open the changed file in your merge editor. (See Tools->Options->Source Control->Subversion User tools for AnkhSVN). With a good merge tool like the free to use SourceGear DiffMerge or TortoiseMerge, resolving the conflict is just a few mouseclicks away.
I have had this happen on a large scale where the files get marked resolved but the conflict metadata is still there. I wrote a regular expression for visual studio to find these, for instances where it is not feasible to simply revert the changed files.
http://www.codetunnel.com/blog/post/90/ever-merge-with-svn-and-mess-up-when-resolving-conflicts-read-on
I closed the IDE, then deleted the obj folder and restarted the IDE and rebuilt my Code. This worked for me.
Inside your project :
odj folder -> Debug -> project name.csproj.Filelistabsolute.txt(snb.csproj.Filelistabsolute.txt)
Inside the text file
>>>>>>>.mine and >>>>>>>.r150 occurs
to remove the things the program works
1)Just save your local changes whatever u have edited in the file
2)revert the file
3)update it from SVN
4)Paste your local changes
If you are using TortoiseSVN you should have a right click option on the file called Edit Conflicts. This should bring up TortoiseMerge which is able to read those obnoxious notations stuck into the file (really, to break your code so you KNOW there's an issue and don't blindly check it in).
TortoiseMerge will read it properly and present you with a 3-way merge. This was what I was looking for. Although it is true that it does also create the separate .mine and .rxxx and .ryyy files, and there are various manual and command-line ways to deal with all this.
Have a simple solution. just delete all file from debug folder and rebuild the solution, an error display on the screen "There were build errors. Would you like to continue and run the last successful build? click on "Yes" button. Now stop the program and run normally.