The root of the problem is perfectly explained here (mind you, my question is different from what can be found in this post): Xamarin - Android - Visual Studio - The application could not be started
In my particular case:
Debug from PC1: everything OK
Debug from PC2 without uninstalling debug app from PC1: the error appears for the first time
Try everything to avoid this error. The app cannot be found in the phone, I deleted the files manually as one post suggested (this might have been a mistake). No "myAppName" files can be found in my phone.
So I have decided to trick Android into thinking it is a different app, and this is what my question is about.
I have changed everything I found in the project (namespace, blah blah) from "myAppName" to "slightlyDifferentAppName" but the problem persists... I have debugged different projects form PC2 and they work, which makes me think it is a "collision" between different signatures of the same app (because otherwise it makes no sense that it worked in PC1 and not in PC2).
My question is: what can I tweak in Visual Studio in order to trick Android into thinking it is a different app?
Related
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.
I'm trying to set up a new Android app development environment at home and I've run into a problem that is a showstopper.
First, here is my environment:
Windows 10
Visual Studio Community 2015 with Xamarin platform installed
Test device is: G Pad 7.0 LTE
Android Version 5.0.2
I'm following this tutorial: MSDN tutorial
When I go to debug my test app, here is what happens.
Select debug from Visual Studio with my tablet as the target
VS deploys to the tablet
App starts on the tablet
App and debug session runs for about 5-10 seconds.
Debug session ends and app closes
No errors are displayed in Visual Studio and when i turn on Android logging it's a such a massive overflow of information that I don't really know where to begin searching for a problem.
Please also note that when I first set up the app, according to the tutorial, debugging on the tablet worked fine. The initial build is simply a template with a few basic controls.
In between then and when it stopped working I also added and successfully tested a Windows Phone project on a Windows Phone device.
Once I got to the section where I was modifying the project is when the problem started. I thought that perhaps a change in the code I did caused this issue so I tried another blank app and that blank app now crashes as well.
When I deploy the tutorial app to an emulator it crashes immediately but when I deploy a blank app it doesn't crash.
I also tried restoring the tablet to factory defaults and testing again. Same scenario: Blank app and tutorial app run for a few seconds, debugging stops, app closes.
Any clue as to what type of problem I'm looking at?
Solution
Clean your project (Right-Click on Project and select clean)
Go to your build folder. Probably in your Android project's root folder, named "obj". Delete either build you had, when you ran into this behavior (Debug or Release).
Directory Path
./AndroidProject/obj/Debug
./AndroidProject/obj/Release
Restart Visual Studio
Build and run again and it should work just fine, as the md5-hashes are now matching again.
I had also uninstalled the app before from the device and restarted it, I don't know whether this is required anymore, because the app is now being "reinstalled" by newer Xamarin versions anyway.
adb uninstall com.your.domain
Story and Background information
Have had the same issue with a device running Android 5.0.
Basically, the app was just stopping without any note.
When I now restarted the phone, The log was extended (once) by the following line:
Device could not find component named: *com.your.domain*/{*md5hash*}.*{Activity}
It turns out that with Andrpod 5.0 a hashing mechanism was implemented:
With the 5.0 release, the default package names for Android Callable
Wrappers will be based on the MD5SUM of the assembly-qualified name of
the type being exported. This allows the same fully-qualified name to
be provided from two different assemblies and not get a packaging
error.
See this for further information Xamarin.Android 5.1
So, if the md5-hash now changes from time to time, a simple Clean of your project is not enough.
I ran into this same issue and applied the same solution described above many times, which seemed to remedy this particular problem.
A possibly related fix, but definitely worthwhile note
After releasing this Android app and later releasing updates to the app, we got feedback from users that their Android Home screen shortcut to the app was disappearing after each app update. This is not good, for obvious reasons, but the fix for it was very simple as noted here:
dream-team-mobile-blog - Android app removes shortcut on update Xamarin solution
On the main activity, set a Name attribute of
<your package>.<your main activity>
like:
com.mycompany.myapp.MainActivity
For my solution, I chose to do it in code like this:
[Activity(Name = Constants.PackageName + "." + nameof(MainActivity),
Label = Constants.AppIconTitle, Icon = "#drawable/icon",
Theme = "#style/splashscreen", MainLauncher = true,
LaunchMode = LaunchMode.SingleInstance,
ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation)]
//Side Note: I change my PackageName between Prod and SQA builds, so using
//a constant as seen above makes that change less risky to miss maintaining.
//Also, using nameof() keeps things tight and a sure match.
public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity
I mention it here in this post because, having this fix in place may have:
definitely prevented app shortcut loss and
possibly prevented the issue discussed in this post
as the MD5 hash prefix from the Main activity seems to no longer be generated.
This tweak may fix two bugs with one fix. If not, implementing a fixed main Activity Name will surely help your users keep their shortcut to your app when you release updates!
What fixed it for me in Visual Studio 2017 is going to :
Tools → Options → Xamarin → Android Settings
and uncheck:
Preserve Application data cache on device between deploys
go to your AndroidManifest.xml and change your package name.
I have found some similar questions on here, but none that are quite the same thing. This Question is probably closest. I am using VS 2015 Community on Windows 10.
This is where it hangs:
I cannot kill the process from Task Manager or CMD when this happens, even signing out or restarting will hang indefinitely. I have to manually kill my machine (hold down power button) to get it to die when this happens. When I restart, I can load the solution, but it will contain no projects.
I am not creating projects in an unusual location.
I am running VS as admin.
I have tried disabling UAC entirely.
I have tried being sure to uninstall all other versions of VS and utilities, SDK's, etc.
If I instead install VS 2013, I can create WPF projects and view XAML in Designer without issue.
There is no XDesProc process to kill in Task Manager when this happens (this is a commonly suggested workaround for issues with Designer, but the process just isn't there in this case).
I can create projects of other types fine. If I try to open an XAML file, depending on how I do it, it may hang or may give the "Object reference not set to an instance of an object" error. I want to be clear on this, it does it even on a straight-up boilerplate XAML file that VS itself has generated on a new project, with zero changes.
I have ultimately managed to work around the issue by setting my default XAML viewer to 'Source Code (Text) Editor'. After doing this, it works just fine; project can be built and run as normal.
It's an okay workaround, but it would still be nice if Designer was working. Anybody have any ideas? It's incredibly hard to search for related issues because the error will almost invariably lead to others who had problems in their code, not with the Designer itself.
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 have a really wierd problem with my app. When i debug the application from visual studio it works perfectly but when i execute the exe file from the debug folder one of the methods does not work at all.
the weird thing is that it is just one method everything else in the application works
i read up on similar types of problems and most articles go in the direction of the configuration manager where the setting for platform is set to 'anyCPU' i changed the platform to x64 because my development machine has a 64 bit OS but i still get the same problem occuring..
this problem has me stumped for the last couple hours....
any help would be appreciated
thanks
Are you sure that while debugging thru Visual studio u r not checking any properties manually(at run time)? I mean by putting some breakpoint and then traverse thru the property tree of the object. Because that can result in intializing some stuff which can lead to different execution path. I am saying this from my personal experience, as i was debugging and checked some properties at run time, which was resulting in desired result.
delete all .dll and .exe file in your solution directory(those which are solution's project output) and then rebuild all project
If you are working with webservices there could be the problem, that the answer from the server is to slow. while debugging the program "runs slower" and the answer has many time. Without debugging programm runs fast and you have the problem of the answer not beeing there when you need it.
I've had this kind of problem one time and too needed a long time to get the point ;-)
Another solution could be a different security police in and out of VisualStudio (I'm not really sure but sometimes it seems like Programs have more rights while debugging (at least on my PC)).