The Quantum Architecture and Computation group launched Q#, our quantum computing programming language, a year ago on December 11th, 2017.

Q# 0.1 was the result of a lot of hard work from a small, dedicated team of developers, researchers, and program managers. We had made the decision to build a domain-specific language for quantum computing about six months before we launched, so we were on a very tight schedule. We were lucky to have a great team of people who all pitched in and did what needed to be done so that we could meet our extremely aggressive timetable.

Start!

Inside the team, we speculated on what level of interest Q# would attract. We hoped that we might receive a few hundred downloads, but we were blown away when we crossed 1,000 users by about 9 hours after launch. That said, with so many users installing the Quantum Development Kit and trying to write simple programs in it, bugs started popping up. In order to deliver the best experience for our users, we released a patch in January that addressed issues like floating-point literals that were handled incorrectly in certain locales, and allowed the simulator to run on older machines without vector instructions support.

We also addressed portability feature requests in our 0.2 release in February 2018, which saw us move from the .NET Framework to the open-source, cross-platform .NET Core. This allowed us to easily support macOS and Linux as well as Windows for building and running Q# code. We also added support for VS Code on all platforms (the 0.1 release was limited to Visual Studio on Windows). As part of the 0.2 release, we were able to make the majority of our libraries and samples available under an MIT license.

Long Hot Summer

We decided to take advantage of one of our team members’ expertise in organizing coding competitions and run a Q# coding competition to engage non-quantum developers with Q# and quantum computing. After a couple of months of preparation, we ran the Q# Coding Contest in early July. Again, the results exceeded our expectations: 514 participants in the warmup round, and 389 in the actual contest. 100 participants solved all the problems, and a lot of them even asked for more challenging ones!

To help make Q# and quantum computing more accessible to the public, we also launched self-paced programming tutorials: the Quantum Katas. We’re up to 10 katas already, and more are coming!

Spring, Summer, Autumn

We started planning the next major release in the spring of 2018, after shipping our 0.2 release: we wanted to rebuild our compiler to work as a language server, to give Q# developers the same interactive error checking and IntelliSense features they’re used to for languages like C# and F#. We knew this would be a huge amount of work and would require a significant re-architecture of the compiler in order to work incrementally. We didn’t want to wait longer to do this work, though, because we wanted to give our users the kind of modern programming environment they’re used to.

We spent the spring and summer re-architecting and rewriting the Q# compiler and shipped the new Q# compiler as our 0.3 release at the end of October.

The 0.3 release also includes a new, open source quantum chemistry library. This library integrates with NWChem, a powerful and popular open source computational chemistry package. The integration is based on the open source Broombridge schema.

Whatever Next

What’s next for Q#? No spoilers (yet!).

The last blog post of the calendar, scheduled for December 24th, will look at some of the things we’re considering for Q# in the coming year.

Until then, enjoy the holidays!

Congratulations to everyone who can figure out what the section titles have in common…

Alan Geller, Software Architect, Quantum Software and Applications @ageller Alan Geller is a software architect in the Quantum Architectures and Computation group at Microsoft. He is responsible for the overall software architecture for Q# and the Microsoft Quantum Development Kit, as well as other aspects of the Microsoft Quantum software program.

In previous versions of Visual Studio, the work item experience was centered around queries, which need to be created and managed to find the right work items. In Visual Studio 2019, we have removed queries and added a new view for work items centered at the developer. This allows the developer to quickly find the work they need and associate them to their pending changes. Removing the need for queries.

For those users who use Visual Studio for work item planning and triage, we encourage you to do so from Azure Boards. Azure Boards is the central place to manage your backlog, triage work, and plan your sprints.

Be sure to read the full documentation on how to use the new Azure Boards work item experience in Visual Studio 2019.

Work Items Hub

The Work Items Hub in Visual Studio 2019 has many of the same views found in the Work Items Hub in Azure Boards. It is where developers can quickly find the work items that are important to them. Filters and views can provide specific lists of work items such as Assigned to Me, Following, Mentioned, and My Activity. From any these views you can do quick do inline edits, assign work, create branches, and associate work to pending changes.

Create branches and relate work

Create a branch directly from a work item. This will automatically associate that work item to any current changes. Alternatively, you can relate a work item to a current set of changes already in progress. You can associate as many work items to a commit as you would like.

#Mention in commit message

Search and select work items directly from the commit message. Associate as many work items to the commit as you would like.

We need your help

We want to make the best experience for developers who use Azure Boards in Visual Studio. Please provide your feedback by sending us bugs and suggestions. You can contact us on Twitter at @danhellem or @AzureDevOps..

Dan Hellem, Program Manager, Azure DevOps @danhellem Dan is a Program Manager with Microsoft’s Azure DevOps on the Azure Boards team. Before coming to Microsoft in 2012, Dan spent his career building applications using Microsoft technologies and assembling Agile teams centered on delivering high quality software to users.

By now, many of you may have noticed a very prominent change to the launch of Visual Studio in Visual Studio 2019 Preview 1. Our goal with this new experience is to provide rapid access to the most common ways that developers get to their code: whether it’s cloning from an online repository or opening an existing project.

New start window in Visual Studio 2019

A month ago, we shared a sneak peek of the experience (in the blog post A preview of UX and UI changes) and mentioned the research and observation that we used as input into the design and development. This is the story about how we got there.

How & why we began this journey

Two years ago, we reinvented the Visual Studio installation experience to offer developers the ability to install exactly what they need and reduce the installation footprint of Visual Studio. We broke Visual Studio down into smaller packages and components and then grouped them together into development-focused workloads (which are bundles of packages and components). We quickly realized that the installation was just one piece of the journey our users take when they are getting started with Visual Studio.

We began to think more broadly – beyond just the installation of the bits, to explore the developer journey of getting to code. This journey starts from the moment you think about that great idea for an app all the way to writing your first lines of code, and integrating Visual Studio into your daily routine. To help us understand what developers were doing throughout their first launch, we built a data informed model of the customer journey.

Our Visual Studio Customer Journey

These insights helped improve installation success rates and address common failures but lacked the ability to answer questions around why some users drop off from one step to the next and how do we make sure Visual Studio meets the need of millions of developers? Some of you may even be trying to better understand how to make your own consumer or business customers more successful with your products.

So, from there we turned to existing mechanisms like surveys, interviews, social media (blogs), and A/B experimentation to help us understand where and how to improve these experiences. The surveys received an overwhelming number of responses (thank you to those of you who contributed!) and provided us with a foundation of anecdotes that helped us understand our individual users even more. They helped us recognize the different types of users coming into our “front door”, which is to say the first place they learn about Visual Studio and decide to download it. We identified through early cohort analysis, that almost half (50%) of users downloading were brand new to Visual Studio (but not necessarily new to coding) and only some of those users came back to Visual Studio for a second time. This was a surprising moment for us as we had no idea why this was happening!

Going beyond the data

We knew we needed deeper insights into how we could help new users be successful with their first time in Visual Studio and assist them in making the best choices along their journey. Fundamentally, we wanted to identify what the “Magic Moment” would be for them in Visual Studio. The “Magic Moment” is a phrase commonly used by product teams that maps a set of events or an experience a user has with a product that transforms them from a casual user trying something out to an avid, loyal user who finds success and even promotes the product. This moment is at the very core of identifying patterns to indicate users who will integrate a product or tool into their daily routine. We didn’t know what our Magic Moment was just yet, but we had a lot of ideas on what we believed it might be, so we asked ourselves:

Is there something new Visual Studio users do in the IDE that indicates they will return or abandon after 5 minutes?

We set out to answer this question by:

1. Observing developers, both brand new to Visual Studio and seasoned, as they find Visual Studio to download, configure, and start writing code.
2. Identifying the problems that they encountered throughout their journey to code.
3. Building hypotheses and concepts around getting to a “Magic Moment.”
4. Validating the hypotheses and concepts via an iterative process of weekly testing and experimentation.

Our iterative process from interns to external users

We started by asking our summer interns to install and use Visual Studio for the first time in our user experience (UX) lab and document their journey. We were surprised at how long and difficult the journey from download to writing and running code was for them. We also gained insights into their expectations for Visual Studio based on other editors and IDEs they had previous experience with.

Our first step was simple: we gave participants a clean virtual machine with only Windows 10 installed and asked them to find, install, use Visual Studio, and “do whatever is natural to you to get started.”

We then just watched…

One of our participants in the User Experience lab

Turns out even students think the 40 year-old concept of writing a “hello world” app is a great starting place. What also became extremely clear to us was that moment when users were writing and running code – we saw them become more engaged with Visual Studio and having fun. We saw an emotional change when they wrote their own code, compiled it, fixed some things, and ran it. We had a strong inkling that we were even closer to the “Magic Moment.”

