Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
161916 stories
·
33 followers

dotnet-1.23.0

1 Share

Changes:

  • be01dec .NET: Add origin pinning to Foundry toolbox MCP client (#8721)
  • 0d6d2bb .NET: fix: declarative workflow http variables (#8797)
  • 2024d4d .NET: Fix workflow topology edge multiplicity comparison (#8656)
  • 37ce872 .NET: Store created external input messages (#8606)
  • 1370903 .NET: [BREAKING] Better support tool changes between runs (#8754)
See More
  • 3f1f3b5 .NET: Propagate TextSearchProvider caller cancellation (#8796)
  • 238d7e2 .NET: Validate Foundry client headers before transport (#8715)
  • c804f32 .NET: [BREAKING] Bump Azure.AI.Projects to 3.0.0-beta.3, OpenAI to 2.14.0, and MEAI to 10.10.1 (#8730) [ dotnet/extensions#7760, dotnet/extensions#7761 ]
  • 93cf98a .NET: Update AGUI SDK packages to 1.0.0 (#8769)
  • 1092349 Clarify CodeAct guest packages and host network access (#8781)
  • 6f1522a Temporarily skip OpenAI integration tests while the CI API key is invalid (#8767)
  • 2c46deb .NET: Clarify hosting authentication, authorization, and isolation guidance (#8677)
  • 024dd99 .NET/Python: Improve MCP skill resource validation (#8690)
  • 8ff549d .NET: Correct InvokeAzureAgent response output (#8605)
  • 5ee3e87 .NET: Remove redundant NuGet configuration (#8719)
  • 6227372 Set better expecations for contributors (#8706)
  • 30b9b8e .NET: Only consume stored approval state when the run succeeds (#8692)
  • 834eb7f fix(dotnet): persist function results as user messages (#8655)
  • 0bbb724 .NET: [BREAKING] fix: use allow list for configuration keys (#8200)
  • a638ce1 .NET: Fix forwarded request-port type validation (#8657)
  • 76ccf3c fix(dotnet): forward declarative Azure agent version (#8658)
  • 11b8b80 Use review App permissions for repair reactions (#8669)
  • 74e8fe6 Use the workflow token for fix-ci evidence (#8667)
  • 173978e .NET: Add function replace support for function middleware (#8615)
  • bf93c53 .NET: [BREAKING] Enforce approval response binding consistently (#8641)
  • 646e116 .NET: [BREAKING] Fix DevUI approval continuation (#8423) [ #6006 ]
  • 925f4f2 .NET: ci/dotnet vscode configuration (#8537)
  • ec7114f .NET: fix: a bug where invoke function tool could bypass approval (#8403)
  • c5a8c8d fix(core): distinguish absent tool call arguments from parse failures (#8609)
  • 17b349f docs(core): fix positional invocations in detect_media_type_from_base64 docstrings (#8614)
  • eb74c8c fix(core): ensure add_usage_details returns copies and filters non-ints consistently (#8613)
  • 02bd1ba fix(ag-ui): allow text events when response_format is a json schema dictionary (#8604)
  • 7b62670 ci: removes workflow based PR limit to use GitHub native feature (#8603)
  • bb53fe1 test(ollama): narrow pytest.raises blocks to wrap only get_response in error tests (#8611)
  • 894b0f6 samples: add McpDocsResearch declarative workflow showcasing agent-level MCP pattern (#6054)
  • 42c22c0 Bump GitHub.Copilot.SDK to 1.0.1 and forward session config properties (incl. per-session GitHubToken) (#5735) [ #6381 ]

This list of changes was auto generated.

Read the whole story
alvinashcraft
just a second ago
reply
Pennsylvania, USA
Share this story
Delete

C++ reminder: Function-local static variables are initialized only once, even if it looks like they get initialized multiple times

1 Share

When you write a static variable inside a function, it is initialized only once, specifically at the first time that execution reaches the variable’s declaration, If execution reaches the variable again in the future, no initialization occurs. It just retains its old value.

Some time ago, I noted an attempt to fix a lifetime issue by making a variable static.

The original code used this header from an external widget library:

// widget.h
struct WidgetController
{
    virtual WidgetKind GetKind() = 0;
    virtual WidgetFlags GetFlags() = 0;
    virtual void OnOpening() = 0;
    ⟦ and so on ⟧
};

std::shared_ptr<Widget>
    MakeWidget(std::shared_ptr<WidgetController> const& controller);

The idea is that you give it a Widget­Controller object that the widget consults at various times, allowing you to customize the widget behavior.

The application code called it like this:

// The basic Widget controller provides information but
// does not override any default behaviors.

struct BasicWidgetInfo
{
    WidgetKind kind;
    WidgetFlags flags;
    ⟦ and so on ⟧
};

struct BasicWidgetController : WidgetController
{
    BasicWidgetController(BasicWidgetInfo const& info) :
        m_info(info) {}

    WidgetKind GetKind() override { return m_info.kind; }
    WidgetFlags GetFlags() override { return m_info.flags; }

    // Do not customize any dynamic actions.
    void OnOpening() override { }
    ⟦ and so on ⟧

private:
    BasicWidgetInfo const& m_info;
}

struct Gadget
{
    std::shared_ptr<Widget> m_widget;

    void CreateWidget(GadgetFlags flags)
    {
        BasicWidgetInfo info = {
            WidgetKind::Vanilla,
            WidgetFlags::Openable |
            (flags & GadgetFlags::ClosableWidget ?
                WidgetFlags::Closable : WidgetFlags::None)
        };

        auto controller = std::make_shared<BasicWidgetController>(info);

        m_widget = MakeWidget(controller);
    }

    ⟦ other gadget stuff ⟧
};

The catch is that the Widget­Options constructor takes a reference to a Gadget­Options and saves the reference. Later, when the widget asks the controller for the flags, the controller will look up the answer in the BasicWidgetInfo structure, but that BasicWidgetInfo had already destructed when Create­Custom­Widget returned, so it returns garbage (or possibly even crashes).

This is a use-after-free bug.

To solve this problem, they made the info static. Static objects continue to exist even after the function returns.

    void CreateWidget(GadgetFlags flags)
    {
        static BasicWidgetInfo info = {
            WidgetKind::Vanilla,
            WidgetFlags::Openable |
            (flags & GadgetFlags::ClosableWidget ?
                WidgetFlags::Closable : WidgetFlags::None)
        };

        auto controller = std::make_shared<BasicWidgetController>(info);

        m_widget = MakeWidget(controller);
    }

Now the program doesn’t crash. Yay!

However, there is a catch: If two Gadgets both try to create a widget, all of them will have the same options as the first one, because function-local static variables are shared among all instances of a class and are initialized only the first time execution reaches the variable. Whatever flags were passed when you called it the first time get locked into the info, and it doesn’t matter what flags you pass subsequent times because info has already been initialized; it’s not going to initialize again.

If you want it to initialize each time, then you have to modify it each time.

    void CreateWidget(GadgetFlags flags)
    {
        static BasicWidgetInfo info;
        info = {                    
            WidgetKind::Vanilla,
            WidgetFlags::Openable |
            (flags & GadgetFlags::ClosableWidget ?
                WidgetFlags::Closable : WidgetFlags::None)
        };

        auto controller = std::make_shared<BasicWidgetController>(info);

        m_widget = MakeWidget(controller);
    }

This time, we set the values as a step separate from construction, which means that it executes each time, and the info gets updated with the most recent flags.

Of course, this is still a problem if two Gadgets create Widgets with overlapping lifetime, because the two Basic­Widget­Controllers are sharing the same info. At the second call to Create­Widget, its updates to info secretly alter the values being used by the first one.

Plus, of course, if Create­Widget is called by two threads simultaneously, you have a data race on the writes to the info variable, and then the results will be unpredictable.

The underlying problem is that the Basic­Widget­Controller wants to extend the lifetime of its info, but a reference gives you no way to do it, so it has to rely on the kindness of strangers.

One idea would be to put the info somewhere else, so that its lifetime can be extended some other way. Maybe you put it in the Gadget:

struct Gadget
{
    std::shared_ptr<Widget> m_widget;
    BasicWidgetInfo m_info;

    void CreateWidget(GadgetFlags flags)
    {
        m_info = {
            WidgetKind::Vanilla,
            WidgetFlags::Openable |
            (flags & GadgetFlags::ClosableWidget ?
                WidgetFlags::Closable : WidgetFlags::None)
        };

        auto controller = std::make_shared<BasicWidgetController>(m_info);

        m_widget = MakeWidget(controller);
    }

    ⟦ other gadget stuff ⟧
};

Now your job is to make sure that the m_info is not destructed before the last shared pointer to the Basic­Widget­Controller. This is tricky, since you don’t really know when the last shared pointer to the Basic­Widget­Controller will be destructed, although you might have some heuristics given that its lifetime is probably tied to the Widget.

Is there a way to hook into the destruction of the final shared_ptr?

Yes, and in fact we already used that feature without realizing it.

You can use an aliasing shared pointer that points at a Basic­Widget­Controller but whose lifetime controls both a Basic­Widget­Controller and its associated Basic­Widget­Info.

struct BasicWidgetControllerWithInfo
{
    BasicWidgetControllerWithInfo(BasicWidgetInfo const& info) :
        m_info(info),
        m_controller(m_info) {}

    // The m_info must come before the m_controller because the
    // m_controller initializer depends on the m_info.
    BasicWidgetInfo m_info;
    BasicWidgetController m_controller;
};

    void CreateWidget(GadgetFlags flags)
    {
        BasicWidgetInfo info = {
            WidgetKind::Vanilla,
            WidgetFlags::Openable |
            (flags & GadgetFlags::ClosableWidget ?
                WidgetFlags::Closable : WidgetFlags::None)
        };

        auto controllerAndInfo = std::make_shared<BasicWidgetControllerWithInfo(info);

        auto controller = std::shared_ptr<BasicWidgetController>(
            controllerAndInfo, &controllerAndInfo->m_controller);

        m_widget = MakeWidget(controller);
    }

    ⟦ other gadget stuff ⟧
};

We use an aliasing constructor with a pointer to the controller, but telling it to control the lifetime of the Basic­Widget­Controller­With­Info.

Of course, all of this is a problem of the application’s own creation. They should just fix the Basic­Widget­Controller to copy the Basic­Widget­Info instead of taking a reference.

struct BasicWidgetController : WidgetController
{
    BasicWidgetController(BasicWidgetInfo const& info) :
        m_info(info) {}

    WidgetKind GetKind() override { return m_info.kind; }
    WidgetFlags GetFlags() override { return m_info.flags; }

    // Do not customize any dynamic actions.
    void OnOpening() override { }
    ⟦ and so on ⟧

private:
    BasicWidgetInfo /* const& */ m_info;
}

Now the original code works again.

    void CreateWidget(GadgetFlags flags)
    {
        BasicWidgetInfo info = {
            WidgetKind::Vanilla,
            WidgetFlags::Openable |
            (flags & GadgetFlags::ClosableWidget ?
                WidgetFlags::Closable : WidgetFlags::None)
        };

        auto controller = std::make_shared<BasicWidgetController>(info);

        m_widget = MakeWidget(controller);
    }

The post C++ reminder: Function-local static variables are initialized only once, even if it looks like they get initialized multiple times appeared first on The Old New Thing.

Read the whole story
alvinashcraft
8 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Your Coding Agent Needs Observability, Too

1 Share
GitHub Copilot can now export agent telemetry with OpenTelemetry. This post takes a deep dive into that: what the traces may reveal, what data to protect, and how to start monitoring information responsibly.
Read the whole story
alvinashcraft
8 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Random.Code() - Yet Another Accessibility Issue in Rocks With Nested Types

1 Share
From: Jason Bock
Duration: 1:25:40
Views: 4

This always comes back to haunt me in mysterious, unexpected ways. I blame gRPC this time.

https://github.com/JasonBock/Rocks/issues/435

#dotnet #csharp

Read the whole story
alvinashcraft
8 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Daily Reading List – September 28, 2026 (#876)

1 Share

I had a relaxing birthday weekend and was raring to go today. Not surprisingly, this reading list has a handful of AI-related items.

[blog] Experts Lead Experts. Obvious? You’d think so. But not everyone believes that experts should lead experts, and we put “people-only managers” in place.

[blog] Do Angular apps need WebMCP? Can’t an AI agent just figure out a web page through the DOM versus needing the tools provided by WebMCP? Sure, but as this test shows, it consumes more time and tokens.

[blog] Elevating Antigravity agent skills, Part 4: Subagent messaging. Subagents need to know about each other, and be able to communicate. Maybe you used a shared doc or some other way to pass messages. Antigravity has some built-in options.

[article] Nine unlikely trends shaping software development. Fair title. I was skeptical that these would be “unlikely”, but there’s some unexpected industry movement called out here.

[blog] Run decision models on vLLM and Red Hat AI using DiffusionGemma. Red Hat showing how DiffusionGemma makes a pretty good Jev-style decision model option.

[article] Meta announces enterprise AI platform, recruits MongoDB CEO to lead it. Keep an eye on this one. Will enterprises buy core technology from Meta? Don’t rule it out. More here.

[blog] Automating coherent long-form video generation. Today is the least realistic and consistent that AI-driven video generation will ever be. Only getting better.

[blog] Unlock 3x QPS and microsecond latency with Memorystore for Valkey 9.1. This isn’t just a Redis alternative. By itself, Valkey is a top performing database for scaled access.

[article] Apps, Agents, and Aggregation. This is all feeding my confirmation bias, but it’s hard not to notice the trend. We’ll use super-apps that aggregate through agents, generative/personalized UIs for the rest.

[blog] Why your startup needs open models alongside frontier APIs. Good post that outlines workloads where an open model is a good complement to our frontier model use.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:



Read the whole story
alvinashcraft
8 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Trump finalizes rule to make cars less fuel efficient

1 Share
President Donald Trump announces plans to weaken fuel efficiency and emissions rules for cars and trucks in the Oval Office at the White House in Washington, DC, on December 3rd, 2025. | Photo: Getty Images

The US Department of Transportation finalized its plans today to weaken fuel efficiency standards, calling it "among the largest deregulatory actions under the second Trump Administration."

It's a nail in the coffin for Biden-era standards that would have required fleet average fuel economy to reach 50.4 miles per gallon by model year 2031. President Donald Trump's plan requires 34.9 miles per gallon, not much higher than the 30.1-mile-per-gallon target previously set for model year 2024.

Consumer advocacy, health, and environmental groups are incensed

The Trump administration claims its plan would shave $1,300 off the average cost of a n …

Read the full story at The Verge.

Read the whole story
alvinashcraft
12 hours ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories