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
Related
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.
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 a webAPI deployed on window azure, till last week I was able to run the WebAPI and debug but all of a sudden when I run the web application I get the below message.
Role instances are taking longer than expected to start. Do you want
to continue waiting?
And I tried to enable disable caching(default caching is disable) and also cleared the local storage but still the same issue persist, its happening in not only my machine but also on other dev machine as well. Could it be because of automatic software updates related to emulator or other SW or any other issue?
Happened withh me today. I ran into an issue of the Azure emulator not working. The roles were going in a continuous loop of Running, Busy and Suspended.
Initially I thought it might be due to some code I had changed ď. However, it turned out that a recent Windows update had caused this issue.
After spending a frustrating amount of time un-installing the recent updates one by one, I found the miscreant.
For Fix please un-install the Security Update KB3126593 (https://support.microsoft.com/en-us/kb/3126593).
While searching for the particular update, make sure you type âKB3126593â in the search bar. Typing 3126593 will not work.
I've just started working with AWS CodeDeploy.
My first few deployments have failed, which is fine. With new tools comes new learning, and I expected to have to iterate a bit initially. Each of my first few deployments has failed in a useful way.
In the AWS Console I see something like this:
Here I can see some useful details. I can click the View Events link to see even more details, and from there I can view logs on the target EC2 instance.
In contrast, my most recent failed deployment shows this:
As you can see, this is missing much of the detail from the previous screenshot. The missing View Events link is particularly unfortunate. It might be significant that this deployment took longer to fail, but not long enough that one of my hook scripts might have reached its timeout.
Re-deploying resulted in the same thing.
How should I go about troubleshooting this?
After trying this one more time while keeping an eye on /var/log/aws/codedeploy-agent/codedeploy-agent.log I realized that there was no new log activity being generated.
Restarting the agent with sudo /etc/init.d/codedeploy-agent restart and deploying again generated the output I expected.
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.