We then scaled up our research to bring in more new and experienced developers every week. We tested out many ideas using low fidelity mockups built in PowerPoint and eventually moved to higher fidelity prototypes. We tried variations of tasks and UIs as we tested our assumptions. There were multiple problems to solve but one of the most significant became clear when we saw new Visual Studio developers struggle when trying to open code or create a new project. The first view of Visual Studio was overwhelming with no clear guidance of what they should do first. So, we set out to focus on that stage of the journey in our designs and storyboards for Visual Studio 2019. The design process looked a little something like this:

Visualizing the friction points in the customer journey

Evolution of our start window designs

Bringing all our insights into Visual Studio 2019

From all the design explorations, experiments, and observations, evolved an idea of the start window which would offer a focused experience to quickly get you to writing those first lines of code. Given our insights, we wanted to ensure users, especially those new to Visual Studio (some who are already experienced in other development tools), could quickly experience that “Magic Moment” of writing their first lines of code and successfully run it each and every time.

The start window would support new Visual Studio users by:

1. Highlighting the choices, they must make during the early, crucial steps of getting started with Visual Studio.
2. Removing distractions and providing suggestions for the best path forward.
3. Enabling a search and filter focused experience for creating a new project.
4. Promoting a streamlined online repository-first workflow.

Developers who are already well-versed and experienced with Visual Studio might be wondering what’s in it for them. What we’ve heard from experienced developers is that onboarding junior developers is very challenging, so we believe the new start window is a step towards ensuring they are more successful in getting to their code each time they open the IDE. We will also continue to preserve and enable existing workflows in the start window to support the muscle memory that experienced users have established with Visual Studio. Lastly, seasoned developers in the user experience lab were delighted by the new “Clone and check out code” experience which brings your online repositories right to your fingertips on launch.

Anatomy of the start window

We know the list of recent projects and solutions is one of the most common ways developers open code, so it was very important that we maintain this list in the most prominent part of the start window. We also knew it was VERY important to not break existing flows where developers open projects/solutions from the desktop (by double-clicking) – so the start window will never show in this flow, as your code will always take priority and open immediately.

Bringing a more focused, source-first experience of clone and check out code (like the Start Page had) to the forefront of Visual Studio was an opportunity to not only show new users the power of source providers like GitHub and Azure DevOps. We have also heard from our research with developers that this action is a more prominent part of a their daily workflow.

Opening a project or solution brings forward the concept of Visual Studio project and solution files that you can click on to open your entire codebase if you have an MSBuild-based solution. But if you use a non-MSBuild build system, such as CMake, then we would recommend opening a local folder instead. We’ve been investing in support to allow you to browse, edit, build, and debug any code without a .sln or project file. You can learn more about Open Folder, including how to configure a different build system to work with it, in our documentation. In addition, if you want to browse loose files in Visual Studio, you can just open the containing folder and pick up the file from the folder view of Solution Explorer.

Creating a new project is a big part of getting to your code in Visual Studio even when it’s prototyping some throwaway code in a simple template (like the Console App) or trying out the capabilities of a new platform or language for the first time. Based on the workloads you install, you’ll always see the most commonly used templates first. We’ve observed that developers first think about the kind of application they want to build (a mobile app, a website, etc.) and not the language – so we removed the language centric tree hierarchy and have improved searching and filtering to help you get to the right template more quickly. You’ll also find a more prominent list of recently used templates so you can quickly get back to your favorite template with a single click.

Lastly, continue without code offers developers a one-time escape from the window for the times when a different action is needed to start work (like joining a Live Share collaboration session, or attaching to a process). Alternatively, hitting the ESC key will also dismiss the window and immediately bring up the IDE. If there are other scenarios that you perform frequently and think should have a home on the start window (like for example attaching to a debugger), please upvote or create a suggestion in our Developer Community.

What’s next for this experience

In just a week, after releasing Visual Studio 2019 Preview 1, we’ve heard developers tell us the start window provides a “focused way to get to the most common things.” We’re already working on some of your feedback, such as support for Team Foundation Version Control and better scan ability in the recent solutions/projects list.

The start window experience is just one part of the journey we’re on to continue to streamline the onboarding experience to Visual Studio. Our longer-term vision includes improvements like reducing the number of choices required to download and install and offering relevant samples and tutorials to assist when learning a new language or platform.

Tell us what you think

As you can tell from the journey we’ve taken to get here, your feedback is essential to making this experience better. We’d love to have you try it out for a few hours in your everyday work. If it still doesn’t jive with you, then you can revert to the previous Visual Studio ‘start’ behavior. Go to Tools > Options and search for ‘Preview Features’ which will allow you to configure this setting along with a few other preview features. Alternatively, you can find the option in Tools > Options | Environment | Startup.

Tools | Options settings for Preview Features

After you’ve experienced Visual Studio 2019 Preview 1, please help us make this the best Visual Studio yet by letting us know what you like or tell us what is not working well for you. And of course, if you run into any issues, please let us know by using the Report a Problem tool in Visual Studio. You can also head over to the Visual Studio Developer Community to track your issue or, even better, suggest a feature, ask questions, and find answers from other developers.

Cathy Sullivan, Principal Program Manager, Visual Studio Platform @cathysull Cathy Sullivan is a Principal Program Manager on the Visual Studio Acquisition team focused on ensuring developers have a smooth onboarding experience for the first time and every time with Visual Studio. She has worked on many Visual Studio Platform teams building C#/VB language features, core UI/Shell features such as Solution Explorer and designed the beloved dark theme used by many developers.

As we seek to continually improve the Visual Studio Code experience for Java developers, we’d like to share couple new features we’ve just released. Thanks for your great feedback over the year, we’re heading into the holidays with great new features we hope you’ll love. Here’s to a great 2019!

Rename

With the new release of the Eclipse JDT Language Server, we’re removing the friction some developers experienced in ensuring renamed Java classes perpetuate into the underlying file in Visual Studio Code. With the update, when a symbol is renamed the corresponding source file on disk is automatically renamed, along with all the references.

Debugger

VS Code Logpoints is now supported in the Java Debugger. Logpoints allow you to inspect the state and send output to debug console without changing the source code and explicitly adding logging statements. Unlike breakpoints, logpoints don’t stop the execution flow of your application.

To make debugging even easier, you can now skip editing the “launch.json” file by either clicking the CodeLens on top of the “main” function or using the F5 shortcut to debug the current file in Visual Studio Code.

TestNG support

TestNG support was added to the newest version of the Java Test Runner. With the new release, we’ve also updated the UI’s of the test explorer and the test report. See how you can work with TestNG in Visual Studio Code.

We’ve also enhanced our JUnit 5 support with new annotations, such as @DisplayName and @ParameterizedTest.

Another notable improvement in the Test Runner is that we’re no longer loading all test cases during startup. Instead, the loading now only happens when necessary, e.g. when you expand a project to see the test classes in the Test viewlet. This should reduce the resource needed on your environment and enhance the overall performance of the tool.

Updated Java Language Pack

We’ve included the recently released Java Dependency Viewer to the Java Extension Pack as more and more developers are asking for the package view, dependency management and project creation capability provided by this extension. The viewer also provides a hierarchy view of the package structure.

Additional language support – Chinese

As the user base of Java developers using Visual Studio Code is expanding around the world, we decided to make our tool even easier to use for our users internationally by offering translated UI elements. Chinese localization is now available for Maven and Debugger, it will soon be available for other extensions as well. We’d also like to welcome contributions from community for localization as well.

IntelliCode and Live Share

During last week’s Microsoft Connect() event, we shared updates on the popular Visual Studio Live Share and Visual Studio IntelliCode features. The new IDE capabilities – all of which support Java – provide you with even better productivity with enhanced collaboration and coding experience that you can try now in Visual Studio Code.

Just download the extensions for Live Share and IntelliCode to experience those new features with your friends and co-workers. Happy coding and happy collaborating!

Attach missing sources

When you navigate to a class in some libraries without source code, you can now attach the missing source zip/jar using the context menu “Attach Source”.

We love your feedback

Your feedback and suggestions are especially important to us and will help shaping our products in future. Please help us by taking this survey to share your thoughts!

Try it out

Please don’t hesitate to try Visual Studio Code for your Java development and let us know your thoughts! Visual Studio Code is a lightweight and performant code editor and our goal is to make it great for the entire Java community.

• Install the Java Extension Pack which including Language Support for Java(TM) by Red Hat, Debugger for Java, Maven, Java Test Runner and Java Dependency Viewer.
• Install other Java related extensions base on your needs, including
  • Checkout Tomcat and Jetty if you’re working with those technologies.
  • In case you’re working on Spring Boot, there’re also great support provided by Pivotal and Microsoft available on VS Code including Spring Boot Tools, Spring Initializr and Spring Boot Dashboard.
  • Checkstyle could be handy when you need coherence code style especially cross multiple team members.
