💡 Pro tip for .NET devs:
If you randomly hit file locking issues during builds, lingering MSBuild worker nodes may be the cause.
🧹 Kill them:
dotnet build-server shutdown
🛠 Disable them:
setx MSBUILDDISABLENODEREUSE 1
#dotnet #MSBuild #VisualStudio #Roslyn
If you randomly hit file locking issues during builds, lingering MSBuild worker nodes may be the cause.
🧹 Kill them:
dotnet build-server shutdown
🛠 Disable them:
setx MSBUILDDISABLENODEREUSE 1
#dotnet #MSBuild #VisualStudio #Roslyn
November 11, 2025 at 2:59 PM
💡 Pro tip for .NET devs:
If you randomly hit file locking issues during builds, lingering MSBuild worker nodes may be the cause.
🧹 Kill them:
dotnet build-server shutdown
🛠 Disable them:
setx MSBUILDDISABLENODEREUSE 1
#dotnet #MSBuild #VisualStudio #Roslyn
If you randomly hit file locking issues during builds, lingering MSBuild worker nodes may be the cause.
🧹 Kill them:
dotnet build-server shutdown
🛠 Disable them:
setx MSBUILDDISABLENODEREUSE 1
#dotnet #MSBuild #VisualStudio #Roslyn
It's time for the multi-targeting finale, dear dedicated #dotnet developers.
We're concluding our journey of packing #MSBuild .props and .targets for versioning of #Roslyn components like #CSharp analyzers.
Date: 2025-11-10 (Monday)
Time: 18:00 (UTC)
#2codeOrNot2code
www.youtube.com/watch?v=RuOl...
We're concluding our journey of packing #MSBuild .props and .targets for versioning of #Roslyn components like #CSharp analyzers.
Date: 2025-11-10 (Monday)
Time: 18:00 (UTC)
#2codeOrNot2code
www.youtube.com/watch?v=RuOl...
2code ^ !2code [S2025E13] Multi-targeting Roslyn Components - Part 3
YouTube video by FlashOWare
www.youtube.com
November 10, 2025 at 9:20 AM
It's time for the multi-targeting finale, dear dedicated #dotnet developers.
We're concluding our journey of packing #MSBuild .props and .targets for versioning of #Roslyn components like #CSharp analyzers.
Date: 2025-11-10 (Monday)
Time: 18:00 (UTC)
#2codeOrNot2code
www.youtube.com/watch?v=RuOl...
We're concluding our journey of packing #MSBuild .props and .targets for versioning of #Roslyn components like #CSharp analyzers.
Date: 2025-11-10 (Monday)
Time: 18:00 (UTC)
#2codeOrNot2code
www.youtube.com/watch?v=RuOl...
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.
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.
November 8, 2025 at 9:54 PM
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.
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.
How does this relate to the Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll? (Which provides MSBuild logging integration for AzureDevOps)
November 8, 2025 at 6:53 PM
How does this relate to the Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll? (Which provides MSBuild logging integration for AzureDevOps)
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.
November 8, 2025 at 6:38 PM
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.
November 8, 2025 at 6:11 PM
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.
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_.
November 8, 2025 at 5:31 PM
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_.
Is MSBuild’s logging infrastructure sufficiently pluggable that these loggers could exist outside of MSBuild entirely?
November 8, 2025 at 5:24 PM
Is MSBuild’s logging infrastructure sufficiently pluggable that these loggers could exist outside of MSBuild entirely?
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...
November 8, 2025 at 5:20 PM
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...
MSBuild, and the log viewer from msbuildlog.com
November 7, 2025 at 9:03 PM
MSBuild, and the log viewer from msbuildlog.com
Wow that actually works. It's surprisingly nice, kind of like it should have always been this way.
Hooking into Visual Studio and MSBuild was way easier than I thought, but calling NuGet through the client SDK was way harder so I used a different technique. I expected the inverse.
Hooking into Visual Studio and MSBuild was way easier than I thought, but calling NuGet through the client SDK was way harder so I used a different technique. I expected the inverse.
November 7, 2025 at 11:17 AM
Wow that actually works. It's surprisingly nice, kind of like it should have always been this way.
Hooking into Visual Studio and MSBuild was way easier than I thought, but calling NuGet through the client SDK was way harder so I used a different technique. I expected the inverse.
Hooking into Visual Studio and MSBuild was way easier than I thought, but calling NuGet through the client SDK was way harder so I used a different technique. I expected the inverse.
New in MSBuild Structured Log Viewer:
property trail showing reads and writes during evaluation, in order:
github.com/KirillOsenko...
If you've ever had ordering issues where someone reads your property before you wrote to it, this is the tool for you.
property trail showing reads and writes during evaluation, in order:
github.com/KirillOsenko...
If you've ever had ordering issues where someone reads your property before you wrote to it, this is the tool for you.
November 7, 2025 at 3:04 AM
New in MSBuild Structured Log Viewer:
property trail showing reads and writes during evaluation, in order:
github.com/KirillOsenko...
If you've ever had ordering issues where someone reads your property before you wrote to it, this is the tool for you.
property trail showing reads and writes during evaluation, in order:
github.com/KirillOsenko...
If you've ever had ordering issues where someone reads your property before you wrote to it, this is the tool for you.
As much as I'd like our builds to be instant, we're pushing the limits of what Roslyn and msbuild can do. All that's really required here is a better way for the LLM to know that the build is still running, and that it's not "idle". It can't know because it's only checking terminal output to tell
November 2, 2025 at 2:17 PM
As much as I'd like our builds to be instant, we're pushing the limits of what Roslyn and msbuild can do. All that's really required here is a better way for the LLM to know that the build is still running, and that it's not "idle". It can't know because it's only checking terminal output to tell
Yep! The big problem is that for many actual builds dotnet cli doesn't actually know anything about them. All of the actual work and knowledge about what is happening is passed directly through to MSBuild.
We need MSBuild at the CLI to be able to act as an actual build server.
We need MSBuild at the CLI to be able to act as an actual build server.
November 2, 2025 at 2:09 PM
Yep! The big problem is that for many actual builds dotnet cli doesn't actually know anything about them. All of the actual work and knowledge about what is happening is passed directly through to MSBuild.
We need MSBuild at the CLI to be able to act as an actual build server.
We need MSBuild at the CLI to be able to act as an actual build server.
msbuild、wine とかで動かへんか？
November 1, 2025 at 2:02 AM
msbuild、wine とかで動かへんか？
You can use the more verbose Sdk element if you want it to look more important.
However, do know that any of those libraries from NuGet packages can also bring along custom build scripts that will run in MSBuild doing whatever they want.
Sdk-style projects use that very mechanism to do their work.
However, do know that any of those libraries from NuGet packages can also bring along custom build scripts that will run in MSBuild doing whatever they want.
Sdk-style projects use that very mechanism to do their work.
October 31, 2025 at 6:50 PM
You can use the more verbose Sdk element if you want it to look more important.
However, do know that any of those libraries from NuGet packages can also bring along custom build scripts that will run in MSBuild doing whatever they want.
Sdk-style projects use that very mechanism to do their work.
However, do know that any of those libraries from NuGet packages can also bring along custom build scripts that will run in MSBuild doing whatever they want.
Sdk-style projects use that very mechanism to do their work.
It's kind of scary that MSBuild can pull in code from the internet...who knows what the security implications might be!?
October 31, 2025 at 6:40 PM
It's kind of scary that MSBuild can pull in code from the internet...who knows what the security implications might be!?
Yeah, it was a little painful to no longer build an install package for WiX using WiX. But the developer experience is so much better; it's hard to argue against the MSBuild Sdk.
October 31, 2025 at 3:15 PM
Yeah, it was a little painful to no longer build an install package for WiX using WiX. But the developer experience is so much better; it's hard to argue against the MSBuild Sdk.
Thanks. Perhaps because I was in "building an installer" mindset I was expecting to find a .msi to download (as with WIX 3.14). Clearly MSBuild does the magic in the background (provided you have internet access).
October 30, 2025 at 5:52 PM
Thanks. Perhaps because I was in "building an installer" mindset I was expecting to find a .msi to download (as with WIX 3.14). Clearly MSBuild does the magic in the background (provided you have internet access).
And it's good you found the Quick Start documentation. So I'll get the team to add a blurb at the top of it for WiX v3 users that the MSBuild SDK is all you need now.
October 30, 2025 at 4:22 PM
And it's good you found the Quick Start documentation. So I'll get the team to add a blurb at the top of it for WiX v3 users that the MSBuild SDK is all you need now.
Yep. It just works. Pick the version you want (6.0.2 is the latest), then `dotnet build` or `msbuild -Restore`or build in VS. It'll do the right thing automatically.
The experience is so much better, I guess it seems too good to be true?
The experience is so much better, I guess it seems too good to be true?
October 30, 2025 at 4:06 PM
Yep. It just works. Pick the version you want (6.0.2 is the latest), then `dotnet build` or `msbuild -Restore`or build in VS. It'll do the right thing automatically.
The experience is so much better, I guess it seems too good to be true?
The experience is so much better, I guess it seems too good to be true?
Yes, I saw the "Get Started" button linking to the documentation.
So the <Project Sdk="WixToolset.Sdk/6.0.0"> line in the .wixproj somehow magically downloads the app?
Does it also keep it up to date if I change 6.0.0 to 6.0.2?
I don't understand how MSBuild SDK works.
So the <Project Sdk="WixToolset.Sdk/6.0.0"> line in the .wixproj somehow magically downloads the app?
Does it also keep it up to date if I change 6.0.0 to 6.0.2?
I don't understand how MSBuild SDK works.
October 30, 2025 at 2:29 PM
Yes, I saw the "Get Started" button linking to the documentation.
So the <Project Sdk="WixToolset.Sdk/6.0.0"> line in the .wixproj somehow magically downloads the app?
Does it also keep it up to date if I change 6.0.0 to 6.0.2?
I don't understand how MSBuild SDK works.
So the <Project Sdk="WixToolset.Sdk/6.0.0"> line in the .wixproj somehow magically downloads the app?
Does it also keep it up to date if I change 6.0.0 to 6.0.2?
I don't understand how MSBuild SDK works.
Ahh, you don't really download and install WiX anymore. It's distributed as an MSBuild SDK. That's why the big orange buttons on our site say, "Get Started" and link to the documentation on how to use the SDK.
If you use HeatWave, creating (or migrating) a project handles everything for you.
If you use HeatWave, creating (or migrating) a project handles everything for you.
October 30, 2025 at 1:53 PM
Ahh, you don't really download and install WiX anymore. It's distributed as an MSBuild SDK. That's why the big orange buttons on our site say, "Get Started" and link to the documentation on how to use the SDK.
If you use HeatWave, creating (or migrating) a project handles everything for you.
If you use HeatWave, creating (or migrating) a project handles everything for you.
im this close to drawing a salt circle and praying to whatever demon lives in MSBuild
October 30, 2025 at 12:24 AM
im this close to drawing a salt circle and praying to whatever demon lives in MSBuild
I forcibly remove literally every reference to any #Apple product, for the entire source tree, then MSBuild globs the deleted directories somehow and errors out.
Performed a full git restore to the head, and for some reason UnrealBuild breaks entirely. Won't even try compiling.
Performed a full git restore to the head, and for some reason UnrealBuild breaks entirely. Won't even try compiling.
October 29, 2025 at 5:02 PM
I forcibly remove literally every reference to any #Apple product, for the entire source tree, then MSBuild globs the deleted directories somehow and errors out.
Performed a full git restore to the head, and for some reason UnrealBuild breaks entirely. Won't even try compiling.
Performed a full git restore to the head, and for some reason UnrealBuild breaks entirely. Won't even try compiling.