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.
Related
So where can one find the local logs for when debugging a Azure Function locally with Visual Studio 2019?
Relevent documentation:
https://learn.microsoft.com/en-us/azure/azure-functions/streaming-logs
The Azure Function documentation only explains this for VS Code, but for this project I need VS 2019, and they are not where I would expect to find them (in the Output window under the Debug dropdown).
They can be seen on the deployed function fine in the Streaming logs, so they are getting created, but for development speed I need them locally too.
I have been looking and googling for a day or two now, so I am reluctantly resorting to Stack Overflow. They must be there somewhere, right?
The logs should also appear in the console window when you start your project.
Ok, the problem was I was using information level messages and they don't come to the console by default. There were some messages on the console, but I had no idea they were actually log messages, thanks to Justin for putting me on to this.
More googling revealed you need to specify an additional argument on startup to see those messages - in Visual Studio on the Properties dialog for the function app Project - a screenshot of that dialog:
So I have created an xaml flow which clicks browser buttons downloads files and then does some basic operations. I setup a windows server and connected remotely to it and when I debug my process automation while staying on the screen it works smoothly, problem is that I can't keep my pc on forever so when I just minimize the file even though my system remains up and running:
The UI Path process kills as the button press times out. I was just curious to know if it's compulsory to keep screen up for the ui based process automation to run through or is there a way to initiate the process and then close the screen and let the system do its job?
This is the eror I get which is like first UI interaction:
Here are the steps I have performed:
Created an unattended robot with machine as the remote instance name.
Created an environment and connected with the robot created in step 1.
Setup UIPath Assistant using machine key and URL.
Published the files and then created the process in cloud console.
Ran it from cloud console.
The process faults at its first UI interaction. Even though it was running in unattended robot form.
Thanks in advance.
AFAIK this is intended by the licensing model of UiPath. So to solve the issue you need a license for the VM of your RDP connection that allows the unattended usage.
Another idea could be to start the process in the PIP (picture-in-picture) mode. But I have never tested that, so this might also not work.
But maybe you already have a license like that and could test that out.
These are our types:
Solution for UiPath Studio 20.4 or higher
For my Use Case Picture in Picture mode worked correctly. Thanks #kwoxer for the suggestions, though his answer was enough but I am adding it up here for those who may need future reference.
So If you're facing issues with automating user interactions in dynamic JavaScript Website over a cloud server that loads on demand (When you minimize or close your remote session, the process times out as it's not able to find the UI component), here are the simple steps to follow:
Goto Debug options on top and select picture in picture as shown below:
This basically lets the bot start the system from another node. Now when you run the system and even close the remote connection, the automation process including all sorts of UI interaction will work like charm. Please let me know in case someone faces the issues with the same. Would love to help!
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.)
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'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