• Learn more about Java on Visual Studio Code.
• Explore our step by step Java Tutorials on VS Code.

Xiaokai He, Program Manager @XiaokaiHeXiaokai is a program manager working on Java tools and services. He’s currently focusing on making Visual Studio Code great for Java developers, as well as supporting Java in various of Azure services.

What if the community of extension authors banded together to add powerful features to Visual Studio that made it easier to create extensions? What if those features could be delivered in individually released extensions, but joined by a single installation experience that allows the user to choose which of the features to install? That’s the idea behind Extensibility Essentials – an extension pack that ships community-recommended extensions for extension authors.

Extension authors are usually interested in improving their own tooling in Visual Studio – either by installing extensions created by others or by building some themselves. By banding together, we can create the best and most comprehensive tooling experience for extension authoring. So, let’s test that theory by creating a range of extensions published to the Marketplace under our own accounts, and reference them in Extensibility Essentials to provide a unified and simple installation experience.

The individual extensions can and probably should be single purpose in nature. This prevents feature-creep where additional features are added that may or may not be useful for extension authors. If additional features are not closely related to the extension, then simply create a new extension for them. That way it is up to the individual extension author to decide if they wish to install it. It is also crucial that the extensions follow all the best practices.

Once the individual extension is stable, it can be added to Extensibility Essentials.

The extension pack Extensibility Essentials doesn’t do anything by itself. It is a barebone extension pack that just references the individual extensions. When installing the extension pack, the user can choose which of the referenced extensions to install. At the time of this writing, there are 9 individual extensions.

How the individual extensions are listed before installing

Ideas for new extensions can be centralized to the GitHub issue tracker. By collecting ideas in a central location, it provides a single location to comment on and potentially design features ahead of implementation.

The issue tracker is for both bugs and suggested features

It would be cool if…

So next time you’re sitting in Visual Studio working on an extension, think about what feature you’d like that would make you more productive. If you can’t think of a feature, but feel there is a scenario that is particularly problematic, then open a bug on the GitHub issue tracker and let other people try to figure out how an extension could perhaps solve the issue.

Thinking “it would be cool if…” is the first step to make it possible and with the Extensibility Essentials, it might be closer to becoming reality than imagined.

Does this idea resonate with you? Let me know in the comments.

Mads Kristensen, Senior Program Manager @mkristensen Mads Kristensen is a senior program manager on the Visual Studio Extensibility team. He is passionate about extension authoring, and over the years, he’s written some of the most popular ones with millions of downloads.

In previous blog posts you have read about some of the ideas behind Q#, how it came into existence, and its development over the past year. You have read about quantum computing, quantum algorithms and what you can do with Q# today. With the end of the year approaching, there is only one more thing to cover: What is next?

This blog post is about our aspirations for the future and how you can help to accomplish them. It contains some of our visions going forward, and we would love to hear your thoughts in the comment section below.

Community

One of the most exciting things about Q# for us is the growing community around it. Being rooted in the principles of quantum mechanics, quantum computing tends to have this air of unapproachability to the “uninitiated”. However, quantum computing builds on the notion of an idealized quantum system that behaves according to a handful of fairly easy to learn principles. With a little bit of acquired background in linear algebra, some persistence, and patience when wrapping your head around how measurements work it is possible to get knee-deep into quantum algorithms reasonably quickly!

Of course, a couple of good blog posts on some of these principles can help. We strive to actively support you in the adventure of exploring quantum algorithms by providing materials that help you get started, like our growing set of quantum katas. Our arsenal of open source libraries provides a large variety of building blocks to use in your quest of harnessing the power of quantum. One of the main benefits of open source projects is being able to share your work with all the people brave enough to explore the possibilities that quantum has to offer. Share your progress and help others build on your achievements! Whether in kata or library form, we welcome contributions of any size to our repositories. Let us know how we can help to make contributing easier.

Exchange among developers is one of the most important aspects of software development. It is omnipresent and vital to building a sustainable environment around a particular toolchain and topic. Thankfully, modern technology has made that exchange a lot easier than when the first computer programmers started their careers. We intend to make full use of the power of the internet and give a voice and a platform for discussions on topics related to Q# and quantum computing to developers around the world. The Q# dev blog is part of this effort. Contact us or comment below if you have an idea for a blog post or would like to hear more about a specific topic related to Q#. Establishing good feedback channels is always a challenging endeavor and in particular for a small team like ours. We would like this place to become a source of knowledge and exchange, a place where you can find the latest news and voice your take on them.

Growth

This brings us back to our plans for Q#. We have built Q# to make quantum development easier and more accessible. Of course, there were also a couple of other considerations that have played into that decision. For instance, we are anticipating the need to automate what is largely done in manual labor today, e.g. qubit layout and gate synthesis that are often still done on a case-by-case basis for each program and targeted hardware. When is the last time you worried about how error correction works on the hardware your code gets executed on? With qubits being an extremely scarce resource, and the long-term ambition to use quantum computing to address the most computationally intensive tasks that cannot be tackled with current hardware, the optimization of large-scale quantum programs needs to be a priority. We chose to develop our own language in order to have full control and flexibility over what information is represented how, and when it is used during compilation in order to be able to support a modular and scalable software architecture for executing quantum programs. But that’s a tale for another time. What is important is that these considerations are key factors in how we design and develop the language going forward.

A programming language is more than just a convenient set of tools for expressing an algorithm. It shapes the way that we think and reason about a problem, how we structure it and break it down into tasks when building a solution. A programming language can have a tremendous impact on our understanding of existing approaches, as well as how to adapt and combine them for our purposes. Particularly so when venturing into new territory.

Our goal is therefore to build a shared understanding of what it is we strive to accomplish, and to evolve Q# into the powerful language needed to drive progress in quantum programming. Our goal is to leverage the expertise of a community of language designers, compiler veterans, quantum physicists, algorithms and hardware experts, and a variety of software developers to shape a new kind of computing architecture. And we want you to be part of it.

Transparency

Since our 0.3 release at the beginning of November we have been eagerly working on not just the next release, but on defining and preparing the next steps in 2019. While we are in the middle of formulating our plans for the future, I want to give you a brief insight into some of our considerations.

As I am sure you have noticed, the support for data structures in Q# is minimal. While we do provide quite a few high-level language features for abstracting classical and quantum control flow, we intentionally omit some of the more object-oriented mechanisms such as classes. We anticipate remaining heavily focused on transformations that modify the quantum state, expressed as operations in Q#, as well as their characteristics and relations in the future. However, basic bundling of data and manipulations of such is of course an important aspect of many programs and we want to provide suitable mechanisms to express these in a way that allows to make abstractions, is convenient, and is resistant to coding errors. User defined types in the current setting have limited power besides an increased type safety. The “black box approach” to type parameterization currently restricts their usefulness; we do not provide a mechanism for dynamic reflection and it is not possible to apply operators or other type specific functionalities to argument items whose type is resolved for each call individually. In that sense, these items are “black boxes” that can merely be passed around. We want to do as much of the heavy lifting as possible statically in particular since debuggability of quantum devices is a huge challenge. There are several mechanisms one might consider alleviating the consequences of these decisions. On one hand, type constraints are a common mechanism used in several popular languages. In a sense, they can be seen as “specializations based on the properties of a type”. One could also pursue the stricter path of specializing based on the concrete type itself, de-facto adding a form of overloading that we currently explicitly prevent from being used. Either way, by clearly separating user defined types from tuples in the type system we have made a first step towards extending their power.

If you are curious to hear more about possible ideas for Q#, their benefits and caveats, or want to share some thoughts of your own, comment below! Contribute to the discussion and post your speculations to the question: What makes a quantum programming language “quantum”, i.e. what makes it particularly suited for quantum computing?

Join us

I hope you join us into a new year of pushing the boundaries of computation by participating in our coding competitions, contributing to our open source repositories, commenting on or writing blog posts and sharing your ideas and experiences!

How about a new year’s resolution of your own? Let us know what you expect to accomplish and how we can help you achieve your new year’s resolution around quantum programming in Q#!

Bettina Heim, Senior SDE, Quantum Software and Application @beheim Bettina Heim is a quantum physicist and software engineer working in the Quantum Architectures and Computation Group at Microsoft Research. She is responsible for the Q# compiler and part of the Q# language design team. Prior to joining Microsoft she worked on quantum algorithms, adiabatic quantum computing, discrete optimization problems, and the simulation and benchmarking of quantum computing devices.

What we’ve heard and experienced ourselves is that when building applications, you have a frictionless experience when your code editor and tools are integrated and seamless. Yet when developing IoT apps, you often need to manage connected devices and send test messages between the device and IoT Hub at the same time that you’re debugging and working on your code. You’ll likely spend time switching between windows or even screens to monitor the messaging and many components of your development.

