Stats
dotnet/msbuild is an open source project licensed under MIT License which is an OSI approved license.
MSBuild Alternatives
Similar projects and alternatives to MSBuild based on common topics and language
-
EmptyLicensesLicx
Easy continuous integration of apps using third-party controls that rely on licenses.licx files
-
FlubuCore
A cross platform build and deployment automation system for building projects and executing deployment scripts using C# code.
-
Scout APM
Scout APM - Leading-edge performance monitoring starting at $39/month. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.
-
-
Roslyn
The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
-
Prism
Prism is a framework for building loosely coupled, maintainable, and testable XAML applications in WPF, Xamarin Forms, and Uno / Win UI Applications.. (by PrismLibrary)
-
EFCorePowerTools
Entity Framework Core Power Tools - reverse engineering, migrations and model visualization for EF Core
-
Posts
- Fix Legacy Msbuild Issues
-
How do build events differ between Visual Studio for Windows and Mac?
MSBuild and the Roslyn compiler are cross-platform. So the short answer is yes.
-
Generally speaking, C# relies on either third-party implementations like http://www.omnisharp.net or Microsoft distributions, which on Windows is largely distributed via Visual Studio Downloads page, including the Tools for Visual Studio package: https://visualstudio.microsoft.com/downloads/ Are there other releases of msbuild, for example? Yes: https://github.com/dotnet/msbuild/releases But are they separate from releases of Visual Studio? No, as the release notes indicate. If you want to live on the bleeding edge of .NET development -- and I do recommend this -- you'll end up in the Preview channel of Visual Studio: https://visualstudio.microsoft.com/vs/preview/ and if you want to use Visual Studio Code instead, welcome to OmniSharp or similar "mostly compatible" solutions. It's totally fine until it's not, and it's definitely not portable or open enough -- yet. I look forward to the day when Visual Studio is fully open source because they can include subscriptions on top or something. That'll be the day when VS and VS Code could begin to merge a bit, at least for development on Microsoft platforms. But that hasn't happened yet, and they're rebuilding Visual Studio in Eclipse on other platforms to better support cross-platform development the same way Rider supports other platforms for JetBrains IDEs. It's a stop-gap until the fully-open-source versions of VS and VS Tools are finally available. I suspect they're waiting for .NET 5 or later, at this point...
They're undoing the split between Core and .NET Framework by suggesting that they'll ship both within .NET 5 using shims or implementations of drop-in replacements for .NET Framework code to use. Imagine if after dropping Python 2 support there was a mode that scanned for Python 2 code and enabled it again, on a file-by-file basis, to work with newer Unicode strings using some kind of translation layer in the runtime. That's kind of what's happening here, I think, but maybe more lightweight than suggested. Legacy .NET Framework code still deprecated, but interoperability libraries will ship as part of the runtime or SDK, will have some amount of shims available. I haven't followed the details closely enough to say more than this, though. I last looked into it a few months ago.