We’re focusing Microsoft Graph PowerShell on the platform where we can give you the most reliable, capable, and well-maintained experience: PowerShell 7.x and later. Built on modern .NET, PowerShell 7.x resolves many of the underlying assembly-loading and dependency issues that affect Windows PowerShell 5.x today. Concentrating our engineering there means faster fixes, quicker delivery of new features, and fewer platform-specific failures for you.

To make that focus possible, today we’re announcing that Windows PowerShell 5.x is entering a 12-month retirement period for the Microsoft Graph PowerShell modules. Over this period, we’ll wind down maintenance on 5.x and direct new investment, development, and validation to PowerShell 7.x and later. The v2.x modules will keep working on Windows PowerShell 5.1 throughout — this is a planned transition, not a switch we’re flipping today.

Retirement refers to maintenance, not compatibility. During the retirement period the v2.x modules will continue to declare compatibility with Windows PowerShell 5.1 and, in most cases, keep functioning in existing environments just as they do now. What changes is where our engineering effort goes: new features, bug fixes, and validation will target PowerShell 7.x, and issues specific to Windows PowerShell 5.x will no longer be actively investigated or fixed. 

Timeline

• Now through the next ~12 months (retirement period). The v2.x modules remain compatible with Windows PowerShell 5.1 and will receive security fixes as required. Maintenance for PowerShell 5.x compatibility winds down, while active development, validation, and investment move to PowerShell 7.x and later — giving you time to plan and complete your migration without disruption.
• In Q4 CY 2026 a new major version of Microsoft Graph PowerShell will be released. With the release of v3.0.0 no new versions of v2 will be published unless security fixes are required. V3.x modules will not have explicit support for Windows PowerShell 5.x and are only supported for PowerShell 7.x.

Call to Action

If you’re still on Windows PowerShell 5.1, begin planning your move to PowerShell 7.x now. It’s the recommended and only maintained platform going forward, and it delivers the more reliable experience described above.

We appreciate our customers’ partnership and understanding as we make this transition and continue investing in the future of Microsoft Graph PowerShell.

The post Investing in a more reliable Microsoft Graph PowerShell experience appeared first on Microsoft 365 Developer Blog.

To be completely honest with you, I missed the news when CSS Container Queries first shipped. And when I finally heard about it, my very first thought was, “Why exactly do I need this when media queries already exist?”

I’m not proud of that reaction, knowing what I know now, but it was comforting to know that I wasn’t alone. In fact, there are legions of us out there.

What baffles me is that container queries aren’t a new feature, as it currently sits at around 94% browser support. And yet, very few people are actually using it. According to the State of CSS survey, 86% of developers are aware of container queries, but only 41.4% actually use them. Surveys can be biased and not completely representative of our entire field, but this one is certainly the best indicator we’ve got.

Kevin Powell also talked about this at SmashingConf Amsterdam 2026: Container Queries adoption has been terrible. And that is so strange to me, knowing that the ability for components to adapt to the size of their outer container has been at the top of so many CSS wishlists over the years.

I’m not particularly interested in how many people are using container queries as much as in how they are using them. I can’t account for everyone, but from what I’ve seen — including in my own early attempts — many of us are using them wrong.

The bottom line is that incorrect use comes down to the same impression I had when learning about them: they absolutely look just like media queries at first glance. And since they look similar, it’s easy to assume they serve similar purposes and work the same way.

They don’t.

Note: I should state up front that what I’m focusing on in this article is using container size queries, i.e., a responsive design technique for responding to the size of a particular container. There are also container style queries that respond to a container’s computed styles (and are experimental at the time of this writing). You can catch up on those in Juan Diego’s piece here on Smashing Magazine where he examines their possible use cases.

The viewport is a proxy. It always has been. Media queries are what gave us the illusion that screen width alone is responsible for how responsive apps adapt to their environment.

Ask yourself this: When you write @media, what are you asking the browser?

