I have an Azure solution that I want to debug in Visual Studio 2010. I have two MVC sites set up as Virtual Applications in a single Web Role - this structure makes sense from a cost and url standpoint. The virtual applications worker processes don't spin up automatically and therefor VS doesn't attach to it. After hitting the virtual applicaiton url (i.e. localhost/app1) in the browser, a new w3p process starts and I can manually attach to it. Just wondering if someone out there has done this before and has a tip on how to automatically attach to the process.
Related post that makes it sound like you have to do it manually: http://social.msdn.microsoft.com/Forums/uk/windowsazuredevelopment/thread/f1c5d72b-9196-480e-ace6-3c9063be79a7
This isn't Azure specific, but you could trigger a breakpoint when your application starts:
protected void Application_Start()
{
#if DEBUG
System.Diagnostics.Debugger.Break();
#endif
...
}
And you could try to combine this with a startup task only running when you are in the emulator and that hits the url of both web applications (using wget.exe for example). This will create the w3wp process, triggering the Debugger.Break.
Resource: http://blog.smarx.com/posts/skipping-windows-azure-startup-tasks-when-running-in-the-emulator
For working on multi-site roles, at development time, I have a separate Cloud project for each site, and use a combined one for deployment purposes only. It's not ideal, but it is easier than the whole manual-attach thing.
(For history fans, this practice originally started before the SDK added support for Local and Cloud configuration files. We used to have a Local project and a Cloud project, because otherwise we kept forgetting to switch the connection strings before deploying.)
Related
I have a .NET5 solution that is made up of several applications that communicate with each other using named pipes. In particular, there is a central service application (implemented using BackgroundService from Microsoft.Extensions.Hosting) and also an "Agent" that is responsible for launching the main service if it isn't running already, monitoring its status and relaying user commands to it. There are also a number of class libraries shared between the applications.
I've already configured the projects in the solution so they all build to the same output directory and I've set <UseCommonOutputDirectory>true</UseCommonOutputDirectory>.
After I launch the Agent in the debugger, it launches the service.exe using Process.Start() (it is not a Windows service). I can then (manually) attach to that process to debug it, too.
However, I'm wondering if this experience could be made smoother somehow:
Is there a way to set this up so the debugger would automatically attach to the child-process when it launches rather than me having to do it manually?
Is there a way to tell VS that it should also automatically rebuild the service and its dependencies when I launch the agent with F5? I keep forgetting this after making changes to the service...
I am aware that I can set up multiple startup projects so they all launch in the debugger simultaneously and that works for some debugging scenarios but I'm currently looking at a case where I really need the service to be launched by the agent and not separately before.
There is a web.api application with Application Insights plugged in. The AI works like a charm when it is published to Azure. Unfortunately sometimes it is necessary to launch the app in iis express for test purposes. Normally I do it from cmd like this: "c:\program files\iis express\iisexpress" /port:1337 /path:c:\tracker_pub.
Is it possible to watch AI statistics in such a case? In particular I would like to see exceptions that happen sometimes.
Please read this. You can use LinqPad to get all internal telemetry live. Also if you have VS 2015 Update 1 there is an Application Insights hub where you can find AI telemetry (same as in the VS output). You can read about it here. And also this.
Yes, as long as your application is receiving requests and your local machine has internet connection, so it can send events to AI data collection endpoint it should be recording activity when running in iis express. The recommended approach is to send this data to a different instrumentation key (after creating a new AI resource in AI portal), so that your local test traffic is not mixed up with your production data, this is also a great way to test new custom events you are about to add. If you are not seeing any data when running in iis express, the best way to debug would be to start your application in Visual Studio with F5, you will see every event that is about to be sent in your debug output window.
I've got a very simple ASP.NET MVC-3 application that I'm trying to push to Azure for the first time. Using Intellitrace, the default settings seem to take forever to pull the trace back down to the IDE.
I'm wondering if anyone knows the optimal Intellitrace settings to use to debug the initial application startup, which is still failing, without having to wait for so long to get the trace?
Depending on the problem, the default settings should capture it. They only time they wouldn't would be if the problem was outside of your code. For instance if Azure had an issue with starting your instance. But if the problem is in your OnStart or Startup scripts, IntelliTrace should capture it just fine by default.
I am trying to start up a web role on Windows Azure, but it initializes, goes to busy/stop and continues the endless loop of busy then stop. I have followed the recommendations of this question : Windows Azure Deployment but still no joy. Of course the application runs nicely in the development fabric when I debug
I have done these things so far:
Turned off the diagnostics to ensure azure storage is not used
Made sure that copylocal=true is set for each no microsoft assembly.
Added the Microsoft.WindowsAzure.* references that the sample web role adds
Did a test run of the basic MVC role and that works.
Did a dependency analysis to make sure I am explicity referencing all assemblies using this tool Dependency Visualizer and that they are in the package for deployment. no joy.
Is there a startup log that azure keeps that I can access or similar facility so that I can learn what is failing?
Do you have access to Intellitrace? If you turn that on (VS Ultimate SKU), you can easily download the logs and see why the role is failing to start. Windows Azure Diagnostics is almost certainly not the issue anymore. Back before SDK 1.3, it used to run in the same process as your RoleEntryPoint, which meant you a.) could crash your role if it crashed and b.) if your role crashed, it killed the monitor which made it useless for collecting information. However, the Diagnostics Monitor is now deployed as background task that runs outside of your RoleEntryPoint and it can no longer crash your role. If you turn on Crash Dump collections and Tracing and you should be able to pick those up. In theory your Crash Dump should have the stack trace.
I'm really loosing it here. Not being able to attach a debugger to a process is kind of a big deal for me. As such, I'm having a very hard time doing something to pinpoint the source of problems with an Azure-hosted application.
What's worse is that the app works fine in the Development Fabric, even when using online Storage Tables, but can go quite haywire when uploaded and running online.
I know IntelliTrace is one way to do it, but unfortunately, I've got a x86 machine, and the application uses RIA Services. As such, publishing it from my machine results in an error caused by RIA services. I can't build the application by specifying x64 the very same bug strikes again. (So far the only way that I know of to deploy a RIA Services Azure application is to set it to Any CPU and build / publish it from an x64 machine).
So IntelliTrace is not available. Online Azure doesn't have something to resemble the nice console log window of the Development Fabric, and as such, I'm at a loss. Thus far I've been just trying to get things to work and not crash by commenting out sections of code, but given the time it takes to upload and start an instance, this is hardly optimal.
Any suggestions would be appreciated at this point.
The Azure SDK has a logging / diagnostics mechanism built in:
http://msdn.microsoft.com/en-us/library/gg433120.aspx.
One route would be to deploy a version with some Azure specific instrumentation built in.
You could try to RDP into an instance of the role and see if there's anything in any of the logs (event or files) that helps you identify where the failure is.
Baring that, I think Amasuriel has it right in that you REALLY need to architect instrumentation into your solutions. Its something that's on my "must" list when building a Windows Azure application.
If you have access to another workstation with an x64 version of Visual Studio, you can configure Azure diagnostics to collect and copy the crash dumps to Blob Storage:
// Must be called after diagnostic monitor starts.
CrashDumps.EnableCollection(false);
You can then download them (using a tool like Azure Storage Explorer) and debug them locally.
If you absolutely need to see what's going on on the console Rob Blackwell has embedded a neat little trick in his Azure Run Me solution.
It pushes the console output of azure instance(s) out over the service bus. You can therefore consume that data locally and in effect monitor the console of the instances running on Azure right on your desktop.
AzureRunMe is available here and it's open source so you can take a look at how they've fed the console output to the SB.
https://github.com/RobBlackwell/AzureRunMe