.net5 Azure Web App can not be debugged properly due to disconnects - azure

I have a .NET5 Service running at azure. Now I try to debug and i can connect successfully after this issue. So one Problem solved, next:
But for now it seems to happen randomly, that after connection the debugger disconnects from service.
So I do following:
restart service at azure, did this many times. Also tested with stopping service and start manually again.
immediatly press shortcut for reattach to process because i want to watch ConfigureServices method.
it connects successfully
shows nothing, means not ending up in any breakpoint
May I be to slow? Do not think so and "Thread.Sleep || Task.Delay" are not helping for catching up any Breakpoint..
after beeing connected it takes almost no time and i get this in my Output:
Output
After few Seconds I get this
Within Azure Diagnostic Tools Application Event Logs I can see following list (I tried several times)
Two entries from list are relevant as i guess, first says RDB connected, second that application has shutdown
Local debugging works fine by the way! Any suggestions where to find additional logging information or what is going on here?
I just found some additional logging in the Cloud Explorer of VS2019. in eventlog.xml I can see many events saying debugger already connected
May be anybody can help me getting further. Otherwise I will setup a new Project in my solution, maybe i broke something, and create a new azure service to have those components clean. Thank you guys!
Update:
Now I created a new service at azure, Set up a new project in VS2019 and no improvement. I tried to check against a new project with View too and tried to see how far code is beeing executed by throwing exceptions and it seems to be executed with no problems through whole startup class, just the remote debugging seems not working because of remote debugger already connected.

This issue may be caused by having 'Use Managed Compatibility Mode' enabled.
To workaround:
List item
Tools->Options
Go to Debugging->General
Scroll down to the bottom of the list and uncheck 'Use Managed Compatibility Mode'
Start debugging again
The debug attribute of the compilation element in your Web.config file must be set to "true".
<system.web>
<compilation debug="true" targetFramework="*.*" />
<httpRuntime targetFramework="*.*" />
</system.web>
This means, you either have to do a 'Debug' build or manually edit the **Web.config** file.
Be sure to add your IP Address to the firewall rules while you are debugging remotely.

Related

Azure App Services Web App not registering update

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.

Why do I see azure function host for .NET startup with Debug=True when I published as release mode?

When I look at the startup logs for my azure .NET function, I see the following line:
Starting Host (HostId=my-function-app, Version=1.0.11015.0, ProcessId=8308, Debug=True, Attempt=0)
I have published the project in release mode and I cannot find out anywhere why this is being set. I am assuming this is not an issue with my function but for some reason the host is in debug mode. Is this expected behavior?
That Debug log doesn't mean your code or the Functions runtime host are running Debug builds. The "Debug" here refers to our own internal mode we use to determine whether the Azure Functions Portal has been connected recently. We track that so we can optimize things for connected debug/develop sessions, and when those sessions are disconnected, optimize for steady state.
So you don't have anything to worry about :)
Check your web.config file and make sure
<system.web>
<compilation debug="false" />
Even though your assemblies are in Release mode, the ASP.net runtime uses this setting to change its behavior. I can't find a current list of changes, but I know it includes serving .debug.js files and enabling additional validation and logging.

Remote Debugging Azure Worker Role

There are a million links like this one http://blogs.msdn.com/b/cie/archive/2014/01/24/windows-azure-remote-debugging.aspx, which more or less would seem to take care of the remote debugging setup. I have done this many times in VS 2013 Update 2, deployed, then attached to debugger and it simply does not work. Well, the debugger seems to attach, but I continually get the message when I hover over a break point informing me that 'The breakpoint will currently not be hit. No symbols have been loaded for this document' A while back I recall seeing a channel 9 presentation and they seemed to configre the symbol store. I tried configuring this and it still gives me the same message when hovering over the breakpoint.
VS 2013 Update 2 Remote Debugging - I can only get it to work with a 'Debug' build. I have set the Debugging Option "Enable Just My Code" and loaded all symbols -- this seems to work fine. I can now set breakpoints and do not receive the message you (and I) noted earlier.
This is probably not the ideal situation as it would be nice to be able to attach the debugger to a production release but it seems to be a semi-reasonable workaround for now.
EDIT:
Important points:
You must enable Remote Debugging in the Azure Portal for your Cloud Service or Web Site -- Configure Tab (it only remains enabled for 48 Hours)
The debug attribute of the compilation element in your Web.config file must be set to "true". This means, you either have to do a 'Debug' build or manually edit the Web.config file. Here is a link to official Microsoft documentation with a full explanation and a great example of how to do that without redeploying your application:
http://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-troubleshoot-visual-studio/#remotedebug
If you still have problems you may have to disable the Debugging Option Enable Just My Code in Visual Studio
I had the same problem - also with VS 2013 Update 2.
The crucial bit I missed was selecting the w3wp.exe process in the pop-up that shows the running processes before hitting the Attach button.