@media (min-width: 1024px) {
  .card {
    display: flex;
  }

I, like most developers, am asking the browser: How wide is the screen right now? That’s it.

Media queries answer that beautifully, but what happens when this .card component is placed in a grid cell that’s 300px wide on a 1920px desktop screen?

The media query doesn’t care; it does its job. The viewport is still 1920px, so min-width: 1024px fires and the matched query styles are applied, even though the card only has 300px of space to work with. Eventually, everything in the card deforms, overflows, or cramps up.

“Media queries are dumb. Not dumb in terms of the concept, but dumb in that they don’t know very much. In fact, most people assume that they know more than they do.”

— Kevin Powell

It’s common to think of responsive design purely as a system for updating complete page layouts, like going from two columns on a large screen to a single column on a small screen.

Container queries are smarter than that. They make responsive layouts more reliant on what’s happening inside a component rather than on the outer context that has no insight into a component’s contents. It is more like: “How much space is available for me in this specific spot, right now?”

Here is the same card code example we looked at in the last section, but with a container query:

.card-wrapper {
  container-name: card;
  container-type: inline-size;
}

@container card (min-width: 450px) {
  .card {
    display: flex;
    flex-direction: row;
  }
}

This changes everything. The card isn’t influenced by the viewport; its only concern is whether the .card component’s parent wrapper has at least 450px of inline (i.e., horizontal in a left-to-right writing mode) space. If that condition is true, the component goes horizontal; if not, it goes to its default block display.

The logic works like this:

1. When there’s enough room, both items (.flex-item) sit side-by-side, each exactly half the parent container’s width.
2. When there is limited space, the second item wraps to the next line.
3. Because flex-grow is active on each item, the wrapped items stretch to fill most of the parent’s width.
4. If the item is a container itself, it detects the sudden width expansion and fires.

/* The flex parent */
.flex-layout {
  display: flex;
  flex-wrap: wrap;
}

/* Register a flex item as a container */
.flex-item {
  container-type: inline-size;
  flex: 1 1 390px; /* Grow to fill space, wrap at 390px */
}

/* Default Card Styles (narrow / side-by-side) */
.card {
  display: flex;
  flex-direction: column;
  background: #f4f4f4;
}

/* Once there's enough room for a full row */
@container (min-width: 600px) {
  .card {
    flex-direction: row;
    align-items: center;
    background: #e2f0d9;
  }
}

This works. As the parent size shrinks and the cards wrap to two lines, the card item expands, the container query fires, and applies the necessary styles.

At the end of the day, the core reason why container queries look incredibly similar to media queries is simply familiarity. They’re not exactly “new”, but they are way less understood and adopted than media queries. But media queries have plenty of their own limitations; otherwise, we wouldn’t need container queries to fill those gaps.

What we have is a more effective feature for detecting when a specific component’s context changes and a means for adjusting styles based on its content, as it should be when that component can exist in multiple contexts.

The post Learn Uno Platform with Tim Corey, Free for Two Weeks appeared first on Uno Platform.

We’ve released version 2026.2.2 of ReSharper, Rider, and .NET tools. You can install this update from inside the tools themselves, through the Toolbox App, or on our website.

Here’s what’s new in this update.

Rider 2026.2.2

AI Agent Setup widget

We’ve recently added a wide range of features to help you work with coding agents in Rider. With so much new functionality, keeping track of every announcement and discovering what’s available can be a challenge. That’s why we’ve now put everything you need in one place.

Rider 2026.2.2 introduces the AI Agent Setup widget, a new entry point in the bottom-right status bar. This new tool helps you find and set up Rider’s features for coding agents. When you open it, you’ll see a list of supported features like MCP tools, skills, and hooks, along with brief explanations of how each one can help your workflow.

The overview shows you which features are already enabled and which ones you can set up, with direct links to the right settings pages. No matter if your coding agent runs inside Rider or in an external terminal, the widget helps you see what Rider offers and quickly find the settings you need to begin.

Less noise and clearer context for AI agents with hooks

Rider’s hooks now provide AI agents with more targeted feedback after code changes. This helps cut down on unnecessary information and makes formatting changes coming from the IDE easier to spot.

Agents now get inspection results from the Run files inspections hook only for the code they added, not the whole file. This lets them focus on their own changes.

The Reformat file hook now gives a diff that shows any formatting changes made by the IDE. Agents can see what changed right away, so they don’t have to reread the file to understand the updates.

Test coverage gets TUnit support

Rider’s dotCover integration now measures coverage for unit tests written with TUnit. To enable coverage, install the JetBrains.dotCover.Framework package in your project.

To enable full Testing Platform support in Rider, go to Settings | Build, Execution, Deployment | Unit Testing | Testing Platform and check the Enable Test Platform support box.

Note: TUnit coverage requires Microsoft.Testing.Platform version 2.3.0 or later.

Notable fixes

Here are some important fixes included in this release:

• RIDER-142337 On macOS 26.2.2, Rider could freeze indefinitely, usually while loading a large solution, but sometimes at other times. Rider collects thread dumps from its backend process to help diagnose slowdowns. This process briefly suspends the backend and then resumes it. A change to the macOS system API broke the resume step, leaving the backend permanently suspended. This issue has been fixed, and macOS 26.2.2 is now fully supported.
• RIDER-142279 The Attach to Unity Editor feature no longer depends on the editor executable name. This change fixes problems with recent Unity Hub versions and custom engine builds.
• RIDER-139586 MCP server access errors on attached folders. File operations now work across all folders attached to the solution, not just in the main solution directory.

To see the complete list of fixes and improvements, please visit this page.

ReSharper 2026.2.2

Test coverage gets TUnit support

dotCover now measures coverage for unit tests written with TUnit. To enable coverage, install the JetBrains.dotCover.Framework package in your project.

To enable full Testing Platform support in Rider, go to Extensions| ReSharper | Options | Unit Testing | Testing Platform and check the Enable Test Platform support box.

Note: TUnit coverage requires Microsoft.Testing.Platform version 2.3.0 or later.

For the complete list of updates included in this build, please see the full release notes.

You can download the latest builds from our website or via the Toolbox App. You can also update Rider as a snap package. Let us know how the new features fit into your workflow in the comments below. 

AI is changing software development at a pace no one can ignore. 

Developers now have powerful AI tools that can help us write code, understand unfamiliar codebases, troubleshoot problems, learn new frameworks, and get answers in seconds. That is an incredible opportunity. But as these tools become more capable, I believe something else is becoming more valuable too: learning directly from other developers. 

That’s one of the reasons I continue to believe so strongly in events like VSLive!. 

Learn from people who have done the work 

One of the things I value most about VSLive! is its focus on practical developer education. 

For more than three decades, VSLive! has helped developers, software architects, and engineers stay current as Microsoft development has evolved. Today, that means learning about AI-powered development alongside the technologies developers are already using to build applications. 

You’re learning from experts who can explain not only how something works, but why they chose one approach over another and what they learned along the way. 

That context is difficult to reproduce outside of this kind of event. 

Get hands-on and ask the next question 

VSLive! gives developers opportunities to move beyond simply hearing about a technology. When you encounter an unexpected error, question a design choice, or discover that your implementation behaves differently than expected, you can dig deeper. 

And because you’re learning alongside experts and other developers, you can ask the next question. 

That feedback loop can turn an interesting technology into something you’re confident enough to bring back to your team. 

The hallway can be as valuable as the session 

Some of the most useful moments at a developer conference don’t happen on a slide. 

They happen after a session when you ask the speaker one more question. They happen over lunch when another developer explains how their team solved a problem you’ve been wrestling with. Sometimes they happen because you meet someone who becomes part of your professional network for years. 

VSLive! creates room for those conversations alongside the technical content and access to Microsoft Product Managers. 

Step away from the backlog and think about what comes next 

Most developers don’t spend their normal workday thinking broadly about where software development is headed. They’re fixing bugs, reviewing pull requests, shipping features, attending meetings, and working through the backlog. 

A conference gives you an opportunity to step outside that cycle and ask bigger questions: 

What should I learn next? 

How should AI change the way I build software? 

What are other teams doing with .NET, Azure, GitHub Copilot, and modern application architecture? 

What could I bring back that would make my team better? 

VSLive! gives you a place to explore those questions with people who are asking many of the same things. 

Put your Visual Studio subscriber benefit to work 

If you have a Visual Studio Subscription, VSLive! is also a great example of why it’s worth exploring the benefits available to you. Visual Studio subscribers have access to exclusive subscriber pricing, including significant discounts on VSLive! events.  

Before you register, check your benefits at my.visualstudio.com and take advantage of your VSLive! subscriber discount of up to 900 dollars.  

Even if you’re not a subscriber, there’s still an opportunity to save: enter VSLMS to receive up to 600 dollars off VSLive! registration. 

Join us at VSLive! Orlando 

VSLive! Orlando is part of Live! 360 Tech Con at Universal Orlando from November 15-20, 2026. 

Topics include: 

• Modern software engineering 

• Cutting-edge AI 

• The core of .NET 

• Full stack web development 

• Database development 

• Developing new experiences 

• Human factors in engineering 

If you’re trying to keep pace with AI while deepening your skills in .NET, C#, Azure, modern software engineering, data, web development, and the Microsoft developer stack, there is real value in spending a few days learning alongside other developers in expert led sessions. 

Join us at VSLive! Orlando and make time to learn, experiment, ask questions, and connect with the developer community. And if you’re planning ahead for 2027, save the dates: VSLive! will be heading to Vegas March 22-26 and Austin May 2-6. 

I hope to see you there.

The post AI Is Changing How We Code. It’s Also Changing How We Learn.  appeared first on Visual Studio Blog.