News For Dev-ops

We're excited to announce the Azure DevOps service connection , a new way to access Azure DevOps from your pipelines using a Microsoft Entra workload identity (a service principal or managed identity) instead of a Personal Access Token (PAT) or session token. This post walks through what it is, how to set it up, and the many places you can use it, including several capabilities we've added based on your feedback. Why use an Azure DevOps service connection? Using an Azure DevOps service connection improves the security of your pipelines in several ways: PAT-free authentication: Eliminate the need to create, store, and rotate Personal Access Tokens Least privilege: Use per-pipeline or even task-level permissions instead of shared build service account permissions No persistent secrets: Use Microsoft Entra federated credentials instead of passwords Audit trail: All authentication attempts are logged in the Azure DevOps audit log Because the connection authenticate...

Last time, we tried to execute on our plan to use the global interface table to hold hold a reference to an object in another apartment that automatically expires when the apartment runs down . But it broke down because objects that are marked INoMarshal can't go into the global interface table. So we will just force the square peg into the round hole: We can put the non-marshalable object inside an object that is marshalable. template<typename Smart> struct force_marshal : winrt::implements<force_marshal<Smart>, ::IUnknown, winrt::non_agile> { force_marshal(Smart const& p) : m_p(p) {} Smart m_p; }; The force_marshal<Smart> object babysits a non-marshalable smart pointer to a COM object and exposes a marshalable wrapper around it. Since the wrapped object is not agile, the wrapper cannot be either. (If the wrapper were agile, then we'd be back where we started: How do we ensure that the m_p is destructed in the correct apartment?)...

In part 5 of this unnecessarily long series on agile delegates , commenter LB asked , "Is the Context­Callback in the deleter guaranteed to always succeed? According to the docs it can fail. I wonder if there's a way to move the fallible part to an earlier point so the deleter can be infallible." Let's look at the first part: What if IContext­Callback:: Context­Callback fails? If it fails, it means that COM couldn't switch to the destination context. If you can't switch to the destination context, then you can't release the pointer. It's not clear what recovery is possible anyway. Do you just keep retrying until it finally works? If the destination context is an ASTA, then it's possible that the reason is that the context is already busy, and ASTA doesn't allow re-entrancy. We'd have to wait a little bit and try again later, when the destination context might be ready. We can't just block on the retry because the destination con...

Over half of the time we spent trying to make an agile version of a Windows Runtime delegate in C++/WinRT was dealing with the case of a delegate that declares non-marshalability . But how much does it matter? I looked at the three major C++ implementations of the Windows Runtime: C++/WinRT, C++/CX, and WRL. The C++/WinRT implementation has an optimization for IAgile­Object , but for objects that aren't agile, it just goes directly to agile_ ref without checking for INoMarshal . This means that a delegate that declares non-marshability will always be rejected by C++/WinRT when used as an event handler. The C++/CX implementation lazy-creates the agile reference to the original delegate when the wrapper is used from a different apartment . If the original delegate is non-marshalable, it means that the CO_ E_ NOT­SUPPORTED is produced only when the wrapper is used in a way that requires a marshalable delegate. The WRL implementation does not have an optimization for IAgile­O...

Windows Performance Analyzer (WPA) is one of the most powerful tools available for understanding system performance on Windows. It helps engineers investigate Event Tracing for Windows (ETW) traces across CPU, memory, disk, networking, scheduling, input, and many other areas of the operating system. That power also comes with complexity. A single trace can contain a huge amount of data, and finding the right signal often requires knowing which WPA tables to open, which columns matter, how to filter the right time range, and how to connect multiple pieces of evidence into a root cause. We are working on WPA MCP as an Early Preview feature to make that workflow easier and more approachable. What is WPA MCP? WPA MCP brings GitHub Copilot CLI into the WPA trace-analysis workflow. Instead of starting every investigation by manually navigating graphs and tables, you can ask questions about the trace in natural language. WPA MCP helps GiHub Copilot translate that intent into trace-data exp...

Not every question deserves the same amount of thought. Renaming a variable isn't the same as debugging a memory leak, and they don't need the same level of thinking. So why should your model treat them the same way every time? Starting in Visual Studio 18.9 Insiders 2, it doesn't have to. Supported models now come with a thinking effort control, so you can dial up the reasoning when a problem is genuinely hard and dial it back down when it isn't. It's a small knob with a big payoff: better-matched answers, and more control over how many credits you spend getting them. A dial, not a switch Thinking effort is exactly what it sounds like: how much reasoning a model does before it answers. It shows up as a set of named levels, and which ones you get depends on the model. Here's what each level is for: Low  - Quick responses with minimal reasoning. Great for straightforward questions and everyday code suggestions, and it consumes fewer AI credits. Mediu...

Learn what's new in Visual Studio Code 1.132 (Insiders) Read the full article Post Updated on July 29, 2026 at 06:00PM Thanks for reading from devamazonaws.blogspot.com