To ensure that the tools you need are close at hand, we’ve updated the Cloud Explorer for Visual Studio extension for IoT developers to enable you to view your Azure IoT Hubs, inspect their properties, and perform other actions from within Visual Studio. Cloud Explorer is installed by default if you selected the Azure Workload when installing Visual Studio. To access the latest features, you need to upgrade to Microsoft Visual Studio 2017 Update 9 or later, then download and install the latest extension from Visual Studio marketplace.

Here are some of the new features to help IoT developers easily interact with Azure IoT Hub, and the devices connected to it:

• Interact with Azure IoT Hub
  • Send D2C messages to IoT Hub
  • Monitor D2C messages sent to IoT Hub
  • Send C2D messages to device
  • Monitor C2D messages sent to device
  • Invoke Direct Method
  • View and update device twin
• Device management
  • List devices
  • Get device info
  • Create and delete devices
• IoT Edge development support
  • Create IoT Edge deployment for device
  • List modules
  • View and update module twin

To learn more about what the IoT Hub enables and how to use the latest, check out the IoT Hub documentation.

Easy to Set Up

After you’ve installed Cloud Explorer, you can open Cloud Explorer view from Visual Studio menu View → Cloud Explorer. Sign in to your Azure account by clicking the Account Management icon if you haven’t done this before.

Expand Your subscription → IoT Hubs → Your IoT Hub, the device list will be shown under your IoT Hub node. Select one IoT Hub or device to inspect its properties or perform actions against the resource.

Now you have learned how to access your Azure IoT Hub resources.

Try the Tutorials

If you want to discover the Cloud Explorer features further, we offer the following walkthroughs where you will perform common IoT Hub management actions. To explore advanced or specific IoT scenarios, head over to check out our IoT Hub documentation, where we’re always adding new projects and tutorials.

• Use Cloud Explorer for Visual Studio to send and receive messages between your device and IoT Hub

• Use Cloud Explorer for Visual Studio for Azure IoT Hub device management

Your feedback is also very important for us to keep improving and making it even easier to develop your IoT applications. Please share your thoughts with us by suggesting a feature or reporting an issue in our Developer Community

Chaoyi Yuan, Software Engineer Chaoyi is a software engineer working on IoT tools. He’s currently focus on providing great tools for Visual Studio and Visual Studio Code users.

The second preview of Visual Studio 2019 is now available for download. This release contains a number of improvements and additions to the core experience and different development areas, many of which are a result of your direct feedback. As always, you can check out the release notes for more details or read on for the highlights.

Core IDE experience

Visual Studio 2019 will automatically download updates in the background while your computer is idle. This means you can continue using Visual Studio 2019 until it’s time to install. And, you will only need to wait for the actual installation of the update. The default will be set to “Download all, then install”, and you can modify this by going to Tools > Options > Environment > Product Updates.

In Preview 1, we introduced a new Per-Monitor Awareness (PMA) preview feature that is now enabled by default for users that meet the system requirements of .NET Framework 4.8 and Windows 10 April 2018 Update. Alongside the core IDE, multiple tool windows such as Toolbox, Breakpoints, Watch, Locals, Autos, and Call Stack should now render sharply across monitors with different display and scale configurations.

Search capabilities have improved in two places: the start window and inside the IDE. In the start window, you can now search for project templates by language, platform, and tags via the search box. Preview 2 introduces filters for menus, components, and templates during search in the IDE, as well as the capability to create and add new projects and items directly from the search box.

Based on your feedback, the new blue theme in Visual Studio 2019 has been updated by dialing down luminosity and increasing contrast. The draggable region has been improved as well by making the toolbar region also draggable. As a result, dragging the Visual Studio 2019 window should now be more natural.

The document health feature that was introduced with Preview 1 has been given a visual upgrade in Preview 2. Now, at a glance, you can see how many errors or warnings your document has, and clicking the control will bring up the error list. Code cleanup, which was introduced in Preview 1, has also been given its own control to quickly access the code cleanup features.

C++ development

C++ developers will notice quite a few improvements in this release. Check out the release notes for the full list, but here are some of the highlights:

• You now have access to a fresh version of the MSVC compiler and to libraries that:
  • Bring you guaranteed binary compatibility with Visual Studio 2017 MSVC toolset and runtime
  • Add initial support for C++ 20 standards (specifically the “spaceship” operator i.e. <=> under /std:latest),
  • Enable OpenMP 4 SIMD vectorization as well as many codegen improvements for better runtime performance and build throughput, including a new compiler switch -Ob3 that provides more aggressive inlining
  • Provide new Code Analysis checks including the new Lifetime profile checker.

• CMake integration now enables you to:
  • Detect and enable Vcpkg toolchains automatically for CMake projects
  • Take advantage of Just My Code debugging and Code Analysis editor integration in CMake projects

Plus, you can try out the latest C++ productivity improvements, including the newly-enhanced C++ Template IntelliSense, NULL->nullptr refactoring, quick fixes for missing #include and using namespace declaration, missing semicolons, and more.

C# development

Visual Studio 2019 Preview 2 adds a couple more new C# 8.0 language features on top of the ones that shipped in Preview 1 (Take C# 8.0 for a spin). Most notably, C# 8.0 pattern matching now allows recursive patterns, which can dig into the structure of an object, and switch expressions, which are a lightweight expression version of switch statements. To learn more, check out Do more with patterns in C# 8.0 on the .NET Blog.

F# development

A preview of the F# 4.6 language is now available in Visual Studio 2019 Preview 2. You can learn more about the language changes in the F# 4.6 Preview blog post. Additionally, we’ve revamped how the F# language service is initialized by Roslyn, which should result in a consistently faster solution load time for larger solutions.

.NET development

Visual Studio 2019 Preview 2 brings a range of new refactoring and codefix capabilities, such as sync namespace and folder name, pull members up, invert conditional expressions/logical operations, and many more. We’re also gradually rolling out new classification colors which are similar to Visual Studio Code. You can control these via Tools > Options > Environment > Preview Features.

Starting with this release, we are making project files for .NET SDK-style projects a first-class file type in Visual Studio and are supporting things like double-clicking a project node to open the project file and finding a project by name with Go To All (Ctrl + T). Additionally, .NET SDK-style projects will now use the new Integrated Console experience for F5 and Ctrl + F5 on console apps.

Code cleanup also now enables you to save collections of fixers as a profile. Now, if you wanted to apply a small set of targeted fixers frequently while you code and have another more comprehensive set of fixers to apply before preparing for a code review, you can configure profiles to address these different tasks.

Python development

You can now switch between different Python interpreters using the new Python Environments toolbar when editing Python files or working with projects or Open Folder workspaces.   Miniconda is available as an optional component during installation so you don’t have to separately install it to create conda environments. Additionally, you can now create Visual Studio Live Share sessions for collaboration on Python code. Check out the Python in Visual Studio 2019 Preview 2 blog post for more details.

Web and container development

If you’re developing with Node.js, you will find JavaScript debugging support for unit tests in this release. If ASP.NET is more your style, you will find that when publishing your application to Azure App Service, you can associate Azure Store and Azure SQL resources with your app as dependencies.

If you’re using containers, Visual Studio 2019 Preview 2 now supports debugging ASP.NET Core applications that use Alpine as a base image. There’s also support for the latest ASP.NET and .NET Core images.

Visual Studio Kubernetes Tools are now integrated in the Azure development workload for easy installation. This will add the Container Application for the Kubernetes project template to Visual Studio, which will automatically create a Dockerfile and Helm chart that you can use. This also enables you to add support for Kubernetes to an existing ASP.NET Core application by right-clicking the project and selecting Add > Container Orchestrator Support. After adding Kubernetes support, you can build, run, and debug your application in a live Azure Kubernetes Service (AKS) cluster with Azure Dev Spaces.

Mobile .NET development

For .NET developers using Xamarin to build mobile apps, Visual Studio 2019 Preview 2 has improved build performance if you use Xamarin.Android 9.1.1 or higher. Xamarin.Android now also supports the latest Android dex compiler (d8) and code shrinker (r8). The Android designer now natively supports Android Pie (9.0) and will show you improved status when loading. You can also use Go-To-Definition (Ctrl + Click) on resource URLs to navigate to the file or line where they are defined.

A new property panel has been added for Xamarin.Forms developers, enabling you to edit common attributes for controls. The Xamarin.Forms templates now use the latest Xamarin.Forms 4.0 release and include a new Xamarin.Forms Shell app that aims to reduce the complexity of a multi-platform app solution.

Last, but not least, load performance for new projects has been improved dramatically, showing performance gains of up to 50% in certain cases. When building apps, you can now also see more detailed build progress information by clicking the background tasks icon in the bottom left of the IDE.

Get started; share feedback

