I am trying to deploy an android app built on C# .NET (in debug mode) to Nokia 5 (Android Pie) using Visual Studio 2019 v16.10.3, but it always fails with error :
XA0136: The 'run-as' command failed with 'run-as: package has corrupt installation: com.ashish.myapp.'
However it deploys and runs successfully in the same device when I turn off the Fast Deployment mode. It also deploys successfully in android emulator with Fast Deployment mode on.
Well obviously I am able to test my builds but it is quite difficult to test gestures on emulator, on the other hand it takes almost 1 minute to deploy an app on a physical device when Fast Deployment mode is off.
Do anyone has any solution?
You could speed up by configuring your project. You could check the configurations in Debug Builds and Release builds.
Enable Fast Deployment (If you do not want this, try the following steps.)
Without Fast Deployment, Xamarin.Android has to build an APK every time there’s change in your project, regardless of size or scope.
UnCheck Multi-Dex
Enable Multi-Dex should be unchecked: unless your app fails to build without it.
Uncheck these Release-only Settings
Using AOT, Linking, or a Code Shrinker for Debug configurations is not that helpful. They will slow down your Debug builds with no real benefit.
For more details, you could check the link below. Some other tricks would be helpful too. https://devblogs.microsoft.com/xamarin/optimize-xamarin-android-builds/
Link SDKs and Frameworks
You could try to utilize the Linker for Release Configuration builds.
On Android Build Settings, generally, we could use Shared Mono Runtime and Fast Assembly Deployment like deploy assemblies to a directory on the device instead of bundling them in the APK. Link SDK assemblies only would reduce the time as well.
The more detailed information about speed-up the build time you could find here. https://github.com/brminnick/ImproveXamarinBuildTimes
I have a C# Console application that was developed in different machines. In this application, we chose to use Fody, because it's the only thing we found that would embed all external resource dependencies (any extra class libraries) into a single executable for our application.
Environment Detsils:
Visual Studio Version: 16.9.2 (Professional 2019)
Type: Console application
Framework: .Net Framework 4.5
Fody Version: 4.2.1
Costura.Fody Version: 3.3.3
While this application worked without any issue in one machine, it starts giving trouble to another machine. We need to get this work on both machines as we need to cover lots of work. We have compared the two environments but couldn't figure out any difference.
the behavior of the issue is as below,
The first time when I clone and build a solution it goes in a
never-ending path and I have no other option other than end tasking
the visual studio.
And I observe that MSBUILD is occupied by something and I cannot end
task it
The second time when I start the solution and build it, I am getting
the following error.
Severity Code Description Project File Line Suppression State
Error CS2012 Cannot open '<<obj folder path>>\Debug\Binary.exe' for writing -- 'The
process cannot access the file '<<obj folder path>>\Debug\Binary.exe' because it is being
used by another process.' Binary.exe <<project path>>\CSC 1 Active
I had to restart the machine to remove the obj folder. And once it is removed Same above behavior repeats.
I found below a similar question below thread,
Error during building application with PropertyChanged.Fody
But it seems like this feature is obsolete in the latest Visual studio as per the below question.
Disabling Visual Studio hosting process on Visual Studio Community 2017
Further, I have tried to set the environment variable as explained in the below thread as I thought its somewhat relevant. However, it doesn't work as well.
https://github.com/Fody/Fody/issues/537
I must use these Nuget packages in my solution. Highly appreciate it if someone can share some thoughts to sort out this issue
My app does not run on "Release x86" when running the app it crashes immediately after the splash screen. Output shows the following exception:
The program '[8204] dfz.exe' has exited with code -1073741515 (0xc0000135) 'A dependent DLL was not found'.
It also tells me the module is build without symbols, however in build settings I have set debug info to Full.
The first time I build the app for the Windows Store it built correctly and I also published that version to the store. When I did a manual rebuild to check if ads where inserted correctly it would not run.
However, I can run the app on ARM and X64 with no problems on release. Only x86 with .Net native toolchain will throw the missing dependant DLL.
What I have tried so far:
Created a new project, Added all my files and Nuget packages, No dice
Removed and updated all my existing references.
Tried to debug the release version so i can find out what DLL is missing from the package. However it keeps telling me there are no symbol files.
I am looking for any suggestions I can try because I am really at a loss here of why it will not run on x86.
Edit:
A blank UWP project also returns the DLL error when i run it. It looks like i have a broken development environment.
Edit2:
Just did a remote debugging session to another laptop and the app worked with no problems. So the problem is an environment related issue.
Could one of the projects in your dependencies be configured specifically for x64?
Another thing to check is that one of your projects is not set to build for that configuration (I vaguely remember some problem I had years ago that sounds kind like your situation ... although not for windows store apps ... and it turned out one of my projects wasn't set to compile for the configuration I was selecting ).
I'm trying to debug an application built in Visual Studio C# under MonoDevelop in Linux.
I have the source code, so I followed instructions that appears at Icaza's blog at http://tirania.org/blog/archive/2010/Feb-20.html without success (which basically consists on create an empty solution and set the Execute command to the already compiled application)
The application is executing correctly but when I load the source code file, and set a breakpoint, it never stops.
pdb's were also transformed to mdb's using pdb2mdb command.
What am I missing?
BTW, load source code into Monodevelop and build the application under Linux is not an option right now, due to the big size of the application and lots of tweaks in the build process. Just wanted to debug the compiled assembly.
There is a command line utility for soft debugger, have a look it, this might be what you are looking for.
First of all I would like to say that I already tried all the solutions I could find on the internet, including Unable to Activate Windows Store App
I recently upgraded my Windows 7 machine to Windows 8.1 to be capable of developing Windows Store apps using Visual Studio 2013. When I open a blank project (Windows Store -> Blank App) and run it I get this error:
Unable to activate Windows Store app 'Package Name'. The App1.exe
process started, but the activation request failed with error 'The app
didn't start'.
See help for advice on troubleshooting the issue.
I already tried:
Reinstalling Windows (Clean install)
Reinstalling Visual Studio 2013
Installing Visual Studio 2012 (same error)
Deleting "bin" and "obj" folder
Cleaning the solution
Uninstalling the app from start menu
Creating a new project
Acquiring the license multiple times (the license is valid)
Making sure that app.config doesn't exist
Investigating the Windows Event Log which says
Activation of the app 'Package Name' for the Windows.Launch contract failed with error: The app didn't start..
but found nothing useful
Adding a new Windows user
Run everything as administrator
and at last, changing the desktop background :)
None of this did bring a solution. Does anyone have an idea what else could be the reason for this error?
Thank you.
I found a solution. The problem was that the drive I was working on was encrypted (TrueCrypt). Moving the output folder to an unencrypted drive solved the problem.
If switching from x86 to x64, make sure your Project Properties Platform Target and Configuration Platform are BOTH set to X64.Hint you need to change to x64 debugging in the Build menu/Configuration Manager dialog to get the Configuration Platform in Project Properties to update.
This caused the activation error problem to be resolved for me
HTH
Robert
I had the same Error and tried after loading the SQLite Package for WP 8.1 some things above:
not working:
Clean and Rebuild
Restart Computer/Phone
what did the deal (for me)
I put Platform Target under Properties -> Build to ARM instead of x86
Hopefully this might help somebody else facing this ridiculously informative Errormessage.
I had the same problem with Visual Studio Community 2015 while trying to debug an Blank App (Universal Windows) using Visual C#.
Visual Studio was installed on Disk C:(SSD), and Project files were placed on D:(HDD). I´ve created a Folder on C: Drive and placed my test project there.
After that Error messages gone.
If you are receiving this error and are developing for Microsoft Hololens:
You are trying to build to a device that is asleep. To wake your device, tap on the button on the back (on/off button).
Good luck!
I've tried all the solutions found on the net and none applied to my case, not even this one.
The only way I could make it work was changing the Package Name in the appxmanifest.
This made me think there must be some leftovers somewhere around with the old package name, that are either corrupted or inaccessible because of some permissions issues.
It might be just a coincidence but the problem appeared twice after I tried using the app verifier (appverif.exe)
Now I reassociated my app to a store app package and things seem to continue working...
In my solution, I have a non-UWP project (Multiplatform development) that builds with a different Solution Platform.
I was attempting to run the UWP project in Debug, but as the wrong Solution Platform.
Edit:
I also get this when I build my project for Any-CPU, instead of x64.
Ensure that ALL APPLICATION PACKAGES has "read" permissions on C:\Windows.
My organization's group policy likes to strip all permissions from C:\Windows, including the ALL APPLICATION PACKAGES group . By adding it back in and setting Read & execute, List folder contents, and Read, I'm able to run the app from Visual Studio without any problems.
See What to do if your Windows 8 Modern App fails to start for more tips, including this one.
I had the same problem in Visual Studio 2015 Update 3, Windows 10 Build 10586.494.
The error came up when trying to start any UWP app that I compiled without .NET Native Toolchain. With Native Toolchain enabled, the apps would start.
Installing a new (blank) app manually fixed the error for me:
Start VS 2015
File > New > Project.
Blank App (Universal Windows) Visual C#. OK.
Make sure to be in Debug config
Right click on Project > Store > Create App Packages
No. Next.
Select Debug for all architectures.
Create
When packaging is finished, open Explorer to the project path / AppPackages / [...]_Debug_Test
Right-click on Add-AppDevPackage.ps1 > Run with PowerShell
Follow the instructions
Start the installed app from Start Menu
I had the same problem a couple of weeks ago. A simple restart helped me out.
Also tried this one?: http://irisclasson.com/2012/11/04/problem-unable-to-activate-windows-store-app-the-app1-exe-process-started-but-the-activation-request-failed-with-error-the-app-didnt-start/
Hope its usefull to you
I managed to fix the same problem by rebuilding the solution. (In Vis Studio 2012)
I have tried many solutions and nothing worked. At the end what worked for me was to change the startup project to windows phone 8.1 and after it runs OK I changed it back to windows 8.1 and it runs OK. It works for me as I am making a universal app. Hope it helps anyone else.
I had the same issue with a Windows Store App after moving some files around. I ended up opening an older file (as Admin) to see if it would run and found that it did. I then returned to the file that would not and it ran also. I believe opening the older file (as Admin) reset the paths for development and the permissions. Hope this helps.
Same problem - moved my project from the TrueCrypt Partition and all was fine.
I had a similar issue, solved by choosing a new publisher certificate. And of course restarting Windows
I had same issue. Selecting proper Platform solved my problem. i.e. My application was selected to run under x86 platform, while my OS & SDK supports x64. Selecting x64 solved my problem.
I had the same problem on a UWP app when creating a package for Testing, but not when runing directly from Visual Studio 2017.
The solution was to select only the architecture that I am using to Debug the App, Instead of all options (x86, x64, ARM).
Here is the option choosed on Visual Studio
There are can be a couple of things that might be causing this problem.
Here are the trouble shooting steps that helped me out:
Step 1 : Check to see if running visual studio in the elevated mode (Run as an Administrator) helped solve the problem. (Sometimes, your folder permissions might get mangled due to various softwares that you might have install)
Step 2 : Delete all the bin and obj folders in your project and rebuild the projects in your solution manually.
Step 3 : Do a quick check of your System Type (x64 or x86 etc) and see if your project is targeted for the same.
Here is how to do know your system type: Win + R > cmd > systeminfo
If it says x64, then make sure to select the Solution Platforms (In visual studios top action bar) as x64 or so forth depending on your architecture.
Thats all I did to solve my problem.
I had unticked an option while trying to get debugging working prior to this error, the fix for me was to re-check the "Compile with .NET Native tool chain"
A rather niche situation and solution...
I was remote debugging a UWP app for a while successfully. After some reworking, I ran into this issue. In the main app project I had set the windows version compatibility accordingly (I am running the app on a Windows 10 IoT Enterprise 2019 device) but had forgotten to match those windows target and minimum versions for the Library Project that was in my solution.
After cleaning and re-deploying the solution (first uninstalling the app from the remote device), the problem went away.