Chet Husk

i think this is key. taking the deal would amount to taking the blame. it would turn a clear political victory into an unambiguous defeat.

Senator Schumer is no longer effective and should be replaced. If you can’t lead the fight to stop healthcare premiums from skyrocketing for Americans, what will you fight for?

Now that #dotnet code coverage will be coming to #visualstudio professional 2026, is there perhaps also any info on Testcase Impact Analysis ( #TIA) for #azuredevops CI/CD pipelines (as far as I can tell it was never supported for .Net Core?)

Saw @justinhawkins.ridesagain.com and The Darkness tonight at Emo's for the first time and HOLY HELL what a show! Amazing performers, brilliant crowd work, and an electric set. Gonna be smiling for a long time after that one 🤘

Zohran font generator sign that says Veggie McRibs for America from https://homes.luddy.indiana.edu/ccshan/for/for.html

them: you're on bluesky? what do you post about?

me: policy ideas, mostly

Could we use something like github.com/baronfel/msb... to prototype/explore? One thing I found with this exporter is that there's SO MUCH data that you drown pretty quickly. Having a better idea of what's actually relevant for specific scenarios would help me a lot.

Woah woah woah let's not get crazy now. We don't have Activity reporting of any kind yet in MSBuild so that's a bigger lift.

What would you want to use that data for? I've had this on my personal backlog for a long time but haven't found a good motivating end to end use case.

In a structured way that we can grab. Imagining something like a `--logger:@nuget:MyLogger` kind of experience, where something about the _identifier_ tells tooling how to locate/acquire it. Of course there are other pathways too.

I was chatting a bit with @joelverhagen.com about related stuff a while back for my combo tool+library idea. There's some package validation stuff on the NuGet client (and maybe server?) that may need to be loosened, but there's a world where you can upload packages containing loggers...

If I don't make @rainer.sigwald.org sigh heavily in consternation, is it even a weekend?

No because I have to do _real_ work during the week - weekends are for crazy hacking around!

Oh I just found it, no worries :)

It doesn't at all, and I didn't know it was even a thing. Time to go ping some partner teams I guess!

bob ross says " we don t make mistakes we just have happy accidents " Alt: Delightful painter Bob Ross says "we don't make mistakes we just have happy accidents" while smiling at the viewer. His demeanor lets you know that everything's going to be all right.

Builds never fail, they're just happy little accidents

Great! My current approach is to wrap each projects' output in a separate collapsible log group, report warnings and diagnostics via provider-specific output formatting, and where possible (like with GitHub STEP_SUMMARY) emit a summary.

That's actually already something that should work - VSCode has shipped a 'problem matcher' for MSBuild for years now. When you define a custom task in tasks.json, you can specify the '$msCompile' matcher to make it all work. For C#/DevKit they report problems directly and skip this process.

Another thing I just thought of is that putting the loggers directly in MSBuild also enables them to be used with folks that build via framework msbuild.exe still (c++ being a big chunk of this) - if we pushed this stuff up into the dotnet SDK/CLI layer it'd be harder to reuse for those folks.

What would you want to see out of it?

The default console loggers can be explicitly disabled via the command line, but then you have to teach the CI/CD pipelines how (injecting command line args? env var?) and when (only when using .NET SDK X.Y.ZZZ or higher?) it's safe to do that.

If we solved distribution, then the final hurdle is 'exclusivity' - you don't want these loggers _and_ the default console/terminal loggers to both be activated - so a completely-external logger would need to be able to signal to the engine that the default console output logger is unnecessary.

Technically yes, but there are a few things that make the answer 'no' practically speaking. The logger implementations could be completely external, but distributing MSBuild loggers is a pain - there is no good mechanism, because our typical way of shipping bits (NuGet) happens _during the build_.

Hey #dotnet, would you like it if #msbuild (and dotnet build, etc) natively integrated with your CI/CD pipelines for integrated warning/error reporting and such? I've vibe-coded some stuff here that might be interesting to folks: github.com/dotnet/msbui...

This is why I set up Sunshine on my PC and Moonshine on my android TV - now I can play games on my TV that are being run on my PC, with a controller from my couch. Took a little bit to set up, but not too much at all.

The decision paralysis for instruments is _real_.

Interested in working in .NET Tooling? My team is hiring for a few roles. This is a great to impact the .NET ecosystem, work with devs all across Microsoft and help drive the .NET platform forward.

jobs.careers.microsoft.com/global/en/jo...
jobs.careers.microsoft.com/global/en/jo...

I see this specific issue as one instance of the more general problem: we need to figure out what the output format for CLI operations should be for LLMs of all kinds. This is something that Rich and I have been looking into a bit already, but hope to focus on after the 10 release.

The token use comes from the live updating timer in the terminal logger display- the act of rewriting that is a bunch of VT codes that llms generally don't know how to interpret well, and just looks like raw text to them. Since that view updates at either 30 or 60 FPS, it's a lot of noise.

For my info, how long are the builds that you're triggering that cause this behavior? We've mostly been testing with token efficiency of the final build output, which means we've been removing information that isn't essential. Supporting long running builds would be counter to that in some ways.

This is actually doable! In .net 10 we added detection for when we are called in an LLM context. Right now we just use it to disable live update in terminal logger, but it could just as easily trigger other output options. We don't have strong evidence for what is best, so feedback is great.

And on a separate, third topic, if we just make builds faster then it's less likely that you hit this idle notification at all. That's the primary unit of work going on currently. We hope multi-threaded mode will unlock a new level of performance. Eval caches that server mode enables will help too.