You can download Visual Studio 2019 Preview 2 here or update using the Visual Studio Installer. If you want to give it a spin without installing it, check out the Visual Studio images on Azure. Let us know of any issues you run into by using the Report a Problem tool in Visual Studio. You can also head over to the Visual Studio Developer Community to track your issues, suggest a feature, ask questions, and find answers from others. We use your feedback to continue to improve Visual Studio 2019, so thank you again on behalf of our entire team.

Angel Zhou Program Manager, Visual Studio Angel Zhou is a program manager on the Visual Studio release engineering team, which is responsible for making Visual Studio releases available to our customers around the world.

Are you inspecting many variables at once in the Locals window? Tired of constantly scrolling through the Watch window to locate the object you are currently interested in? New to Visual Studio 2019 for most languages (with some exclusions such as Xamarin, Unity, and SQL), you can now find your variables and their properties faster using the new search feature found in the Watch, Autos, and Locals windows!

With the new search feature, you will be able to highlight and navigate to specified values contained within the name, value, and type columns of each watch window.

Find your keywords faster using search and highlighting

If you are a fan of scrolling to the items you want, highlighting will allow you to find what you want easier. As you start typing in the search bar, the highlighting of matches currently expanded on screen will occur, giving you a faster alternative to performing a large-scale search.

Navigate between your specified keywords quickly

You can execute a search query using ENTER or the right and left arrow icons (“find next” (F3) and “find previous” (Shift+F3), respectively) shown below. If you are not a fan of scrolling to the items you want, clicking the arrows are also used to navigate through each found match. We based the search navigation on a depth first search model, meaning that matches are found by diving as far into the selected variable as specified before looking for matches within the next variable. You don’t have to sit through the full search if you don’t want to because search can also be cleared and canceled at any time, whether the search is ongoing or not.

Search for items deeply nested in your code

Unable to find what you’re looking for on your initial search? We’ve provided a “Search Depth” drop down to find matches nested X number of levels deep into your objects, where levels are defined similarly to levels in a tree data structure context. This option gives you the power to choose how thorough you want to search inside your objects (up to 10 levels), letting you decide how long or short the search process takes.

When you are searching for items that are already expanded and visible on your screen, these items will always be returned as matches no matter what search depth you have specified. Having to loop back to the item you want after passing it can be a pain, so setting the search depth to 1 will allow you to navigate to previous matches using the “find previous” arrow icon.

Excited to start searching in the Watch, Autos, and Locals windows? Let us know in the comments!

For any issues or suggestions, please let us know via Help > Send Feedback > Report a Problem in the IDE. If you have any additional feedback about this feature, feel free to complete this brief survey.

Leslie Richardson, Program Manager, Visual Studio Debugging & Diagnostics @lyrichardson01 Leslie is a Program Manager on the Visual Studio Debugging and Diagnostics team, focusing primarily on improving the overall debugging experience and feature set.

We are excited to announce that, in our Visual Studio Enterprise 2019 preview, we are expanding Snapshot Debugger support beyond Azure App Services hosting ASP.NET Core and ASP.NET applications to now also include Azure Virtual Machines (VM), Azure Virtual Machine scale sets (VMSS), and Azure Kubernetes Services (AKS)!

When Visual Studio 2017 Enterprise 15.5 became generally available, we introduced the Snapshot Debugger, an innovative diagnostic tool that enables you to quickly and accurately evaluate problems in their Azure production environments without stopping the process and with minimal performance impact.

When an unanticipated issue occurs in production, it can be difficult to replicate the exact conditions in your testing environment and almost impossible to do so on your local development machine. You might consider asking your DevOps team to “turn up” production logging but this relies on you having already anticipated where issues might occur prior to deployment. You may also request that a process dump be taken, but that requires perfect timing and some luck to capture the most important details, you also must gauge how your collection strategy might negatively imy pact performance.

The Snapshot Debugger provides a familiar and powerful debugging experience, allowing developers to set Snappoints and Logpoints in code, similar to debugger breakpoints and tracepoints. When a Snappoint is hit in your production environment, a snapshot is dynamically created without stopping the process. Developers can then attach to these snapshots using Visual Studio and see what’s going on with variables, Locals, Watches and Call Stack windows, all this while the live site continues to serve your customers.

Azure Virtual Machines/Azure Virtual Machine scale sets

For most PaaS scenarios, Azure App Service is more than capable of encapsulating a complete end-to-end experience. However, for developers and organizations that require greater control over of their platform and environment, VMs remain a critical option and Snapshot Debugger supports them in the latest preview of Visual Studio.

Once your VM/VMSS has been set up to host your ASP.NET or ASP.NET Core web application you can open your project in Visual Studio 2019, and click on the “Debug->Attach to Snapshot Debugger…” menu item, where you will now be able to select VM/VMSS as shown.

The UI experience remains almost identical but now you will be required to select an Azure Storage account to collect your snapshot logs and to share the snapshot collection plan (App Services will also require Azure Storage in Preview 2).

Selecting the “Install Remote Debugger Extension” option will prompt Visual Studio to install the extensions in Azure, which is necessary to view snapshots. This process also opens a specific set of ports (30398, 31398, 31399, 32398) to facilitate communication to your local machine, these ports are not required for retrieving and viewing logpoints.

Azure Kubernetes Services (AKS)

Azure provides an incredible cross platform experience and our debugging and diagnostics tools now provide feature parity in our Kubernetes service offerings.

Before attempting to use any of the Snapshot Debugger features in AKS it is vital that your Docker images include ASP.NET Core 2.2+ installed in a global location, as well as the correctly configured Snapshot Debugger and the requisite environment variables.

To help you enable support for Snapshot Debugger in AKS we have provided a repo containing a set of Dockerfiles that demonstrate the setup on Docker images. We support three variants of Linux (Debian, Alpine and Ubuntu) and they are organized according to the ASP.NET Core version, the OS platform, and the platform architecture.

For example, the ASP.NET Core 2.2 Debian 9 (Stretch) x64 Dockerfile is located at /2.2/stretch-slim/amd64/Dockerfile. This Dockerfile produces an image with Debian 9 x64 as the base with ASP.NET Core 2.2 Runtime, it includes the latest supported Snapshot Debugger backend package and sets the environment variables to load the debugger into your .NET Core application.

Try the preview

The latest Snapshot Debugger experiences are now in preview, download and try it out here.

This preview supports the following scenarios:

• Azure App Services on the Windows OS running ASP.NET Core (2.0+) or ASP.NET (4.6.1+).
• Virtual Machines on the Windows OS running ASP.NET Core (2.0+) or ASP.NET (4.6.1+).
• Azure Kubernetes Services (Linux Docker Containers) running ASP.NET Core (2.2+).

If you have any issues using Snapshot Debugger, please review this guide on Troubleshooting and known issues for snapshot debugging in Visual Studio.

We would love to hear your feedback. To report issues, use the Report a Problem tool in Visual Studio. You’ll be able to track your issues on the Visual Studio Developer Community site where you can also ask questions and find answers.

Mark Downie, Program Manager, Visual Studio Diagnostics @poppastring Mark is a program manager on the Visual Studio Diagnostics team, working on Snapshot Debugger.

If you are a web, mobile or games developer and would like to know how to become more productive and efficient using Visual Studio for Mac then we’ve got you covered. Visual Studio for Mac is a powerful IDE for C# developers that work with Xamarin, .NET Core and Unity workloads. The new video series, hosted on the Visual Studio Toolbox, contains short, roughly 5-minute, videos that cover tips and tricks for specific tasks and may even unveil features you didn’t even know existed! The first few videos will be introducing Visual Studio for Mac and what you can do with it.

You don’t want to miss a single video in the series so make sure you subscribe now. We will be recording and releasing a new video each week over the next few weeks, and the links will be updated on the date specified below. The videos currently feature Program Managers, Cody Beyer (@cl_beyer) and Sayed Ibrahim Hashimi (@SayedIHashimi). You can also provide feedback using the Developer Community portal

Here are the links to all the videos:

Tell us what you think!

We invite you to leave us a comment below and let us know what you think of the series. If these are helpful and valuable to our users, then we will record more videos and keep the series going. If there is another format that you think would be better, we would love to hear your thoughts.

Here are some useful links:

• Download Visual Studio for Mac
• Learn more about Visual Studio for Mac
• Report a problem, or suggestion, for Visual Studio for Mac

Cody Beyer, Program Manager @cl_beyerCody Beyer is a Program Manager on the Visual Studio for Mac team at Microsoft. His primary areas of focus cover overall performance and reliability of the IDE. He is also interested in computer ethics and privacy and aims to create software that empowers and respects everyone.

