I have a C# project opened in visual studio. We are using TFS to manage our projects. In one source code file of the project I have configured a warning in the following way:
#warning expand for all properties
When I compile my project the warning is shown in the error list twice. Once in the original file, and once in a file called vctmp2984_94722.cs. I can open the temporary file in visual studio and it has a previous state of the file.
Opening the file in explorer is not possible, cause the path of the temporary file points to a place that does not exist: C:\Users\developer\AppData\Local\Temp\TFSTemp\vctmp2984_94722.cs
Does anybody nows how to solve this?
Did you have a "compare" running (with the "Diff - xxx") window open when you kicked off your build? I noticed that I was getting this---a ton of vctmp errors in a project called "Miscellaneous Files", but when I closed the Diff window they all disappeared.
Related
When trying to load a file from a target project directory using in C#
Directory.GetCurrentDirectory()
Visual Studio keeps looking for the file in
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\
The problem is that an annoying error about it keeps appearing, although the application builds, compiles and runs without issues, since the file exists in the project target directory.
Does anybody have any idea or previous experience?
Right click on the error -> Show error help, got me to this page, and by doing this, the error disappeared. I am yet to understand, how that had anything to do with the xaml designer.
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.
Everytime I open the database from visual studio 2017 and then try to rebuild the solution of windows form I get those errors:
Severity Code Description Project File Line Suppression State
Error MSB3021 Unable to copy file "C:\Users\bsuro\documents\visual studio 2017\Projects\WindowsFormsApp2\WindowsFormsApp2\App_Data\Database.mdf" to "bin\Debug\App_Data\Database.mdf". The process cannot access the file 'C:\Users\bsuro\documents\visual studio 2017\Projects\WindowsFormsApp2\WindowsFormsApp2\App_Data\Database.mdf' because it is being used by another process. C:\Users\bsuro\documents\visual studio 2017\Projects\WindowsFormsApp2\WindowsFormsApp2\WindowsFormsApp2.csproj C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 4353
Severity Code Description Project File Line Suppression State
Error MSB3027 Could not copy "C:\Users\bsuro\documents\visual studio 2017\Projects\WindowsFormsApp2\WindowsFormsApp2\App_Data\Database.mdf" to "bin\Debug\App_Data\Database.mdf". Exceeded retry count of 10. Failed. C:\Users\bsuro\documents\visual studio 2017\Projects\WindowsFormsApp2\WindowsFormsApp2\WindowsFormsApp2.csproj C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 4353
How can I fix it?
This happens because another process is using your project's resources, or you have insufficiant privilages to modify them.
Try the following actions:
"As soon as I open again my database the problem repeats herself" - Do not open your database while trying to build - you are locking the mdf file.
Open your task manager and look for a process of your application, it might be running in the background. If it does, kill it.
Make sure you are building in "Debug" mode and not in "Release" mode. If you are, there could be a production EXE running somewhere.
Close and reopen Visual Studio.
Start Visual Studio as administrator.
well what you have to do is on the top of vs, there is a button debug and kind of on the bottom a menu debug, now it has to be set on debug and next to it there is another menu, you have to set that to x86 click on it go to config settings than add x86 than run and all should be good
I'd been working on a visual studio project, and decided to rename it. After a little bit of renaming, everything was under the new name. I tried to open the project in Visual Studio, and the load failed, saying the project file had been moved, renamed, or deleted. I can edit the project via the C# project file among the other class files, but no matter how I try to rename files to change it back, the load still fails.
Any ideas on how to fix this?
I have the same problem but with VS 2019. I changed the name of the project and then got the same error. I fixed it by editing the .sln file because when I changed the name of the project one line didn't change. It was like this:
oldnamefolder\newnameproject.csproj
I changed it
newnamefolder\newnameproject.csproj
I have got a few projects and when I run them on another computer, it fires an error that says: the debugging doesnt belong to...
and it opens a browser dialog box as if it wants me to point to the missing file..
How can i overcome that problem?
"Entering break mode failed for the following reason: Source file:"D:Document and Settings..."(path to the old directory the files were).. doesnt belong to to the project being debugged.."
Try look here:
"Entering break mode failed for the following reason: Source File XXX does not belong to the project being debugged
from the above post:
I found 2 things that may have helped:
1) I had previously moved the folder location of a dependent project,
then removed and re-added the project to my solution. However, the
"References" of the depending project still showed the path to the old
location. These properties are unfortunately read-only within the
GUI, so I just removed and re-added the project reference.
2) I noticed that my Visual C# 2005 Express doesn't have a "Build",
"Clean Solution" menu option. Instead, I closed Visual C#, deleted
the "bin" and "obj" directories under each project, restarted Visual
C#, and things are working as expected again.