oday we are releasing our first experimental preview of debugging for the new ASP.NET Core CLI toolset in Visual Studio Code. Before I continue it’s important to note a few things:
This support is for the new prerelease .NET Core CLI toolset; it does not work for the existing DNX experience (see the ASP.NET teams Q&A blog post to understand the changes).
VS Code’s IntelliSense does not yet work with the .NET CLI tools. So if you want to try out debugging, IntelliSense won’t be available for the CLI project type.
With this first release you get breakpoints, stepping, variable inspection, and call stacks.
vsc
However, given the very early stage of .NET Core and the debugging experience there will be some features you might be used to in the Visual Studio IDE that we don’t have in VS Code yet. These include:
No separate console window is created when you start debugging, all program output appears in the Debug Console of VS Code. This means that to use Console.ReadLine in a console application during debugging you have to start the application with dotnet run outside of VS Code and then attach the debugger.
No Edit & Continue (the ability to modify code and have the changes applied while debugging)
Cannot edit the value of variables during debugging
No TracePoints or Conditional breakpoints
Set Next Statement is not supported
We are very interested in your feedback to help us prioritize addressing these as covered at the end of this post.
Getting started
To get started you will need to do a few things (see our GitHub page for complete instructions)
Install (or upgrade to) Visual Studio Code version 0.10.10 or greater
Install the .NET CLI tools
Install the C# extension
Open any .cs file in VS Code to load the extension and complete the installation (view progress in the Output pane)
Install mono
Things you get while debugging
Breakpoints – set breakpoints with one click (or via F9)from the editor
Watches – define expressions that you want to keep an eye on
Locals – see the value of local variables automatically
Call Stack – find information on method calls on the stack
Debug Console – shows you all debug messages (show and hide this pane using Ctrl+Shift+Y or Cmd+Shift+Y on a Mac)
Current values – hover over variables to see the value
All panes show coordinated values – whenever you click an entry in the Call Stack you automatically jump to the corresponding line in the editor and watches and locals are updated
What else can you configure for debugging?
Once you install and configure the extension you will have the basic debugging experience describe above, but there is much more you can configure using the launch.json file.
Stop at Entry
Setting the stopAtEntry flag will cause the debugger to break immediately on the entry point to the application. This allows you to start stepping through your code without setting breakpoints.
Configure debugging for ASP.NET applications
Besides the default debug configuration there’s a configuration called .NET Core Launch (web) which is a good starting point for debugging ASP.NET applications. It contains an additional section “launchBrowser” that is used to open up a WebBrowser on your development machine whenever you start debugging. Per default it is configured to use the default browser but you can specify alternative browsers if you modify the commands in file accordingly. To get started and to give ASP.NET a try just download the ASP.NET CLI samples from Github .
Here’s what a configuration of launch.json would look like if you configure it to open a page with Opera.
…
"osx": {
"command" : "open",
"args" : "-a opera ${auto-detect-url}"
}
…
Modify launch URL
The URL the browser navigates to is configurable as well. If you stick to the defaults the debugger figures out the URL automatically and targets to the default URL the server listens to. ${auto-detect-url} serves as placeholder to find the URL automatically and you can use it anywhere in the configuration. For a scenario where you’d like to always debug a certain URL path like http://localhost:5000/api/customers/42 , you can overwrite the default value to avoid the manual navigation process.
Attach scenarios
For attach scenarios a third configuration section is integrated. All you have to do here is specify the process name of the application you want to debug. In our case this would be HelloWorld. If you spin up your application from the command line with dotnet run make sure you select the .NET Core Attach configuration first before starting the debugger.
If you have multiple processes running with the same name you can also specify processId instead of the processName. Just make sure you don’t use both properties at the same time.
top
processid
Hidden configuration properties
There are currently three additional properties that don’t show up in the default configuration. If you wonder how to figure out those properties aside from reading the documentation, here’s a tip: Start typing “o in launch.json (make sure you also type the leading quotation mark) and you’ll get an auto-completion that shows you a list of properties containing an “o”.
typeo
While this is very handy when you’re already editing, you might want always up to date documentation. As always the truth is in the code, and if you want to dig a little deeper you can take a look at the installation folder of the extension where you will find a file called package.json . Consider this file as the master template for valid configurations. It gives you a very good overview about configurations possible on your machine for your current version of the extension in easy to understand and human-readable json.
pathtopackagejson
json
symbolPath
You can use “symbolPath” to specify an array of paths to your debugging symbols. This can be very helpful if your symbols are located on a central server and when you are working across multiple operating systems. Symbols generated on one specific operation system also work cross platform.
A valid configuration of the symbol path is shown below.
“symbolPath”:”[ \”/Volumes/symbols\” , \”/OtherVolume/otherSymbols\” ]”
justMyCode
When you are in a debug session you might not be interested in stepping into framework code or into code of components you haven’t written. This is the reason why we came up with justMyCode. This feature is enabled per default as it seems to be the preferred setting for most debugging situations. However, if you want to debug framework code or external components you can enable this by setting it explicitly to false.
“justMyCode”:false
sourceFileMap
If you want to point the debugger to the corresponding source files for your debugging session you can specify a mapping table using the sourceFileMap property. This property can have any number of entries and will make sure the debugger works with the source code files you want it to work with. A configuration could look like this.
“sourceFileMap”: {
“C:\foo\bar”:”/home/me/foo/bar”
}
Source: https://blogs.msdn.microsoft.com/visualstudioalm/2016/03/10/experimental-net-core-debugging-in-vs-code/
Showing posts with label News. Show all posts
Showing posts with label News. Show all posts
Saturday, March 12, 2016
Friday, August 28, 2015
C# is the most used programming language at work
C# is making its way past Java as the most popular programming language in the workplace, according to SD Times readers.
While Java sits on top of the TIOBE Programming Community index for August 2015, with C# coming in at No. 4, our latest poll shows C# is the No. 1 language used in the workplace, with Java and C/C++ following.
Out of 1,166 votes, 37% of developers voted for C#, 20% voted for Java, and 17% voted for C/C++. The least-popular programming languages used at work, according to the poll, included Python/Ruby/Perl and Objective-C/Swift.
A more detailed breakdown of the poll results is available below:
Source: http://sdtimes.com/sd-times-blog-c-is-the-most-used-programming-language-at-work/
Friday, August 14, 2015
Hello, Windows 10 IoT Core (Internet Of Things)
We are excited to announce the public release of Windows 10 IoT Core for theRaspberry Pi 2 and the MinnowBoard Max. Visit the Windows IoT Dev Center to choose your target board, then walk through the steps to provision your board, acquire the tools, and get started Making. This release of Windows 10 IoT Core requires a development machine running the 7/29/2015 release of Windows 10 (Build 10240) and Visual Studio 2015.
Introduction to Windows 10 IoT Core
Windows 10 IoT Core is a new edition for Windows targeted towards small, embedded devices that may or may not have screens. For devices with screens, Windows 10 IoT Core does not have a Windows shell experience; instead you can write a Universal Windows app that is the interface and “personality” for your device. IoT core designed to have a low barrier to entry and make it easy to build professional grade devices. It’s designed to work with a variety of open source languages and works well with Visual Studio.
Oh, and you can also use it to build robotic air-hockey tables.
New in this release
The first public preview of Windows 10 IoT Core was released at the //build/ conference, and we’ve made great progress since then. Perhaps most importantly, long-awaited support for Wi-Fi and Bluetooth connectivity has arrived. The full list of new features and improvements is too long to list here but here’s a nice sampling:
- Improved support for Python and Node.js, including a new Express Node.js project template
- GPIO performance on the Raspberry Pi 2 has improved by 8X to 10X
- Analog-to-digital converter (ADC) and pulse-width modulation (PWM) are now supported via breakout boards and ICs
- New Universal Windows Platform (UWP) APIs give apps easy control over system management features like time zone and network connections
Developers, Developers, Developers
The developer experience has been a high priority for our team as we’ve built Windows 10 IoT Core, and we hope this shows when constructing apps for this platform. Our philosophy is that we want to make it easy for developers to use the languages and frameworks they prefer to build IoT device apps. This means full support for the standard UWP languages like C++, C#, JS and VB, but it also means bringing support – including full tools, debugging, and project systems – for Node.js and Python. The project templates for the standard UWP languages create projects that look like standard UWP projects, but for Node.js and Python we’ve worked hard to make these apps look and feel just like they do on other platforms. The code below shows a complete Node.js UWP app that reads from an I2C sensor and serves up a web page with the data (and you can get the sample here).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
| // Copyright (c) Microsoft. All rights reserved.var http = require('http');//Import WinRT into Node.JSvar uwp = require("uwp");uwp.projectNamespace("Windows");var i2cDevice;//Find the device: same code in other project, except in JS instead of C#var aqs = Windows.Devices.I2c.I2cDevice.getDeviceSelector("I2C1");Windows.Devices.Enumeration.DeviceInformation.findAllAsync(aqs, null).done(function (dis) { Windows.Devices.I2c.I2cDevice.fromIdAsync(dis[0].id, new Windows.Devices.I2c.I2cConnectionSettings(0x40)).done(function (device) { i2cDevice = device; });});http.createServer(function (req, res) { res.writeHead(200, { 'Content-Type': 'text/plain' }); var output = ""; var humidity = 0; //Read the humidity from the sensor var command = new Array(1); command[0] = 0xE5; var data = new Array(2); i2cDevice.writeRead(command, data); var rawhumidityReading = data[0] << 8 | data[1]; var ratio = rawhumidityReading / 65536.0; humidity = -6 + (125 * ratio); //Read the temperature from the sensor var tempCommand = new Array(1); command[0] = 0xE3; var tempData = new Array(2); i2cDevice.writeRead(command, data); var rawTempReading = data[0] << 8 | data[1]; var tempRatio = rawTempReading / 65536.0; var temperature = (-46.85 + (175.72 * tempRatio)) * 9 / 5 + 32; output = "Humidity: " + humidity + ", Temperature: " + temperature; res.end(output);}).listen(1337); |
A small note about VS RC->RTM project system compatibility:
There were a variety of breaking changes in the VS project system between the //build/ and RC and RTM. For the most part, application code will remain functional, but the project itself will need to be rebuilt. The recommendation from the Visual Studio team is to build a new project and move the code over into the new project shell.
Built to work with the tools & languages you want to use – whatever they are
As part of our engagement with the broader community, we’ve worked with the community to support as many open source options as we can. You can find all of our IoT samples on Github, as well as documentation and a growing set of libraries and helper tools. Even our project system and runtime support for Python and Node.js is available open source on Github.
When our samples start turning into full projects, you can find them onHackster.io.
We’ve also worked with our friends at Arduino to make it very easy to talk to Arduino boards from Windows and even for Arduinos to talk to Windows devices as if they were virtual shields. See this project for more information.
IoT Projects for fun and profit
We built IoT Core and the corresponding developer tools to make it easy to build projects that are fun and cool, as well as those that have very practical uses in the real world. Find evidence of this in the range of projects, from members of our team, as well as the community, that have been created in the months since our first public builds.
Sampling of Hackster.IO projects:
- From IoT team members
- Rover Robot Kit – Make and program your own robot using a Raspberry Pi 2 running Windows 10 IoT Core
- Windows Remote Arduino- using an Arduino from a Windows Phone app to control an LED
- Home Automation with the RPI2
- From the community
- Cooling off in the Summer: Handheld fan control from an RPI2
- Even more robots : GoPiGo
We have more projects in the pipeline, so keep your eyes on our hackster.io hub for more information about our Air Hockey Table, Face Recognition Unlocked Door, and more.
We are listening
While you’re playing around, if you notice some rough edges, please let us know. As always, we appreciate your feedback, so keep it coming and we’ll do our best to address issues.
Quick links
- Release Notes : Details about what is covered in this release of Windows 10 IoT Core.
- Download Now : Click here to start downloading for FREE now. You will need the latest version of Windows 10, Visual Studio 2015 and tools.
- Community : Share your feedback here and engage with other Makers using our forums.
Subscribe to:
Posts (Atom)