Debugger does not recognize variable for return value of awaited method - microsoft-metro

I have this very simple code in portable class library targeted to .NET 4.5 and Windows Store Apps:
HttpResponseMessage response = await _httpClient.PostAsync(uri, content);
response.EnsureSuccessStatusCode();
When I put breakpoint on the second line and run my application the breakpoint is correctly hit but I cannot investigate response in the debugger because it reports:
The name 'response' does not exist in the current context
I'm not sure how much is it related but I also had to disable Just My Code debugger setting in Debugger's settings to be able to debug my portable class library placed in the same solution as the executing application.
Is it some limitation of async-await methods, portable class libraries, targeted applications (Windows Store App particularly) or combination of those tools? Or is it a debugger bug? Any workaround would be more than helpful.

I'm not sure if this still happens with newer Visual Studio updates (I don't have that code base anymore) but the problem in my case was probably combining Async-Await debugging with code contracts. I haven't seen the problem when not using code contracts.

Related

No application has connected to the REPL server

I am trying to evaluate some Clojure forms in VS Code using the Calva REPL.
When I run any of these commands, I get the error:
No application has connected to the REPL server. Make sure your JS environment has loaded your compiled ClojureScript code.
It doesn't seem to let me switch namespaces.
By the comments to the question I am assuming this is a browser project. And by the error message, that it is shadow-cljs.
With shadow-cljs Calva opens up the REPL window a bit prematurely, because we still lack a reliable way to ensure the connection to the ClojureScript application. Once you have the prompt, like you have there (embarrassingly undefined), try reloading the web page with the application. You should be able to evaluate something then, and the prompt should get something less undefined.
I can recommend joining the #calva channel on the Clojurians Slack, for faster help.

How to launch vscode debug configuration from the browser?

I have a test case reporting scheme delivered in HTML that is complex in its own right and not easily ported to a VSCode extension. I would like to launch a Debug Configuration for each failing test case from the browser displaying the report. I have already been able to modify the report and have added a copy/paste widget for each test case's associated command. However I would like to do something to the effect of:
Launch a service as a VSCode extension that can handle requests
Formulate those requests in a way that can dynamically create launch configurations
It may be that I am stuck writing a Debug Adapter without the bells and whistles of interacting with the report.
That being said, if this is a solved problem or has a framework for solving with VSCode (and I realize remote execution could be a Very Bad Thing for VSCode to allow), I have not been able to find it through an existing extension.
I welcome your ideas.
This is perhaps not as open ended as it sounds...my question ultimately is: can VSCode operate as a service to be requested by web interfaces? Even if it could be done via Localhost this would be a boon. If it can be done over ssh with authentication, that would also be a bonus.
One way of getting VSCode to handle requests would be by invoking a vscode:// URI. This requires your extension to implement a URI handler. After the mandatory parts of the URI, you could have arbitrary data with whatever information you need.
Something that might or might not be an issue for your use case is that invoking such a URI triggers a popup in VSCode / doesn't work silently:
For dynamically creating launch configurations, you can use the vscode.debug.startDebugging() API.

Debugger break command in VS Code?

In Visual Studio (C#) there is a command
System.Diagnostics.Debugger.Break();
that lets you automatically hop into the debugger even without setting a breakpoint. Is there such a thing for VS Code? I'd especially like it for rust. I tried just writing "let x = 1/0" but that just crashes the program.
I'm using the cppvsdbg debugger for windows.
Looking through what David Cullen suggested in the comments leads to a few options:
std::intrinsics::breakpoint This needs nightly rust.
The breakpoint crate This doesn't even compile but it would have been nice.
The WinApi this is rather OS specific but it works for my case. The OS dependency can at least probably be mitigated using conditional compilation. To use the library, add:
[dependencies.winapi]
version = "0.3.7"
features = ["debugapi"]
to Cargo.toml and call it using
unsafe {
winapi::um::debugapi::DebugBreak();
}
However it turns out that even this approach doesn't work across crates, it just crashes.

Aurelia/Babel 6 sourcemaps shown as html

I have an aurelia application updated to the latest beta, 1.0.0-beta.1.2.1 at the time of this writing. This version of aurelia already uses Babel 6, and my application is based on the based on the ASP.NET 5 ES2016 navigation skeleton.
"All of a sudden", whenever I try to open my untranspiled javascript source files in Chrome (Version 49.0.2623.110 m (64-bit)) Developer tools, for instance main.js, all I get to see is the html of Index.cshtml.
It doesn't matter which javascript file I try to open, it always shows the html of Index.cshtml instead of javascript.
The transpiled files are displayed correctly in Chrome Dev Tools.
I've had this before but it usually meant I had a binding or templating error somewhere, but in this case the application works perfectly, so it probably has to do with the sourcemaps... Or does it?
My questions are:
What is the best way to track down a subtle binding or templating
error in Aurelia? Everything I've tried to do in my applcation works
fine, but I don't want to rule out this being my own fault just yet.
In case it's not my fault, has anybody come across this before? What
is the reason the sourcemaps are not working; is it Aurelia? is it
Babel 6? Is it Chrome?
Update
It doesn't seem to be a Chrome issue; the same problem occurs in Edge.
Update 2
By turning off Enable javascript sourcemaps on Chrome Developer Tools I can debug de transpiled code.
The transpilation gulp tasks I'm using are copy/pasted from the version mentioned above.
Has anybody else come across this issue?
Ok, I think I've found the problem.
I changed includeContent to true for sourcemaps.write in the build-system gulp task defined in build\tasks\build.js, so that line 23 of that file looks as follows:
.pipe(sourcemaps.write({ includeContent: true}))
This comes set to false in the navigation skeleton, so more people should have this same issue. Anyhow, this seems to have solved the problem.
I also removed the sourceRoot: "/src" parameter in that call, as it is only necessary when includeContent is false.

J2ME: Prefetch error -5. MediaException

I get a MediaException (Prefetch error: -5) when executing the following code on a Nokia N73. It runs fine in the emulator and I have tried the same thing before on the same phone successfully. The only difference now is that I am using NetBeans to build and deploy rather than Eclipse.
inputPlayer = Manager.createPlayer("capture://audio?encoding=pcm&rate=4000&bits=16&channels=1");
inputPlayer.realize();
inputPlayer.prefetch();
inputPlayer.start();
I am wondering whether it is security related, as with Eclipse I always got a security prompt on the phone. With NetBeans I do not get any prompt, just the Exception.
-5 is Symbian error code KErrNotSupported.
The N73 is based on Symbian OS v9.1
Native (from Symbian C++) error codes are sometimes propagated into Java exceptions when the JSR-135 implementation couldn't find a nicer way to express the error.
Make sure that you do not have any other player references held. That is, you are not attempting to prefetch the second player object, while the first one is not yet released/closed. Also, esp on the Nokia, try releasing it on a separate thread, as closing/releasing the player on the same thread is know to cause some problems. Same with creating too.