top | item 10165289

MSBuild is going cross-platform with .NET Core

250 points| kungfudoi | 10 years ago |blogs.msdn.com | reply

134 comments

order
[+] BinaryIdiot|10 years ago|reply
I know MSBuild gets a lot of hate but this is still great news. The end goal of having a .Net project be compile-able on Windows, Linux and Mac is going to be awesome. I'm curious, when everything is finally done, what the adoption rates will be like. Will hard-core Linux users who used Java migrate when it makes sense? Will they avoid it because "M$"?

All good stuff.

[+] fiatjaf|10 years ago|reply
Anyone who does not like MS because of the $ cannot at the same time like Java.
[+] swozey|10 years ago|reply
It will be very nice to be able to do CI/compilation on extremely cheap and fast (to spin up) linux slaves as opposed to requiring an expensive (license, hardware) and slow (miserably slow ec2 boots) Windows servers.
[+] kenbellows|10 years ago|reply
The Mono framework[1] has been pretty popular in some circles for years now, so I imagine a decent amount of adoption can be expected once .Net Core proves stable.

1: http://www.mono-project.com/

[+] naasking|10 years ago|reply
> The end goal of having a .Net project be compile-able on Windows, Linux and Mac is going to be awesome.

Except msbuild can't easily support builds across different version of .NET on the same platform. I hate digging into its needlessly archaic build files.

[+] Touche|10 years ago|reply
.NET was already somewhat popular on Linux for GTK apps. I don't know if you're going to see adoption for web servers unless it can be competitive with Java in performance, which I don't think Mono has traditionally been.
[+] edwinnathaniel|10 years ago|reply
> Will hard-core Linux users who used Java migrate when it makes sense?

Probably only for mobile/desktop app but less likely for back-end/webservice/infrastructure stuff.

Take MSBuild. This is pretty much Ant. Sure, there's NuGet but Ant+Ivy or MSBuild+NuGet combo isn't anywhere close to Maven (despite the XML hate).

Libraries, communities, tools, frameworks of .NET ecosystem is still behind Java.

Unfortunately language features and syntatic sugar alone probably not enough to sway these users. Besides, Java and C# are very similar, technically there's less reward in learning a very similar language.

[+] godzilla82|10 years ago|reply
Do you have any practical experience of using MSBuild? If you have ever worked on MSBuild and other build tools (e.g. ant, maven, even make for that matter), you would have noticed how difficult it is to write or extend simple build tasks in msbuild. Have you ever tried to use MSBuild to build anything on a machine that doesnt have visual studio installed? If you use any other ide, the separation of IDE and the compiler is very clear. Try figuring out the build parameters that Visual studio uses to compile your code.
[+] lmm|10 years ago|reply
It's a whole different ecosystem - it's not like Scala where I can sling in one class on an existing Java codebase. .net isn't just its own VM, it's its own IDE, its own build tool, its own packaging model....

For little standalone pieces - the kind that people write in D or OCaml because they want to - I can see .net being used on linux. But I don't see anyone migrating an enterprise Java codebase - it's just too much effort for too little gain.

[+] tomjen3|10 years ago|reply
1 year ago, yes. C# is awesome as a language but I don't see a reason to switch to .net when the JVM has Kotlin, which is nicer than C#, but still super lightweight and thoroughly pragmatic.
[+] rbanffy|10 years ago|reply
Does building .net projects require MSBuild?
[+] cptnbob|10 years ago|reply
Now I can hate every moment of its existence on more than one platform!

Having dealt with it for years, it's unadulterated pain and bad performance and nothing else.

[+] CydeWeys|10 years ago|reply
I used to work at a mostly-Microsoft shop and I cannot fathom why anyone would want to deal with MSBuild for other platforms. There are so many better alternatives. And as bad as MSBuild is for building .NET stuff, at least it's the right tool for that job. Trying to shoehorn it into some other stack entirely, which you know is just going to cause even more pain? No. Just no.
[+] jahnu|10 years ago|reply
The thrill of undocumented property sheets! The rush of accidentally getting a build to work while using a genetic algorithm to try every possible combination of configuration settings!

What's not to love!?

[+] serve_yay|10 years ago|reply
Hoo boy, MSBuild was always by far my least-favorite part of being a .NET developer. I would like to flippantly say they should just throw it away and replace it, but probably much too late for that.
[+] Someone1234|10 years ago|reply
I have no strong opinions for or against MSBuild. What is it that you dislike about it? Or what is it that other tools do that MSBuild fails to do?

