When I try deploy an app with the build type set to debug the app is deployed but crashes straight away.
If I try using the release mode the app is deployed and works fine.
I have tried cleaning the project and redeploying however that doesnt seem to help.
I have taken a look at the crash log but it doesnt make sense to me.
What do I need to do to get to the issue of what's causing the app to crash while trying to debug?
You can set a breakpoint in the Main.cs
If there isn´t a try catch build one around UIApplication.Main(args, null, "AppDelegate"); and put a breakpoint inside the catch.
From there you can go back in the stacktrace to find the cause.
Related
I have a Azure App Service app that I'm trying to get deployed.
Today I ran into an issue where .NET informed me (via the yellow screen of death when I browse to the URL of my app) that I had a missing DLL (for the purposes of this question I don't think it really matters).
I used FileZilla to publish my changes in an attempt to do a manual deployment first and then work my way to automate it.
After so many attempts to fix it I later realized that the error message never changed. I did something more severe and renamed my bin folder into something completely different and the exact same error message would appear.
I've stopped the service, restarted it, and as mentioned, renamed folders, etc. and still the exact same error message persisted.
I also decided to open up the Azure Portal Console for my App Service app to browse a bit and to my amazement, nothing seemed to have reflected at all. The FTP shows one thing and the Console shows another.
Would anyone have any idea as to why this is happening?
I eventually got it to work and I will share what I tried.
I deleted the web app and created it again (I found this to be important the first time around). This was quite time consuming and did help but it wasn't long before the same problem happened again.
Then I finally found a solution that seems to give me consistent results:
I kept on editing the Web.config which seems to force a recompile and clear some sort of cache. So each time the web app stopped updating, I would make a slight change in the Web.config, upload it via FTP and the app finally updates.
If anyone has any more details on this, it would be greatly appreciated.
I have an MVC application that I've deployed to Azure. Offline it works with no issue with the code first development. However when deployed to Azure it just gives me a non-de-script Error advising me that there's been an error.
I have a look on the management console for further information but was only able to find an error telling me a fatal error had occurred causing a 500 error. Everything else works on the site with no issue it's just when I'm trying to do anything with the database attached to it.
To publish the app I used the downloaded publish settings from the server so I know connection string and what not are all fine. I've also set up code migrations to fill in gaps in the code first dev work so I can see what I'm missing and I don't know where to go now without a more detailed error message?
Any ideas on where I can possibly look next to try and solve this?
I had a site running asp.net 5 beta4, and decided to upgrade to beta5. The site runs locally fine. I pushed the changes to master and it was picked up from bitbucket and deployed successfully.
When I try to hit the site in azure, I get a 500 Internal Server Error. I've tried a number of things, but can't seem to track down the root cause of the failure. I'm looking for suggestions as I'm hitting a wall. From what I've tried below it seems like some fundamental initialization is failing.
Here's what I've tried:
Enabling customerrors="off". I added a web.config to the wwwroot folder with system.web/customErrors mode="Off". I've verified that the web.config is populated correctly in the deployed wwwroot and had the appsettings containing the dnxversion etc merged correctly.
Customizing the custom error page, adding runtimeinfo. I have the following set in my Startup.cs:
app.UseErrorHandler("/Home/Error");. I also have set the error page to display the exception. This doesn't seem to be hit.
Attached to the remote process to debug. Visual studio eventually freezes, so haven't gotten anywhere with this.
Enabled application insights. This registers events when I debug locally, but doesn't capture anything from the azure instance.
Enabled application logs and request failure tracing. The detailed errors show a 500.0, without much detailed information.
Imgur
Imgur
I've also verified through the console that the runtime is set correctly to beta5.
Update:
I set the ASPNET_ENV to Development and it loaded with appsettings loaded via the azure portal. Setting ASPNET_ENV to something else isn't working. I also removed any custom code from startup.cs pertaining to the non-development environments, with no help. I'm still looking for a means of capturing the original error.
Assuming you are targeting DNX451 and not dnxcore50, there is a good chance Azure it still trying to run it against the beta4 runtime instead of beta5. If that's the case, you won't get a decent error message.
Try adding an environment variable in Azure "SCM_DNX_VERSION" and set it to 1.0.0-beta5. It looks like kudu was recently upgraded to support beta5 https://github.com/projectkudu/kudu/commit/55175a017779bf493ff8e6ce87b96dd1451f7d7b, so you might want to try to redeploy from bitbucket in the case that the Kudu team has already deployed this change.
For a little more detail, you can check out my previous answer (although it is very dated and references the old "K" names) here:
Deploying ASP.NET vNext beta 2 on Azure with Kudu
Every time you update to a new beta, you will have to update your SCM_DNX_VERSION environment variable.
I get same error every single time i try to launch ANY project , can't figure it out by myself where's the problem. I used eclipse but now tried android-studio as well but it didnt fix error. Even if i create new project-on launching it will crash.
when it crash it says -unfortunately "app" has stopped-
http://pastebin.com/P3QNYyLg
You'll need to import
android.support.v7
There's great instructions on how to do so here: https://developer.android.com/tools/support-library/setup.html
I have run into an issue with VS 2012 not hitting breakpoints during the seeding process of my DB. I am on Svr 2008 R2 using EF 5. This is similar to this breakpoint issue, but not quite the same. Once I get past the seeding process my breakpoints work fine in the controllers (and I assume everywhere else).
I can get the breakpoints to work with IIS Express, but not IIS 7. Since the breakpoints that I would like to hit are in the Application_Start and the Seed process I do not have time to Ctrl-Alt-P to attach a process and attempt debugging that way. I did check windows authentication and registration of iis, those did not affect the breakpoints.
I can verify that the seeding is run with logging and how the DB is created. I would prefer not to revert to the dark ages of debugging with logs though. I would also prefer not to be required to switch back and forth between IIS Express and IIS 7.
To recreate this I started a new VS 2012 proj selected MVC4 and Internet Application. I manually changed the web.config to point to SQLEXPRESS. Then I changed the project properties > web to not use IIS Express. I created a breakpoint in the Application_Start and and a breakpoint in the homecontroller/index and ran the project. The only breakpoint that was hit was the index breakpoint. Rechecking the IIS Express allows both breakpoints to be hit.
Please let me know if you have seen this issue and have a workaround.
Thanks,
TJ
I seem to be running into lots of these types of issues lately. I clear ways to replicate them, and I leave them alone for a few days and they disappear. I am unable to recreate this anymore. I even used the same project that I was only changing the checkbox to use IIS Express.
So, when in doubt, don't pull out your hair, work on something else and be patient. Who knows, perhaps turning it off and on again worked (even though I did try that, thanks Roy).