Last time, we fixed the problem of creating a unique_ptr whose deleter's constructor was might throw an exception . But we're not out of the woods yet. Let's take another look at what we have: if (d.try_as<::INoMarshal>()) { void* p; if constexpr (std::is_reference_v<Delegate>) { p = winrt::detach_abi(d); } else { winrt::copy_to_abi(d, p); } return [p = std::unique_ptr<void, in_context_deleter>(p, {}), token = get_context_token()](auto&&...args) { if (token == get_context_token()) { std::remove_reference_t<Delegate> d; winrt::copy_from_abi(d, p.get()); d(std::forward<decltype(args)>(args)...); } else { throw winrt::hresult_error(CO_E_NOT_SUPPORTED); } }; } We had originally broken the rule that the u...

It looked like we were done when we fixed the problem of releasing a non-marshalable delegate on the correct thread . But we missed something. Again. if (d.try_as<::INoMarshal>()) { void* p; if constexpr (std::is_reference_v<Delegate>) { p = winrt::detach_abi(d); } else { winrt::copy_to_abi(d, p); } return [p = std::unique_ptr<void, in_context_deleter>(p), token = get_context_token()](auto&&...args) { if (token == get_context_token()) { std::remove_reference_t<Delegate> d; winrt::copy_from_abi(d, p.get()); d(std::forward<decltype(args)>(args)...); } else { throw winrt::hresult_error(CO_E_NOT_SUPPORTED); } }; } The first part gets a raw ABI pointer, either by moving it out of the inbound delegate if we can, else ...

You know the moment. CI goes red, or a build that took 8 seconds yesterday now takes 40, and you're staring at a wall of MSBuild output trying to find the one line that matters. The answer is almost always sitting in the binary log ( .binlog ) - it records every project, target, task, property, and diagnostic in the build. The problem is that reading one has meant firing up a separate viewer and already knowing where to look. What if you could just ask ? That's the idea behind the MSBuild Binlog Analyzer for VS Code, now in Preview on the Visual Studio Marketplace . It brings binlog analysis right into your editor and hands the tedious detective work to GitHub Copilot Chat - so you can stay in the flow and keep shipping. Just want an agent to investigate builds for you - say, unattended in CI? Check out the Microsoft Binlog MCP Server - the same analysis engine, driven headlessly. This post is about the interactive, in-editor experience. The problems it solves Buil...

Electron and Node.js make it straightforward to build Windows desktop apps in JavaScript. Calling Windows Runtime APIs has been less straightforward: features such as on-device AI often required a C++ or C# bridge, manual translation of WinRT types and asynchronous behavior, and wrapper code for every exposed API. That meant another language and toolchain to build, test, and keep compatible with Electron. We're making  a dynamic Windows Runtime API (WinRT) projection for Node.js  available in public preview. It lets an Electron app or plain Node.js process call supported Windows Runtime APIs directly from JavaScript or TypeScript. Start with one npm package; the tooling generates JavaScript wrappers and TypeScript declarations for the Windows features you choose. No app-specific native addon,  node-gyp  setup, or C++ wrapper is required. What makes this projection different The Windows Runtime already has static language projections for  C++/WinRT ,  C#/WinRT ,  wi...

Hello Java customers! We are happy to announce the latest July 2026 patch & security update release for the  Microsoft Build of OpenJDK . Check our  release notes  page for details on fixes and enhancements or  download and install  the binaries today. The source code of our builds are now available on GitHub for further inspection: OpenJDK 25.0.4 OpenJDK 21.0.12 OpenJDK 17.0.20 OpenJDK 11.0.32 Microsoft Build of OpenJDK specific updates OpenJDK 25 Used the "Processor Information" counter to enumerate processors in all processor groups Added optimized aarch64_get_thread_helper() for Windows/ARM64 Marked Reserved Stack Area as unsupported on Windows/ARM64 OpenJDK 21 Used the "Processor Information" counter to enumerate processors in all processor groups Marked Reserved Stack Area as unsupported on Windows/ARM64 OpenJDK 17 Used the "Processor Information" counter to enumerate processors in all processo...

Last time, we wrote a wrapper delegate that checked whether the context it was being invoked from matched the context it was captured from . if (d.try_as<::INoMarshal>()) { return [d = std::forward<Delegate>(d), context = winrt::capture<IContextCallback>(CoGetObjectContext)](auto&&...args) { if (context == winrt::capture<IContextCallback>(CoGetObjectContext)) { d(std::forward<decltype(args)>(args)...); } else { throw winrt::hresult_error(CO_E_NOT_SUPPORTED); } }; } We did this by comparing context objects. This obtains the current object context in order to compare it with the original one, and that means an internal Add­Ref , and then we have to explicitly Release it. But there's a way to do this without having to obtain any objects. The Co­Get­Context­Token function gives you an integer that uniquely identifies a live context ob...

Big news: Azure SQL Developer is here, in private preview. It's  the Azure SQL Database engine, on your laptop, in a container. Build against the exact engine you run in the cloud. Ship the same code to Azure. Change one line, the connection string, and  you're  in production. Free for local dev and CI. No subscription. No credit card. No catch. Run it yourself, or hand it to an AI agent and watch it go.   The inner-loop problem If you build apps on a cloud database, you know the friction. To develop and test locally, you either point your app at a shared cloud instance, with slow round trips, noisy neighbors, and connection-string rewrites between dev and prod, or you develop against a different database locally and hope the behavior matches once you deploy. Either way you pay a tax: cloud spend while you experiment, flaky integration tests, and the occasional "it worked on my machine" surprise when a local-only feature does not exist in the cloud. The fix is not ...