PS - I have done a lot of .Net development, but rarely did anything beyond the basics with MSBuild directly (mostly via Visual Studio, or took the pre-generated command line and stuck in a script).

[+] CmonDev|10 years ago|reply
Fork it and change it to your taste! Welcome to open source.
[+] dblock|10 years ago|reply
While at Microsoft in early 2000s when MsBuild was first seen (I helped with the initial integration into CoreXT) I attempted to find the person responsible for <Output TaskParameter="Y" PropertyName="X" /> to scream at them. Unfortunately the repo doesn't have pre-open-source history :(
[+] gnoway|10 years ago|reply
The talk about first-class support for packages and dependency comprehension is interesting. At a minimum, having a native NuGet task - or have it be default behavior of the MSBuild task - vs. having to run restore/install via Exec would be very nice.

MSBuild is not a great tool, but it's not awful either. I would not be depressed or angry at having to use it to build something on Linux.

[+] aaronbrethorst|10 years ago|reply

    MSBuild has a long history: It started out
    in 2005 as a part of the .NET Framework
    itself, and became an integral component
    of Visual Studio over time. Most recently,
    Microsoft’s build engine found a new home
    in the Tools for Software Engineers (TSE)
    team in Microsoft’s Cloud and Enterprise group.
What's funny, though, is that the MSBuild team was originally part of Visual Studio Core, which also owned devenv.exe, the Visual Studio SDK, Projects and Solutions, the editor, and—perversely—Visual SourceSafe.
[+] drfritznunkie|10 years ago|reply
One can only hope this effort improves the miserable MSBuild documentation. Exposure to the .Net ecosystem and MSBuild are recently events for me, and I can't say I've had a day where I've not cursed out either the documentation for Azure or MSBuild. Thank god I found a single reference in a single engineering blog post to the very very beta at the time ARM Resource explorer many months ago (resources.azure.com). It was the only way I was able to reverse engineer the ARM provisioning templates since nothing was documented.

Now if the people responsible for all this awesome effort in cross platform tools and open sourcing products could go down to the licensing and support divisions and bust some heads, I might be willing to continue working on the platform. But as it is, I've been playing 10 hour Bangalore ping-pong for almost a month now trying to get them to acknowledge the Azure support contract that was paid for a month before that! Ultimately, if Microsoft doesn't fix their baroque and Kafkaesque licensing and support process, all this work is going to be for naught.

[+] akshayB|10 years ago|reply
This is good news but little bit too late. Microsoft strategy of sticking with windows to slow down Linux and Mac back fired . If they opened up .Net few years back cross platform app development landscape would have been totally different today.
[+] wsc981|10 years ago|reply
I'm not sure Microsoft came too late to the party. Perhaps MSBuild is a bit crappy (I don't know, never used it), but I can imagine Roslyn becoming more useful now on other platforms since it's open sourced. It'll be great that one can be sure the runtime behaves the same on all platforms Roslyn will run on. And it'll also be nice if new runtime features will be available on every platform at (more or less) the same time. I think Roslyn could have a nice future ahead. Personally speaking, I find writing C# is much more enjoyable as writing Java.

And who knows, maybe someone will build a decent MSBuild replacement. Or perhaps the Xamarin guys already have a nice alternative.

[+] UK-AL|10 years ago|reply
What do you mean totally different? Outside of silicon valley and start up world .net and Java dominate.
[+] camdenre|10 years ago|reply
I don't know why you think it is too late? Do you think people aren't going to embrace cross-platform .NET?
[+] faragon|10 years ago|reply
In my opinion, Microsoft should think about making their compilers/linkers make-friendly, e.g providing cross-compilers ("cl.exe", separated compiler and linker).
[+] wangii|10 years ago|reply
what's the core advantage over make/rake?
[+] rblatz|10 years ago|reply
Historically the project files in C# apps included msbuild configuration. Also a lot of nuget packages include a.targets file, which also contains msbuild configuration. For compatibility reasons if you are using the .net ecosystem you need msbuild.
[+] beastway|10 years ago|reply
Why would I want to deal with MS on any other platform? I want nothing to do with that company out of principal and I hope we can do a equally harmful shut out of MS in the future, they deserve their own medicine.

No, into the trash it goes.

[+] romanovcode|10 years ago|reply
>Why would I want to deal with MS on any other platform?

Because C# is a great language.

[+] rjbwork|10 years ago|reply
You can't win if you're not going to reward companies for good behavior.
[+] BigChiefSmokem|10 years ago|reply
Because Microsoft keeps me employed and making money.
[+] m0v_eax|10 years ago|reply
There are people other than you that matter.