Sayed Hashimi, Senior Program Manager @sayedihashimiSayed Ibrahim Hashimi has a computer engineering degree from the University of Florida. He works at Microsoft as a Senior Program Manager creating better .NET Core, and ASP.NET Core, ­development tools in Visual Studio for Mac. Before joining the Visual Studio for Mac team, he worked on ASP.NET features in Visual Studio. Prior to joining Microsoft, he was a Microsoft Visual C# MVP. Sayed has written four book on MSBuild, http://msbuildbook.com and he is a co-founder of  the OmniSharp project.

What we’ve heard and experienced ourselves is that when building applications, you have a frictionless experience when your code editor and tools are integrated and seamless. Yet when developing IoT apps, you often need to manage connected devices and send test messages between the device and IoT Hub at the same time that you’re debugging and working on your code. You’ll likely spend time switching between windows or even screens to monitor the messaging and many components of your development.

To ensure that the tools you need are close at hand, we’ve updated the Cloud Explorer for Visual Studio extension for IoT developers to enable you to view your Azure IoT Hubs, inspect their properties, and perform other actions from within Visual Studio. Cloud Explorer is installed by default if you selected the Azure Workload when installing Visual Studio. To access the latest features, you need to upgrade to Microsoft Visual Studio 2017 Update 9 or later, then download and install the latest extension from Visual Studio marketplace.

Here are some of the new features to help IoT developers easily interact with Azure IoT Hub, and the devices connected to it:

• Interact with Azure IoT Hub
  • Send D2C messages to IoT Hub
  • Monitor D2C messages sent to IoT Hub
  • Send C2D messages to device
  • Monitor C2D messages sent to device
  • Invoke Direct Method
  • View and update device twin
• Device management
  • List devices
  • Get device info
  • Create and delete devices
• IoT Edge development support
  • Create IoT Edge deployment for device
  • List modules
  • View and update module twin

To learn more about what the IoT Hub enables and how to use the latest, check out the IoT Hub documentation.

Easy to Set Up

After you’ve installed Cloud Explorer, you can open Cloud Explorer view from Visual Studio menu View -> Cloud Explorer. Sign in to your Azure account by clicking the Account Management icon if you haven’t done this before.

Expand Your subscription -> IoT Hubs -> Your IoT Hub, the device list will be shown under your IoT Hub node. Select one IoT Hub or device to inspect its properties or perform actions against the resource.

Now you have learned how to access your Azure IoT Hub resources.

Try the Tutorials

If you want to explore Cloud Explorer features further, we offer the following walkthroughs where you perform common IoT Hub management actions. To explore advanced or specific IoT scenarios, head over to check out our IoT Hub documentation, where we’re always adding new projects and tutorials.

• Use Cloud Explorer for Visual Studio to send and receive messages between your device and IoT Hub

• Use Cloud Explorer for Visual Studio for Azure IoT Hub device management

Your feedback is also very important for us to keep improving and making it even easier to develop your IoT applications. Please share your thoughts with us by suggesting a feature or reporting an issue in our Developer Community

The post Build an Azure IoT application with Cloud Explorer for Visual Studio appeared first on The Visual Studio Blog.

Are you inspecting many variables at once in the Locals window? Tired of constantly scrolling through the Watch window to locate the object you are currently interested in? New to Visual Studio 2019 for most languages (with some exclusions such as Xamarin, Unity, and SQL), you can now find your variables and their properties faster using the new search feature found in the Watch, Autos, and Locals windows!

With the new search feature, you will be able to highlight and navigate to specified values contained within the name, value, and type columns of each watch window.

Find your keywords faster using search and highlighting

If you are a fan of scrolling to the items you want, highlighting will allow you to find what you want easier. As you start typing in the search bar, the highlighting of matches currently expanded on screen will occur, giving you a faster alternative to performing a large-scale search.

Navigate between your specified keywords quickly

You can execute a search query using ENTER or the right and left arrow icons (“find next” (F3) and “find previous” (Shift+F3), respectively) shown below. If you are not a fan of scrolling to the items you want, clicking the arrows are also used to navigate through each found match. We based the search navigation on a depth first search model, meaning that matches are found by diving as far into the selected variable as specified before looking for matches within the next variable. You don’t have to sit through the full search if you don’t want to because search can also be cleared and canceled at any time, whether the search is ongoing or not.

Search for items deeply nested in your code

Unable to find what you’re looking for on your initial search? We’ve provided a “Search Depth” drop down to find matches nested X number of levels deep into your objects, where levels are defined similarly to levels in a tree data structure context. This option gives you the power to choose how thorough you want to search inside your objects (up to 10 levels), letting you decide how long or short the search process takes.

When you are searching for items that are already expanded and visible on your screen, these items will always be returned as matches no matter what search depth you have specified. Having to loop back to the item you want after passing it can be a pain, so setting the search depth to 1 will allow you to navigate to previous matches using the “find previous” arrow icon.

Excited to start searching in the Watch, Autos, and Locals windows? Let us know in the comments!

For any issues or suggestions, please let us know via Help > Send Feedback > Report a Problem in the IDE. If you have any additional feedback about this feature, feel free to complete this brief survey.

The post Enhanced in Visual Studio 2019: Search for Objects and Properties in the Watch, Autos, and Locals Windows appeared first on The Visual Studio Blog.

When Visual Studio 2017 Enterprise 15.5 became generally available we introduced the Snapshot Debugger, an innovative diagnostic tool that allows developers to quickly and accurately evaluate problems in their Azure production environments without stopping the process and with minimal performance impact.

When an unanticipated issue occurs in production it can be difficult to replicate the exact conditions in your testing environment and almost impossible to do so on your local development machine. You might consider asking your DevOps team to “turn up” production logging but this relies on you having already anticipated where issues might occur prior to deployment. You may also request that a process dump be taken, but that requires perfect timing and some luck to capture the most important details, you also must gauge how your collection strategy might negatively impact performance.

The Snapshot Debugger provides a familiar and powerful debugging experience, allowing developers to set Snappoints and Logpoints in code, similar to debugger breakpoints and tracepoints. When a Snappoint is hit in your production environment, a snapshot is dynamically created without stopping the process. Developers can then attach to these snapshots using Visual Studio and see what’s going on with variables, Locals, Watches and Call Stack windows, all this while the live site continues to serve your customers.

We are excited to announce that in our Visual Studio 2019 Enterprise preview we are expanding Snapshot Debugger support beyond Azure App Services hosting ASP.NET Core and ASP.NET applications to now also include Azure Virtual Machines (VM), Azure Virtual Machine scale sets (VMSS) and Azure Kubernetes Services (AKS)!

Azure Virtual Machines/Azure Virtual Machine scale sets

For most PaaS scenarios Azure App Services is more than capable of encapsulating a complete end to end experience. However, for developers and organizations that require greater control over of their platform and environment, VMs remain a critical option, and Snapshot Debugger is now fully supported in the latest preview of Visual Studio.

Once your VM/VMSS has been set up to host your ASP.NET or ASP.NET Core web application you can open your project in Visual Studio, click on the “Debug->Attach to Snapshot Debugger…” menu item, where you will now be able to select VM/VMSS as shown.

The UI experience remains almost identical but now you will be required to select an Azure Storage account to collect your snapshot logs and to share the snapshot collection plan (App Services will also require Azure Storage in Preview 2).

Selecting the “Install Remote Debugger Extension” option will prompt Visual Studio to install the extensions in Azure, which is necessary to view snapshots. This process also opens a specific set of ports (30398, 31398, 31399, 32398) to facilitate communication to your local machine, these ports are not required for retrieving and viewing logpoints.

Azure Kubernetes Services (AKS)

Azure provides an incredible cross platform experience and our debugging and diagnostics tools now provide feature parity in our Kubernetes service offerings.

Before attempting to use any of the Snapshot Debugger features in AKS it is vital that your Docker images include ASP.NET Core 2.2+ installed in a global location, as well as the correctly configured Snapshot Debugger and the requisite environment variables.

To help you enable support for Snapshot Debugger in AKS we have provided a repo containing a set of Dockerfiles that demonstrate the setup on Docker images. We support three variants of Linux (Debian, Alpine and Ubuntu) and they are organized according to the ASP.NET Core version, the OS platform, and the platform architecture.

For example, the ASP.NET Core 2.2 Debian 9 (Stretch) x64 Dockerfile is located at /2.2/stretch-slim/amd64/Dockerfile. This Dockerfile produces an image with Debian 9 x64 as the base with ASP.NET Core 2.2 Runtime, it includes the latest supported Snapshot Debugger backend package and sets the environment variables to load the debugger into your .NET Core application.

Try the preview

The latest Snapshot Debugger experiences are now in preview, download and try it out here.

This preview supports the following scenarios:

• Azure App Services on the Windows OS running ASP.NET Core (2.0+) or ASP.NET (4.6.1+).
• Virtual Machines on the Windows OS running ASP.NET Core (2.0+) or ASP.NET (4.6.1+).
• Azure Kubernetes Services (Linux Docker Containers) running ASP.NET Core (2.2+).