Role instances are taking longer than expected to start - Is there a new solution to this problem?

I've rebooted my computer 50-100 times this week. I find I can start / deploy locally usually 3-4 times before getting this message:
"Windows Azure Tools for Microsoft Visual Studio
Role instances are taking longer than expected to start. Do you want to continue waiting?"
The solution to get me going again is rebooting.
I know it's not a new problem. I recall that MS agreed it was a problem but does anyone have a solution that does not involve going back to the Hosted Web Core. Seems like this problem is something a lot of people get and it's been around without a resolution (that I know of) for 4-5 months or more.
Now I'll get back to doing another reboot !!!!!
I had this same problem, but could eventually get it to start after dismissing 2 or 3 of the
"Role instances are taking longer than expected to start"
message boxes.
I then found that the problem seemed to be that the Diagnostics were enabled and the storage account was set to something invalid in the Role configuration (.cscfg).
Solved it by going into the UI and disabling diagnostics, I found it would run ok.
To get the UI, right click on the created Role inside the Roles folder in the Solution Explorer.
Then I re-enabled Diagnostics and it auto-populated "UseDevelopmentStorage=true", and this seems to work fine.
From what I understand, there are a few different things that can cause this issue.
For me, I encountered this error after I created a Windows Identity Foundation Startup Task for my Azure deployment and then tried to run my application using the Azure Emulator.
Basically, all I needed to do was change the taskType of the Startup Task from simple to background
ServiceDefinition.csdef
<Startup>
<Task commandLine="Startup\IdentityGac.cmd" executionContext="elevated" taskType="background"></Task>
</Startup>
Based on your question, I'm not sure if this applies to your project, but I figured it would at least be worth mentioning.
You can read my full blog post here.
A new cause for this problem was introduced in Feb 2016.
Using Windows 8.1, Visual Studio 2012 Update 5 and Azure Emulator 2.3
Installing this windows update: KB3126593 will leave you in a situation where the emulator will never start and you'll see this in the Emulator UI.
Uninstalling the update fixes the emulator.
Control Panel > All Control Panel Items > Programs and Features > Installed Updates
Security Update for Microsoft Windows (KB3126593), right-click, uninstall.
(Upgrading to Windows 10 also solves the problem.)
I was also facing the same issue. From looking into the Emulator UI I found that it was trying to read some date from storage area and was failing.
So what I did, I went to location %appdata%\local and deleted all data from folders
1. DevelopmentStorage
2. dftmp
After that restarting the service, every thing started working
For me, the problem was related to caching. The problem started with a warning that said something like, "unable to install cache....exe," but I only saw the error once. After that, the emulator stalled every time. After reading this blog I tried disabling and then re-enabling caching, which fixed the problem.
After I some further investigation I found that the critical issue was this entry in ServiceConfiguration.Local.cscfg:
<Setting name="Microsoft.WindowsAzure.Plugins.Caching.ConfigStoreConnectionString" value="UseDevelopmentStorage=true" />
Previously this connection string had been pointing to a cloud storage connection.
In my experience this can happen if one of your roles does not stop when OnStop() is called. Look for WaWorkerHost.exe (I think). You might also try killing IisConfigurator.exe (or something like that). You know you've got the right process when your task manager list gets dramatically shorter :-)
I encountered the same issue and found the following steps resolved it (I stumbled across this solution when applying the answer from #RobPotter above).
First, opene the ServiceDefinition.csdef file and added this entry:
<Import moduleName="Diagnostics" />
To the: ServiceDefinition / WebRole / Imports node.
Second, add the following diagnostics configuration setting to the necessary .cscfg files:
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
under: ServiceConfiguration / Role / ConfigurationSettings for the web role.
FYI. My Service Definition value for schemaVersion is "2012-10.1.8". The issue may have arisen when I migrated my solution from SDK 1.7 to 1.8
I can't solve the problem after followed all the solutions above.
Finally, I decided not to let it stop my coding any more, just changed the StartUp Project from the 'Cloud Project' to the 'WebRole Project', and F5, ... OK website runs properly on my IIS Express.
So, I think, if it can publish to Azure, and can debug website local, so just let it work in this way, until Microsoft make it easier to use.
(my AzureSDK is 2.0)
Similar to answers above. I was running a startup script and it was running appcmd.exe, however, due to a mistake, the section I was trying to unlock caused an error, which made the roles fail to start.
I had used:
%windir%\System32\inetsrv\appcmd.exe unlock config /section:system.webServer/security
but this is an error and should have been
%windir%\System32\inetsrv\appcmd.exe unlock config /section:system.webServer/security/access
For me, this only happened when I had the checkbox for "Enable Caching" selected. And for me, the problem was that I was running my project off of a UNC Share (actually its running in a VM on my macbook). When I'd start the debugger after checking the "Enable Caching" box on the worker role, it would just hang. Come to find out, about every 2 seconds it was creating a 160MB dump file in C:\Windows\System32\%LOCALAPPDATA%\CrashDumps. After debugging one of those, I could see the first error was when it tried to start cmd.exe on the caching stuff in my worker role and it said CMD cannot be run on a network share, so it would default to windows/system32 or something.
That's when I found this handy dandy 7 year old MS KB article: http://support.microsoft.com/kb/156276 When I added DisableUNCCheck REG_DWORD and set the value to 0 x 1 (Hex) under the registry path HKEY_CURRENT_USER\Software\Microsoft\Command Processor everything started up just like a champ. Hopefully this helps someone else.
I have faced the same issue and spent lots of hours including checking all of the rest answers of this post. I just delete my application under the roles and again add webrole project in current solution. And working fine for me.
I had similar issue. I was executing an .cmd file to register a dependent DLL during the start of the debug session. The .CSDEF file looks like:
<ServiceDefinition name="WorkerRole.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
<WorkerRole name="SampleWorkerRole" vmsize="Small">
<Startup>
<Task commandLine="register.cmd" executionContext="elevated" taskType="simple" />
</Startup>
</WorkerRole>
</ServiceDefinition>
After starting the Visual Studio using "Run as Administrator" option, this issue did not occur. i was able to debug the application as usual.
My environment is:
Windows Service 2012 R2 + VS 2013 Update 3 + Azure Tools 2.2
Uninstall Windows update KB3126593 works for me!!!

RoleManager.WriteToLog in Azure Development Fabric

I'm just taking my first steps with Azure and the first thing I see in the development fabric is a bunch of console style logging windows. So I figure that's going to be handy and decide to figure out how to write stuff there and stumble upon this:
Microsoft.ServiceHosting.ServiceRuntime.RoleManager.WriteToLog("Information", "Message);
Cool, except I don't see anything in the log. Saw a post somewhere that after first install you need to reboot before this will work, so I tried that but still nothing.
I've checked with a break point that the code is executing and I've checked the logging level in the dev fabric.
Is this supposed to work, or am I completely off base?
Just to add some more information about what I'm doing:
Started with VS08's new project wizard for Cloud Service
In the wizard added a single ASP.NET Web Role project
In the Page_Load method in Default.aspx.cs I added the WriteToLog line shown above
Ran the project and in the dev fabric UI, drilled down the tree to web role instance "0"
Nothing in the displayed log except some role instance start up messages followed by a bunch of health status messages.
Tried reloading the page a few times, the breakpoint in Page_Load gets hit but nothing in the log.
Logging Level is set to information, and the other events are level information so I don't think it's a logging level issue.
Logging level is the common gotcha, but there's also a delay before logs start showing up in the dev fabric, so make sure that this message is getting logged at least 10 seconds after the application starts.
After some more googling, seems like this is a known issue:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=481184

Resources