I am working with a Xamarin application where I have already built both IOS and Android applications. I am using Visual Studio 2019 for the development and use iPhoneSimulator to test the application, after connecting to the mac device. Suddenly I am getting an error as preceding.
Error The file 'Resources/LaunchScreen.xib' conflicts with 'Resources/LaunchScreen.xib'.
Anyone ever faced this issue before, I am 100% sure that it is not related to any recent code changes, thus providing codes wouldn't help here.
As I was sure that the issue is not related to the recent code changes. I did the preceding things first.
Clean the solution and rebuild
Delete the bin and obj folder manually and then rebuild
But I was getting the error again, the only thing which worked for me is restarting the visual studio and open the project again. Hope it helps.
I get this error a lot, or various other errors that seem to be related with items being duplicated. The easiest fix is to just disconnect from the Mac and reconnect. This is assuming that you are developing on a PC and pairing to a Mac. I suggested to the developers that they simply include disconnecting and reconnecting as part of the build process until they can figure out the actual cause.
If you are on the actual Mac, the process that Sibeesh Venu describes may be what occurs each time Xamarin pairs with the Mac.
The developers asked me, and others that have reported this issue, to turn on diagnostic debugging so that they can be provided with a log for when it happens. I did this, and noticed that it occurs less frequently for me. This makes me suspect that it's related to timing when files are processed.
https://github.com/xamarin/xamarin-macios/issues/6770#issuecomment-575310911
I encountered this same issue after after doing a merge in source control. It turns out that there was a duplicate instance of the .xib registration in my iOS.csproj file. In other words, there were duplicate lines that looked like this:
<InterfaceDefinition Include="Resources/LaunchScreen.xib.xib" />
Once I removed the duplicates, everything worked perfectly.
Un Unity3d, I am having an issue where changes to Code (C#, Monodevelop) is not picked up, until I reload the Project or Reimport all assets.
The (Intermittent) problem seems to start when I write something with a compile time error. After that point, any changes to the file are ignored (the old error still appears when you try to Build again). Even commenting out the line, or adding other errors on purpose.
It seems to happen once or twice an hour.
Unity 5.5.0f3 64 bit on Mac.
Does anyone know a fix?
Can anyone suggest next steps to debug the compilation process?
I had this, upgrading to 5.5.1 once released fixes the problem.
I was searching for a test project I had coded a few months ago, and could not remember in which solution I had placed it. I decided to write some quick code to get all my Visual Studio 2010 projects' c-sharp source files, and look through them for a literal I know should exist in the file.
I started in debug mode, and when my code executed this statement, I got a blue screen of death:
string[] results = System.IO.Directory.GetFiles(#"C:\Users\<user name>\Documents\Visual Studio 2010\Projects\", "*.cs", SearchOption.AllDirectories);
After a reboot, I checked the event logs, and I only saw the generic unexpected shut-down messages. I brought up the temp project, ran in debug mode again, and got the BSOD again. If I remove the SearchOption.AllDirectories param, the code doesn't break, but it doesn't get me the results I want either. But when I put it back, BSOD again.
Does anyone have any insight as to what could be causing this, or where I might be able to look (logs, etc) to see what the issue is? I did not see a kernel dump in the Windows directory, and the event log doesn't show anything that would stand out to me. FYI, I can run the same search from Windows Explorer with no errors and all the files returned.
* Update *
I ran the same snippet of code but changed the file mask to *.txt, and it runs with no issue, so the .cs extension is playing into the error for some reason. Could it be having an issue listing the .cs file that I am running in debug?
I guess there is a disk hardware error in one of your projects. Try enumerating all files there recursively and log it to see which one causes BSOD.
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.
I am working on a gui app written in C# using visual studio and I am running into a really annoying bug where when I make changes to the application, it debugs correctly the first time I try to debug it, but when I try to debug the application again I get an error say that it can't copy an exe file from the obj directory to the bin directory.
Restarting visual studio fixes this.
It's really annoying to have to restart all the time though. There seem to be a number of posts online about this, but no one seems to have found the solution. Has anyone here been able to resolve this?
try VSCommands 2010 extension.
When you get the error again righ click on the message in error list and click 'Apply Fix' from context menu. This will tell you which process sits on the file and allow you to terminate it.
In a longer run, it may be that you have a background thread running which doesn't terminate when application finishes.
I have the same problem. I found in another thread (can't remember which) that for some unfathomable reason, you can change the assembly version declared in your AssemblyInfo.cs files from
AssemblyVersion("1.0.*")
into
AssemblyVersion("1.0.0.0")
Or some other explicit version, and the problem goes away. This worked fine for me. However, I would like a solution that would allow me to use the wildcard version as well. Or an explanation of why the assemblyversion causes the file to be locked.
is this a service? you may have to installutil -u prior to recompiling
In my case it was the Anti Virus software Avira antivir. When I added the publishing folders in the exceptions the problem went away.
Avira usually takes a long time to scan stuff in the background, apparently locking exe files before they can be overwritten. After the scan the file is unlocked. When my develop/test cycle is less than 30 seconds (which it often is) it will trigger this error after retrying 10x.