If you have any issues using Snapshot Debugger please review this guide on Troubleshooting and known issues for snapshot debugging in Visual Studio.

We would love to hear your feedback. To report issues, use the Report a Problem tool in Visual Studio. You’ll be able to track your issues on the Visual Studio Developer Community site where you can also ask questions and find answers.

The post Debug your live apps running in Azure Virtual Machines and Azure Kubernetes appeared first on The Visual Studio Blog.

If you are a web, mobile or games developer and would like to know how to become more productive and efficient using Visual Studio for Mac then we’ve got you covered. Visual Studio for Mac is a powerful IDE for C# developers that work with Xamarin, .NET Core and Unity workloads. The new video series, hosted on the Visual Studio Toolbox, contains short, roughly 5-minute, videos that cover tips and tricks for specific tasks and may even unveil features you didn’t even know existed! The first few videos will be introducing Visual Studio for Mac and what you can do with it.

You don’t want to miss a single video in the series so make sure you subscribe now. We will be recording and releasing a new video each week over the next few weeks, and the links will be updated on the date specified below. The videos currently feature Program Managers, Cody Beyer (@cl_beyer) and Sayed Ibrahim Hashimi (@SayedIHashimi). You can also provide feedback using the Developer Community portal

Here are the links to all the videos:

Tell us what you think!

We invite you to leave us a comment below and let us know what you think of the series. If these are helpful and valuable to our users, then we will record more videos and keep the series going. If there is another format that you think would be better, we would love to hear your thoughts.

Here are some useful links:

• Download Visual Studio for Mac
• Learn more about Visual Studio for Mac
• Report a problem, or suggestion, for Visual Studio for Mac

The post Become a Visual Studio for Mac super user with this Tips and Tricks Video Series appeared first on The Visual Studio Blog.

Visual Studio 2019 now supports per-monitor DPI awareness (PMA) across the IDE. PMA support means the IDE and more importantly, the code you work on appears crisp in any monitor display scale factor and DPI configuration, including across multiple monitors.

If you have used Visual Studio across monitors with different scale factors or remoted into a machine with a different configuration than the host device, you might have noticed Visual Studio’s fonts and icons can become blurry and in some cases, even render content incorrectly. That’s because versions prior to Visual Studio 2019 were set to render as a system scaled application, rather than a per-monitor DPI aware application (PMA).

System scaled applications render accurately on the primary display as well as others in the same configuration but have visual regressions such as blurry fonts and images when rendering on displays with different configurations. When working for extended periods of time, these visual regressions can be a distraction or even a physical strain.

Visual Studio 2019 Preview 1 included the core platform support for per-monitor DPI awareness and Preview 2 includes additional fixes for usability issues around scaling, positioning and bounding (e.g. content renders within the bounds of tool windows). Preview 2 also adds several more popular tool windows that now correctly handle per-monitor DPI awareness.

How to enable PMA for Visual Studio 2019

The easiest way to try the new PMA functionality is on Visual Studio 2019 Preview 2. You’ll need to have the Windows 10 April 2018 Update or a newer build installed along with the latest version of .NET Framework 4.8. If you’re still running Preview 1 then you also need to enable “Optimize rendering for screens with different pixel densities” in the Preview Features node of the Tools -> Options dialog.

There are many features where you’ll start to see Visual Studio render clear fonts and crisp images. Here’s a few of the most used UI in Visual Studio where you should notice a difference.

• Core Shell
• Menus and context menus
• Most code editors
• Solution Explorer
• Team Explorer
• Toolbox
• Breakpoints
• Watch
• Locals
• Autos
• Call Stack

Visual Studio 2019 Preview 2 also fixes some of the usability issues affecting UI positioning, scaling and content bounding that were discovered in Preview 1.

Our goal is to have per-monitor awareness working across the most used features by the time we ship Visual Studio 2019. In future updates, we’ll continue enabling PMA across more areas and look forward to your feedback.

Tell us what you think!

We thank you for your ongoing feedback, and encourage you to install the latest Visual Studio 2019 preview, enable the PMA functionality, and tell us about your experiences through the Developer Community portal. Please upvote PMA related asks or create new ones whenever you feel a specific component (tool window, dialog, etc.) or issue has not being reported.

Reporting your experience alongside your display configurations, PMA feature state (on/off) and for bonus points, any screenshot or video showing the affected areas will help us resolve issues faster, and account for as many use-cases as possible.

The post A better multi-monitor experience with Visual Studio 2019 appeared first on The Visual Studio Blog.

“Why is this value changing unexpectedly and where or when is this occurring?!”

This is a question many of us dread asking ourselves, knowing that we’ll have to do some tedious trial-and-error debugging  to locate the source of this issue.  For C++ developers, the exclusive solution to this problem has been the data breakpoint, a debugging tool allowing you to break when a specific object’s property changes.  Fortunately, data breakpoints are no longer a C++ exclusive because they are now available for .NET Core (3.0 or higher) in Visual Studio 2019 Preview 2!

Data breakpoints for managed code were a long-requested ask for many of you. They are a great alternative to simply placing a breakpoint on a property’s setter because a data breakpoint focuses on a specific object’s property even when it’s out of scope, whereas the former option may result in constant, irrelevant breaks if you have hundreds of objects calling that function.

How do I set a data breakpoint?

Setting a data breakpoint is as easy as right-clicking on the property you’re interested in watching inside the watch, autos, or locals window and selecting “Break when value changes” in the context menu.  All data breakpoints are displayed in the Breakpoints window. They are also represented by the standard, red breakpoint circle next to the specified property.

When can I use data breakpoints?

Now that you know how to set a data breakpoint, now what?  Here are some ways to take advantage of data breakpoints when debugging your .NET Core applications.

Let’s say that you want to figure out who is modifying a property in an object and for most of the time, this property change does not happen in the same file. By setting a data breakpoint on the property of interest and continuing, the data breakpoint will stop at the line after the property has been modified.

This also works for objects. The data breakpoint will stop when the property referencing the object changes value, not when the contents of the object change.

As illustrated in the GIF above, calling the toEdit._artist.ChangeName() function did not cause a breakpoint to hit since it was modifying a property (Name) inside the Song’s Artist property.  In contrast, the data breakpoint hits when the _artist property is assigned a reference to a new object.

Data breakpoints are also useful when you want to know when something is added or removed from a collection. Setting a data breakpoint on the ‘Count’ field of classes from System.Collections.Generic makes it easy to detect when the collection has changed.

Are there opportunities for improving managed data breakpoints?

Since Visual Studio 2019 is still in preview, we highly encourage you to experiment, play around with, and provide feedback for this iteration of data breakpoints.  Here are some known scenarios where data breakpoints currently cannot be set that we are working on erasing and improving in future Visual Studio updates:

• Properties that are not expandable in the tooltip, Locals, Autos, or Watch window
• Static variables
• Classes with the DebuggerTypeProxy Attribute
• Fields inside of structs

Managed data breakpoints also exclude properties that call native code and properties that depend on too many fields.

Ready to try data breakpoints in your .NET Core applications?  Let us know in the comments!

For any issues or suggestions about this feature, please let us know via Help > Send Feedback > Report a Problem in the IDE or in the Developer Community.

The post Break When Value Changes: Data Breakpoints for .NET Core in Visual Studio 2019 appeared first on The Visual Studio Blog.

Today, we’re proud to show you the new look and URL for Microsoft’s developer tools and services blogs where you can explore the latest news and updates for our products, discover a new project to try out, and share your favorite content with your friends. With our new mobile-friendly design, you can stay connected with our developer community even when you’re AFK (away from keyboard).

You’ll see this enhanced UI and functionality on our Visual Studio, IoT Developer, Premier Developer, DevOps, and the new QSharp blogs. Over the next few weeks, you’ll see additional developer blogs transition to this new URL. All blogs will preserve existing content as well as your bookmarks and RSS feed subscriptions. However, if you have any issues reaching your desired content, please report it to us through the Feedback button in the lower right corner.

Explore your favorite tags

On some of our existing posts, you will notice some visual changes. We’ve reviewed our previous posts on the Visual Studio blog and edited for more accurate categories and tags so that you can more easily find content related to your work. When you find a post that is helpful, make sure to check out the categories and tags at the bottom to discover other related posts.

We’ll be evolving and improving these tags over time to make sure that we’re keeping you connected with the latest topics and news. If you’re looking for a tag that doesn’t currently exist or you have a topic you’d like us to cover, please send us a suggestion through our Feedback button. Our authors will be reviewing these suggestions to inspire their next posts!

Visual Studio Blog’s most popular categories and tags:

• Web Development /category/web/
  • NET /tag/asp-net

