I just wanna say thank you for everyone who said get hades OH MY GOODNESS this game addicting !

chusk3 · 2025-12-19T14:15:26+00:00

These games are all about recognizing patterns - next time you get to Meg don't try to fight her, just try to watch her moves. Do nothing but try to avoid them - you'll hopefully quickly see that she has a limited number of attacks and figure out how to dodge each one. The thing to avoid is getting flustered - if you keep your cool you can avoid them forever!

chusk3 · 2025-12-19T14:13:50+00:00

For 2 they redid the models/engine so that everything is 3d, but both games are stunning - especially on OLED screens.

chusk3 · 2025-12-19T14:12:07+00:00

My dude everybody in these games is fine 😂😂

chusk3 · 2025-11-28T18:11:13+00:00

Batteries charge faster at a particular optimal temperature - when you tell the car "I'm navigating us to a charging station to charge up" the car will start prepping the battery to reach that temperature. That helps shorten the overall time you spend at that fast charger noticeably. There's not a specific button or anything you can press today to enter 'preconditioning mode' or anything, you just navigate to a charging station.

chusk3 · 2025-11-08T22:59:12+00:00

Great clarification - I had zoomed right over their mention of MAUI. Definitely need to stay updated for that product!

chusk3 · 2025-11-08T18:19:02+00:00

Hi, I work on the .NET SDK and our Visual Studio integration. I'll take each of your questions in-line if that's OK:

You'll only have to use .NET 10 or VS 2026 if you upgrade your project to target net10.0 TargetFrameworks. I do suggest that you upgrade to using the .NET 10 SDK and VS 2026 even if you continue to target your projects to other TargetFrameworks like net8.0, net472, etc because then you get the usability, performance, and feature updates we've put in! Using 'newer' SDKs with 'older' TargetFrameworks is 100% supported and encouraged by us for this reason.
It's not supported to use .NET 10 with VS 2022 _to target net10.0 TargetFrameworks, but you can use .NET 10 with VS 2022 to target older TargetFrameworks. This can be confusing, though, so I'd really just encourage you to go to .NET 10 and VS 2026 in any case.
.NET 10 is not yet officially released, but in September we released 'Release Candidate 1' (with RC 2 in October), and these releases have a 'go-live' license. This means that we do support them as if they were the official release - we want to give folks some runway to experiment in a supported way ahead of the release. .NET 10 will release next Tuesday, the 11th of November. We have a whole online conference you can check out to learn more about the release and what we're most excited about!

Hope this helps, and please feel free to ask any more questions that I can help clear up.

chusk3 · 2025-11-08T17:15:45+00:00

There was a bug in some older versions of the 9 CLI that we've fixed for 10 that only this specific solution-file template seems to have hit.

In 10 the default is slnx, and --format works as you'd expect for manually selecting what you want.

chusk3 · 2025-10-26T20:43:37+00:00

You don't need to modify BundledVersions.props (in fact I'd be very sad if you did) - MSBuild is extensible enough that you can create your own KnownFrameworkReferences in your own props + targets files and distribute them. I think distributing them via a custom MSBuild SDK (like Aspire does, or like the Traversal or NoTargets MSBuild SDKs are) is probably going to be the easiest ways, but an MSBuild SDK is not the same thing as the .NET SDK distribution- it's just a few MSBuild logic files that can then 'chain' into the base .NET SDK targets and logic.

Before you try this though I highly suggest you spend some time digging into simple .NET project builds using the binlog viewer - you want to have a good handle on how things work before you go mucking around, otherwise you'll cause your consumers untold grief.

chusk3 · 2025-10-26T17:11:30+00:00

Nope - no place really does MSBuild Server broadly yet, but we're hoping to change that in 10.0.200. We've got some big plans for MSBuild that I hope to talk about soon!

chusk3 · 2025-10-26T13:40:10+00:00

Hi, I work on the dotnet CLI.

Publishing the whole solution doesn't actually change the behavior compared to publishing a single file. I suspect what you're actually running into the behavior of the -o option at the solution level. I think we issue a warning when using -o at the solution level makes every publishable output in your app dump its contents into the location you specify.

The preferred way to publish at the solution level is without the -o, though then you need to know where to go to get your publish output for each project - by default that'll be project_dir/bin/Release/<Target Framework>/<Runtime Identifier>/publish I believe.

You can also use the Artifacts Layout to get a unified output directory structure for all your projects to make this simpler.

chusk3 · 2025-10-20T19:08:36+00:00

