I'm trying to run a profiling session following the instructions, but I'm stuck on the first step where it says to pick a profiling configuration as they are all disabled with the error message "This profiling configuration does not apply to the selected run configuration".
What does this mean? What might cause it? And how might I resolve it?
Linux Mint 19, Rider 2020.1.3 installed via jetbrains toolbox, dotnet core installed via asdf-vm.
It's not a real problem, just a UI bug I think.
In toolbar, the profiling configuration drop-down menu is also a button to run the current Run/Debug Configuration. If you set the Run/Debug Configuration to a normal .NET Static Method (often Main function), the profiling configuration button is enabled again. Click it will run the Main function and profiling it normally.
But you can't use this button to profile a unit test session.
Instead, this setting is automatically applied when you click Profile selected unit test:
Just select the config you want, start the unit test, it will work.
This logic is more clear in menu. In the Run menu, third item Profile XXX Using YYY has a same icon with profiling configuration. Hover the profiling configuration button will show a tooltip contains a message equals the menu item.
And you can't run a unit test in Run menu, there is a Tests menu instead.
One more thing: Rider profiling support in Linux is incomplete, I recommend you do profiling things in Windows.
Related
I'm trying to get started with microsoft's azure sphere development.
When I try to debug any of the starter projects within vs code, it tells me that I have a breakpoint set on the first line of the app.
However, vs code doesn't show any breakpoints in the "Breakpoints" tab.
I am running the latest VS code version (1.44) with the Azure Sphere Extension 20.1 on windows 10. The same problem appears on Linux.
To reproduce the bug:
Download the starter projects from github
Install the Azure sphere extension for visual studio code.
open HelloWorld_HighLevelApp folder in azure-sphere-samples\Samples\HelloWorld\HelloWorld_HighLevelApp in visual studio code.
Go to the Debug tab and hit the green play button on top left corner. Next to the button it should say Launch for Azure Sphere High-Level Applications (gdb)
For me it doesn't an error but the output console shows:
Deploying image...
Starting debugger....
Process /mnt/apps/1689d8b2-c835-2e27-27ad-e894d6d15fa9/bin/app created; pid = 2233
Listening on port 2345
Remote debugging from host 192.168.35.1, port 54911
Starting CMake Hello World application...
The Debug Console shows:
...
Breakpoint 1, main () at ../../main.c:45
45 {
Loaded 'target:/usr/lib/libapplibs.so.0'. Symbols loaded.
Loaded 'target:/lib/libgcc_s.so.1'. Symbols loaded.
Loaded 'target:/usr/lib/libc++runtime.so.1'. Symbols loaded.
Is there a work around / a plan to fix the issue?
Addition 1:
To provide extra clarification here is a screenshot, showing the miss match of console output (breakpoint set) and ui (no breakpoint set)
Azure Sphere uses gdbserver to provide a debug channel to the device. A default behavior of gdb is to break on entering main. This can be confusing to people on Windows who expect a run to breakpoint behavior as is common in Visual Studio. For our interface with GDB we intentionally silently skip the breakpoint on entering main in Visual Studio to be consistent. You can actually see that breakpoint skipped in the debug log output window.
For VS Code we also skip the breakpoint on main when you are on Windows. It looks like you are on Linux from the output above. I haven't used it on Linux for a few weeks so can't recall if the behavior is intentionally different there or not. It would make sense to me to break on entering to main when on Linux as that is the common expectation when using GDB which is more common there than on Windows. I'll check if this is by design or not and reply back, but I suspect it is.
Solution:
Finally I found the root cause of the issue. Visual studio code acts just slightly different when debugging the sphere device compared to just plain c code.
When you start the debugging mode and you haven't set a breakpoint initially, it won't start running your program till you have set a breakpoint. In plain c debugging the program just runs through and printed values are shown in the debug console.
I'm learning Flutter and using Android Studio as my IDE and i've hit some pain points around Integration Testing.
As part of the learning process i have written a basic Integration Test.
The intention with this integration test is to examine an Image widget (created via Image.Asset) to see if the image source, which is dynamically generated, is the expected value, or that an image is being displayed.
I run the integration test using the Terminal tab in the IDE, e.g: flutter drive --target=my_app/test_driver/user_list_scrolling.dart
I want to add a breakpoint to my Integration Test method and step through it from within Android Studio to help aid my learning of the testing functions.
My questions are:
How can i debug an integration test from within Android Studio? - As I'm learning i would love to put a breakpoint in my integration test and play around with the Finders in the immediate window. However, when i start my integration test from the terminal my Breakpoints seem to be ignored, i also tried adding the Debugger(); command. Execution paused, but i was unable to step through my code in Android Studio. I've also tried using the 'Attach to process' option in the IDE but the 'Choose process' list is empty.
Can i execute an integration test from within Android Studio without having to manually enter a command into a terminal? - i would rather click a button than memorise a command. Right-clicking my integration test file and selecting run does not appear to work.
How can i effectively test an Image widget from within an Integration Test? - The image source is set by calling Image.Asset() with a calculated value as the first argument, so i want to confirm that an image is displayed / the argument is the expected value. I'm guessing i need to use find.byType("Image") and somehow examine the result for the source value?
The following are the steps I took to set-up for integration test development using Flutter tooling, including debugging:
Configure the app to listen on a shared port (in this case 8888)
Add ‘— observatory-port 8888’ to ‘Additional Arguments’
Configure integration test to connect on the same shared port
Add ‘VM_SERVICE_URL=http://127.0.0.1:8888/’ to ‘Environment Variables’
Start the app in run or debug-mode (only required once, with hot-reload when needed):
Start the integration test in run or debug mode (as many times as you want):
You can now add breakpoints to the app and/or test and view source code and variables in debugger.
The following describes how to setup Android Studio to develop integration tests in more detail.
A how-to for fast integration test development with existing tooling
For some reason in Android Studio the icon to run in debug mode doesn't work with configurations scoped to entire directories. Create a configuration targeting one file, or simply click the "Run Test" icon in the gutter next to your main() function and select the "Debug" option.
With the new integration_test package you can just run flutter run integartion_test/app_test.dart to debug your tests.
My launch.json (I'm using VS Code):
{
"version": "0.2.0",
"configurations": [
{
"name": "Integration Test",
"request": "launch",
"type": "dart",
"program": "example/integration_test/app_test.dart",
},
]
}
You can run then the integration test from the AndroidStudio as you would run any other Flutter app (right-click on the file, run -> debug).
Sometimes the AndroidStudio identifies the file as Dart and not Flutter, so you have to create a new Run/Debug configuration for Flutter instead. At "Dart entrypoint", select the integration file with the "main" func.
I develop Excel tab-pane addin(office.js api) and use F12Chooser tool for debugging.
After upgrade Windows 10 to build 14342.1001 I can't run F12Chooser.exe from:
C:\Windows\SysWOW64\F12\F12Chooser.exe and C:\Windows\System32\F12\F12Chooser.exe
After double-click the mouse cursor quickly flashes and nothing happened. When try run from context menu in Excel web view still nothing happened.
(This is an old post so replying in case anyone else finds it usefull.)
You can file a bug/feedback on F12Chooser in the Feedback Hub (search for it in start). If you place it in the Microsoft Edge -> Developer Tools category it should get routed to the right people.
As a workaround if you have Visual Studio 2017 installed you can use that to attach the script debugger to any process from the attach to process menu (changing the debug engine to script). VS2017 has the same tools as F12 (e.g. the DOM Explorer and Console etc.).
We use VS Ultimate for web tests and load tests, but since moving to VS 2012 from VS 2010, the web tests don't seem to run anymore. We used to be able to do ctrl-r ctrl-t to debug specific tests, but that doesn't work anymore. I then found out about the issue with running tests in context, so I just tried running all tests, but that didn't work either. VS2012 is acting like it doesn't see WebTest as real tests anymore.
Even when I try to view the tests in the test explorer, nothing shows up. I know my tests are correct because I can go back in to VS 2010, and everything still works like it should.
Is anyone else having this issue?
Visual Studio 2012 dropped the "Test View" window that we used to use to run tests in VS 2010. The new "Test Explorer" window only recognizes Unit Tests and Coded UI Tests, as you've discovered. This totally threw me off too.
To run web and load tests (besides the obvious but tedious method of actually opening them and clicking "Run" in the editor window) you have to select the tests you want to run in the Solution Explorer, then Load Test (menu) > Run > Selected Test. Or alternatively "All Tests in Solution".
You also have the option of running the individual Web Tests that are contained in any open Load Test. Right-click on the Test Mix node (in Scenario) or any of the tests in the Test Mix.
For completeness here is the authoritative source: http://msdn.microsoft.com/en-us/library/ms182541.aspx
By the way, here is another gotcha: although you still choose testsettings for a Load Test from the Load Test menu, you now set the testsettings for Web Test execution separately, under the Test menu:
I'm trying to use EQATEC Profiler to profile my ASP.Net app. I am following the below steps to do it. I have selected the application's bin folder in App path and clicked on the build button. Then I have run the application from visual studio 2005. However, i don't see the reset counter or take snapshot buttons enabled. Please help.
You'll find a nice step-by-step instruction and explanation in this thread.
I may also have an explanation of what's going wrong for you:
You compile your asp.net app in VS2005 - fine
You then instrument and overwrite your app using Build in the profiler - also fine
But then you run your app from VS2005 and that may re-compile your app again so you're running an un-instrumented version. Instead of running it from VS2005 you should simply have IIS "launch" the code by navigating to the corresponding webpage.
If this is not the problem then take a look at the log-file generated by the running, profiled app. By default the log-file is located in C:\Windows\Temp\EQATECProfilerLogs\profiler.log.