• Debugging and Diagnostics /category/debug/
  • Tips & Tricks /tag/tips/
  • Getting Started /tag/start/

• Mobile Development /category/mobile/
  • Xamarin /tag/xamarin/
  • Apache Cordova /tag/cordova/

• Game Development /category/game/
  • Unity /tag/unity/
  • Unreal Engine /tag/unreal/

• Cloud /category/cloud/
  • DevOps /tag/devops/
  • Azure /tag/azure/

Share with your colleagues

It’s a great feeling when you can show someone a tool or trick that makes their development so much easier. Now, when you discover a quote, code snippet, or blog post that shows you that new tool or concept, you can share it on your favorite social media easily.

Frequently Asked Questions

To see the full list of FAQs and latest on the known issues, please see our Developer Blogs FAQ. If you have a question, idea, or concern that isn’t listed, please share it with us through the Feedback button in the lower-right.

How do I find content, especially about topics relevant to my projects or from my favorite authors?

You can always do a search or filter to posts in a specific blog. If you’re still having trouble finding content, please tell us about it by completing our short survey. To find posts by a certain author, you can now visit their author page where you can connect with on social media or discover other topics they’ve recently written about.

I have saved/bookmarked the URL to this blog. Will I need to change this?

We have you covered. All your existing URLs will auto-redirect. However, if a link unintentionally breaks, please report it through our feedback.

What about my RSS feed? Will my feed reader still get all the latest posts?

Your RSS feed will continue to work through your previous set-up. If your RSS feed is broken, please report it with details about which feed reader you use.

How do I follow the team / author?

For the authors, please visit the author pages to find the appropriate social spaces to follow them at.

For a blog, or related social, please see the “Follow Us” links at the very bottom of the blog.

How do I find other developer blogs?

The navigation right on top will take you to our various developer blogs. Some links will take you to a blog on the new site. Others will show an error. This is because those blogs are still in the process of moving to our new platform. For immediate access to content on those blogs, please continue to visit the MSDN blog.

Is this the only blog that is moving?

This migration involves a number of Microsoft developer blogs. Check out the Developer Blogs FAQ for a table of all blogs that will be migrated over the next few weeks.

Share your feedback!

We are very excited about our new blogs and would love to hear your thoughts. Please fill out this survey to help us improve, or share your feedback and bug reports through the feedback button.

The post Welcome to the new home of our developer tools blogs! appeared first on The Visual Studio Blog.

At Connect();  alittle over two months ago, we released the first Visual Studio 2019 Preview. Based on your inputs, we’ve made several improvements to Visual Studio 2019 in our endeavor to make this the best Visual Studio yet. On behalf of our entire team, I’m excited to announce the upcoming release of Visual Studio 2019 on April 2, 2019 at the Visual Studio 2019 Launch Event.

Join us at our virtual event

Join us online on April 2 starting at 9 AM Pacific Time for demos and conversations centered around development with Visual Studio 2019, Azure DevOps, and GitHub. We’ll have something for everyone, whether you’re a developer who uses C#, C++, or Python or target the web, desktop, or cloud. And, of course, you’ll be one of the first who get to try out the Visual Studio 2019 release.

Scott Hanselman will kick off the day with an online keynote highlighting the newest innovations in Visual Studio. Be prepared to be delighted and ready to return to your coding even more productively than before! The keynote will be followed by several live-streamed sessions, hosted by experts with online Q&A, that dive deeper into various features and programming languages. We’ll close out the day with a virtual attendee party sponsored by our Visual Studio ecosystem partners, so make sure you stick around!

We’re also looking to team up with community organizers around the globe to organize local, in-person launch events between April 2 and the end of June. Check out the local events page for more details on how to host one of these events or to join local events around the globe. We’ll have supporting content available on GitHub and we’ll support your local event with swag if you let us know about it by March 1.

Visual Studio 2019 Preview 3

As we keep marching towards our launch, we are continuing our Visual Studio 2019 Preview releases. Yesterday we released Visual Studio 2019 Preview 3, which includes several improvements and fixes based on the feedback you provide through the Developer Community. Be sure to check out the release notes for all the details on this release.

Save the date

You can head over to https://launch.visualstudio.com/ today to get a glimpse of what we’ll be sharing and save the date using the calendar invite or sign up for updates via e-mail. We’ll update the site regularly with more information on the full agenda as well as additional speakers. Tell us about your Visual Studio journey so far and let us know what you’re excited to see using the #VS2019 on Facebook and Twitter. We look forward to seeing you online!

The post Join us April 2nd for the Launch of Visual Studio 2019! appeared first on The Visual Studio Blog.

We started sharing Visual Studio 2019 Previews with the goal to deliver the best possible experience through a more open dialog.

Over the last few months, we’ve seen lots of thoughtful and passionate discussion throughout the community, on the blog, in Developer Community, and a bunch of social media sites. Through these previews, we were able to share some of the UI changes in this release.

We want to say thank you for sharing this feedback. Everyone working on the team has read through all the comments and we’ve done our best to respond to the different themes discussed in the threads.

Hopefully, by now you’ve had a chance to try the Visual Studio 2019 Preview. If not, we encourage you to try out some of the new experiences. There were a few popular themes in the feedback that we wanted to acknowledge and talk a bit about the changes we’ve already made based on your feedback.

Combining the title and menu bar

With the combined menu and title bar, we took an opportunity to give back valuable vertical space and update the layout of the upper shell controls. This also makes the new more accurate VS Search more discoverable and accessible. While we strived to do this without impacting your workflow many users highlighted the title bar was home to several information elements including solution name, administrator mode, experimental instance tag, and the preview badge the were important for navigating between multiple instances of Visual Studio running at the same time.

When we first combined the title and menu bar, we were careful not to remove the solution name from the app title that appears when you ALT+TAB or hover over the app icon in the start menu. We found in controlled studies testing these were the most commonly used elements for establishing context across instances of Visual Studio. As we started to test the changes internally though, feedback surfaced that users still found the missing solution name jarring so we started working on some potential solutions.

We heard another piece of feedback from the community that we’d heard in our studies; users often need more context than just the solution name. Having seen this feedback before in some of our studies we experimented in Preview 1 & 2 with a new home for solution name in the status bar next to the existing branch switcher. While this design had the benefit of bringing solution and repo information closer together it wasn’t very discoverable and didn’t work well with cascaded windows. Preview 3 now brings back the solution name into the combined title & menu bar and updates surrounding controls to reserve space for the name.

The title bar included other information in addition to the solution name. We took steps to preserve the other contexts that were previously available in the title bar including Administrator mode, experimental instance, and preview channel by displaying them in a badge under the window state controls. The “Send feedback” and “Live Share” controls are available on the toolbar row while the notification icon has a new home in the bottom right of the shell to better align with common notification patterns.

Blue theme changes

Another goal for Visual Studio 2019 was to make it easy to tell the difference when you have different versions of the IDE open, be that 2012, 2017 or 2019. We refreshed the blue theme, which we’d not touched since 2012, to indicate this step into the future.

What we found through the feedback is that some functional elements from the original Blue theme were lost with the first iteration of the theme update. While most of you generally liked the new theme some customers gave us feedback that it removed some spatial definitions in the UI that helped navigate around the IDE quickly and intuitively. Comments also pointed out that the blue theme updates had gotten too bright adding eye strain over longer periods.

For Preview 3, We’ve heightened overall contrast which in turn helped improve legibility, accessibility, and wayfinding throughout the IDE. We reduced the brightness of the base color and added a set of complementary and analogous accent colors. These changes preserve an at a glance difference between versions while tackling the functional feedback.

New Icons

While not the most glamourous part of a new release, the new product icon is an important way to identify our IDE in a busy taskbar, start menu or desktop. It’s also another way that you can tell the difference between versions of our product. In our original post we explained the approach we’ve taken to simplify the icon for Visual Studio as well as create a system for showing the difference between a Preview and full released version.

We’ve now applied this approach to the Visual Studio for Mac icon which is available to download from our website. One of the challenges with the icon for Visual Studio for Mac was how to create an icon that was closely tied to the Visual Studio Family line of products but that stood apart from the Windows version of Visual Studio so as not to confuse you into thinking they’re the same (just on different platforms). We experimented with many ways of showing a differentiation between the two applications but settled on tying them together as a family, with a background shape that echoes the form of the Infinity Loop, and adds a macOS flavor to the icon.

Let’s continue the conversation

We are truly grateful for all the feedback we’ve received so far and hope to use this to continue to improve the experiences we’re delivering throughout the product. As you find bugs or have suggestions the Developer Community site is the place to log these items for the team to review and the benefit of the community. We’re eager to continue the discussion as you continue to use Visual Studio 2019.

The post Reflecting your feedback in Visual Studio 2019 appeared first on The Visual Studio Blog.