I have a C# web application that I've been working on which has built properly since I began working with it. I moved the entire solution into a different folder, and now, when I try to build it says "Rebuild All failed" with no other errors. I have reviewed the verbose output from build; but, I don't see anything that jumps out at me as causing the problem. If I move the solution back to the original location, it will build again. Anyone know why the new location breaks the build?
Thanks.
The most likely cause of this error is that the location you are moving the solution to is not trusted.
For example, if you move the solution to a protected folder like C:\Program Files or C:\Windows or a network location.
If this is not the case, please advise where you are moving the file too and perhaps share any errors from your build log.
I believe I found it- turns out, moving it several directories deeper may have blown the maximum path size for NTFS (see this question: VS2010 - same soltuion (IE SVN checkout), different locations, one builds, one fails any ideas?). I moved my project to a root directory in c: and now it's compiling normally in VS2010.
A friendlier error would have been nice; but, hey, what can you do?
Related
I work on this project every day, and recently each day its broken (refuses to build)
Error message:
Microsoft.Common.CurrentVersion.targets(5100, 5): [MSB3021] Unable to copy file "D:\projects\Emulator\Emulator.Server\obj\Debug\net6.0\apphost.exe" to "bin\Debug\net6.0\Emulator.Server.exe". Access to the path 'D:\projects\Emulator\Emulator.Server\bin\Debug\net6.0\Emulator.Server.exe' is denied.
I'm unsure what is causing this. I've tried everything I can think of: dotnet clean, deleting bin and obj folders, nothing seems to want to fix it.
The process is not running. I can also delete the .exe so it isn't in use anywhere.
There really doesn't seem to be a fix other than renaming the folder to something else, building it, renaming it back. If you just change it on a regular basis it will keep happening and "break" the path its in when it breaks, no explanation I guess we just have to live with it.
It's a feature not a bug, right Microsoft?
I was working on a WPF application in Visual Studio 2015 and all went well until unexpectedly the build dropped me the CS2012 error inform me that it cannot access/update the executable in the /Debug directory.
I tried the following and it didn't work:
Restart
Close VS and open the application again
Build->Clean
I couldn't find any solution in the web so I tried:
1. to move the whole project directory to another location.
2. creating a new WPF project and assembling it file by file with copy/pastes.
The weird thing was that in both cases the application worked in the new location. I continued the experimentation (in the original directory) and i tried to build a "Hello World" Console application in the same directory. The result was that the trivial console application didn't work and produced the same problem as the WPF application (CS2012 error).
Since I haven't noticed any activity of another program (i.e., antivirus) trying to quarantine (or changing the file/folder permissions of) this folder, I assume that this has been done by VS somehow but I don't know why. Perhaps it is a bug.
Is anyone has a logical explanation about this problem? And a way to fix it?
I found that my other running solution was referencing the same < executable path>.
Just make sure that no other process is using the referenced folder/file/dll
Try to close all processes, move the project to a different folder (on a different disk) b restart the computer and everything will work as it should. It worked for me without any problems. Hope this helps someone
I wanted to quickly test something in a .NET Core Console Application Solution and ran into this issue due to BitDefender blocking the resulting binaries.
I've named the app client which actually was the culprit. Renaming my solution fixed this.
Sometimes antivirus softwares can block copying an exe file from a folder to any path. You can manage by settings or the easiest way is to shut down live protection while you are coding and debugging.
:)
Deactivate your anti-virus for a while and try again.
This works for me.
I'm working on a game written in C# using VS2013 and monogame. However, monogame doesn't support the XNA content pipeline (still), so the going advice is to build your content separately using Microsoft's XNA and VS2010. Since I didn't want to clutter my primary development machine (Win8) with VS2010 et cetera, I created a Win7 virtual machine to run Win7 along with VS2010 and all the tooling I need to build my content. All my project and solution files have corresponding 2010 versions, and the 2010 solution only has the necessary projects to build the content.
I can successfully build the content, but only if it's present direcly on the VM's hard disk (C:\). If I map a local drive to a network share on the host machine and attempt to build, I get a build time error. Why do I want to do this? Because I want a single copy of the source tree so I can iterate at a decent speed. It's just far too painful and error-prone if I have a separate source tree in the VM.
Here's the build error I get:
Error loading pipeline assembly "S:\Src\ContentPipelineExtension\bin\x86\Debug\Newtonsoft.Json.dll".
I have S:\ mapped to my network share. Newtonsoft.Json.dll exists at the indicated path.
I have tried:
specifying /verbosity:d when building to see if any more information is output. There isn't.
attaching a debugger to the MSBuild.exe process with break on any exception enabled. It never breaks.
using subst instead of Windows Explorer's drive mapping tool (it might be using subst behind the scenes, but I wanted to be sure).
debugging MSBuild, but I hit the "mismatched leave" bug when I did so.
applied the workaround for the mismatched leave bug and debugged the build simultaneously on both C:\ and S:\. In both cases, I put a breakpoint right before XNA's BuildContent task was called. I let both builds run until they hit this breakpoint, and then I opened the locals windows, side-by-side. I compared all locals and found no difference apart from the expected C:\ versus S:\ path roots.
spelunking through the XNA code in ILSpy to try and figure out where it's going wrong, but have had no luck with that either
enabling full trust on the network share in CAS by executing: CasPol.exe -m -ag 1.2 -url file://S:\* FullTrust. No change in behavior.
enabling Fusion Log Viewer (fuslogvw.exe) and checking out its log. It says it has successfully loaded the assembly!
added <loadFromRemoteSources enabled="true"/> to my MSBuild.exe.config. No change.
Why does the build fail when running off my mapped S:\ and succeed when a copy of the source is placed on my C:\?
UPDATE: I just found the most awful work-around. I modified my ContentPipelineExtension project's Output Path such that it is an absolute directory on my C:\. This allows the build to complete successfullly, but is obviously far from ideal.
Here is a hack I used. It's not a satisfying answer (and I won't mark it as accepted), but in the absence of a better solution, it will save me an enormous amount of time and pain.
I edited my 2010 project files and changed my output paths to something like this:
<OutputPath>$(TEMP)\ContentPipelineExtension\bin\x86\Debug\</OutputPath>
The TEMP environment variable resolves to a folder on C:\ and saves me hard-coding a specific path. Now I can build the project from my Win7 VM using the same source tree as I use in my primary Win8 machine.
Recently we have been having problems with TFS and our code base. We have a section of tests that use Webdriver, and a section that use Coded UI. Lately, we've been having problems merging our code after a new build has been pushed out. Some folders show up as a white outline of a folder, which we can right click and select "include in project". We also notice some files missing, and we can't "get latest" to grab them. We have to go some round about way to do it (shelve code, delete local files, get latest, merge code). Even when we do that we still have some issues.
But the main issue we are having is that our Coded UI maps are breaking. Instead of being the normal structure such as:
.uitest
----.cs
----.designer.cs
When we merge in the new code, the UI maps break out like:
.cs
----.designer.cs
.uitest
I opened the .csproj in notepad++ and noticed that both the .cs and .designer.cs files no longer have a dependancy of the .uitest file. Now the .cs file has no dependancy, and the .designer is dependant on the .cs file. We can fix it with relative ease, but it keeps breaking in every build and we have several maps we need to fix. What exactly could the problem be here? Also, referring to my frist problems of files not being included in the project, what could the issue be there?
I asked the same question on the MSDN forums, but the suggestions I have received I have already tried, like creating a new workspace since the other might be corrupt. Still didn't work.
Thanks in advance
Edit: Had a suggestion on the MSDN forums to run VS as administrator. That didn't work either. Not really sure what could be causing this issue. It doesn't seem to be causing problems for everybody because some new builds cause issues for some people but not others. Some more info would be I run on Windows 7 64bit and Visual Studio Ultimate 2010.
In the past I've had issues with TFS that sound similar, 2 of our developers seemed to periodically create problems when merging files into the data store, folders and files would show as not included while the project file would make it in (breaking everything after get latest). Eventually the problem went away but we never truly found the source. I believe it had something to do with our network - maybe a switch issue in combo with the way we mapped working folders to network drives pointing to a shared dev server. Also one of the workstations seemed to have a problem with windows explorer not seeing file updates on the dev server share... developer would have to hit \servername\C$\sharefolder then hit his mapped network drive again before updates would refresh. (And his check in's created the most problems) ... we ran VS2008, TFS2010
Just some ideas...
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.