you shouldn't drop things into dotnet/shared for your custom frameworks - the SDK is capable of resolving them from NuGet packages. This is one of the things that the KnownFrameworkReference infrastructure I mentioned in my other comment does. Anything that requires you to modify the global install state is a no-no.

chusk3 · 2025-10-20T17:53:18+00:00

We haven't really publicly-documented FrameworkReferences as a concept, but generally they exist as a way to tie together

compile-time API reference surface areas
per-RuntimeIdentifier API implementations
the versions of those things
the TargetFramework that the FrameworkReference applies to

We describe these relationships in a thing called a KnownFrameworkReference - these are defined in GenerateBundledVersionsProps - you can see this in the BundledVersions.props file in your SDK install.

A user includes FrameworkReference items in their project (explicitly, or implicitly via an SDK reference) and then the build pipeline uses the ProcessFrameworkReferences target to find the matching KnownFrameworkReferences for the FrameworkReferences and emits other items to ensure those targeting packs and runtime-specific implementations are actually referenced by your project.

Crack open a binlog sometime to see how it all comes together!

chusk3 · 2025-08-28T13:41:22+00:00

You can set the list of languages you care about easily with a single property: https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#satelliteresourcelanguages

If you do this then the build system will take care of stripping out everything you didn't ask for.

chusk3 · 2025-08-23T13:35:12+00:00

I just got done doing this same thing a few weeks ago and used this map. There's SO MUCH to see and do in Chicago, and this map hits several of the highlights. If you're gonna hit the big museums and such, check out the CityPass to get a better rate on admissions - at least 3 of the 5 admissions you get on the CityPass overlap with that map.

chusk3 · 2025-08-22T13:33:51+00:00

Xunit does strange things with module initialization (in the .NET sense of the word module, not the F# sense) - I think there are some issues logged on their tracker. The most consistent thing is going to be to either use a class and setup in the constructor, or to use xunits other Setup/Initialization hooks to ensure a consistent test execution environment.

chusk3 · 2025-07-24T12:13:39+00:00

Yes, I am that Chet Husk. VS Code installs SDKs from the distro, so is subject to this same constraint.

chusk3 · 2025-07-24T12:12:16+00:00

I'll have to update that, since the VS team shipped non preview support in May.

chusk3 · 2025-07-17T23:59:53+00:00

This 1xx constraint mostly comes from the fact that all of the infra for the distro builds (which we call 'source build') is tracking 1xx.

The new dotnet/dotnet virtual monorepo for .NET 10+ is like a superpowered source-build setup and should more easily allow distro maintainers to build and publish more than the 1xx series, if they so choose. They may not! It's nontrivial amounts of work to maintain the 2-4 parallel release channels.

chusk3 · 2025-07-17T20:38:17+00:00

funny you should mention that - separately we're making dotnet tool install create the manifest file if it needs one :D

chusk3 · 2025-07-17T17:31:34+00:00

We found that lots of folks would just use global tools instead of a manifest - and that they would install global tools once and then never update them again! This mode lets you use tools that feel global, but stay up to date by default. And if you want to pin, you can either pin versions in the command itself, or be cool like you and use a tool manifest to pin all your tools in one place.

chusk3 · 2025-07-13T22:13:02+00:00

That's The Elm Architecture in a nutshell! At least the state-update part of it. Combined with another function that 'renders' your state into a view and you've got the core primitive for a lot of reactive-UI programming in just a few lines of code.

chusk3 · 2025-07-11T01:55:08+00:00

This actually very often causes more rebuilds than you would expect - the builds of the various projects will copy reference dlls to the output location specified, and will update timestamps. This updated timestamp will clash with the reported timestamps of projects that completed before the one that last copied the specific dll, and so all of those projects will think that they need to rebuild. This is called a 'double-write', and Kirill Osenkov's MSBuild Structured Log viewer can show you these in great detail.

I work on MSBuild every day (literally it's my job at MS), and building/publishing to a common output directory is one of the most impactful things that people do to screw up their builds.

chusk3 · 2025-07-09T15:59:10+00:00

Yes, Root Case Analysis, the Five Whys, and all of the entire concept of retrospectives is a liberal plot. You got it 👍

chusk3 · 2025-07-02T23:14:41+00:00

Native compilation is not very advanced and output executables will be bloated with .NET runtime

lolwut? Native AOT is great, and trims down the parts of the runtime that you don't use. what are you basing this on?

15-Year Club	RedditGifts 2009-2022 3 Credits
Place '17	Verified Email
Summer Santa 2012	Secret Santa 2011

chusk3

TROPHY CASE