
MSBuild is going cross-platform with .NET Core - kungfudoi
http://blogs.msdn.com/b/dotnet/archive/2015/09/03/msbuild-is-going-cross-platform-with-net-core.aspx
======
BinaryIdiot
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.

~~~
tomjen3
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.

~~~
CmonDev
Cool! How would you build an app for iOS and WinPhone using Kotlin?

~~~
wtetzner
Don't know about Windows Phone, but for iOS you could use RoboVM.

[http://robovm.com/](http://robovm.com/)

------
cptnbob
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
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.

~~~
cptnbob
What's even worse is that I recently jumped into asp.net 5 and tripped over
three build systems and a pile of cack just trying to get it off the ground.
Now msbuild as well!?!

Also its not even the right tool to build .net stuff. Add the shoddy
dependency resolution steps plus the shitty performance of NTFS on lots of
small files (MFT contention) we have to wait 8 minutes for a build. I wrote my
own system in powershell and we're down to two minutes. Also, powershell sucks
awfully too but that's another story.

Frustratingly I've played around with golang on and off for around two years
now. I've not written anything significant in it yet (lack of opportunity more
than anything else). You know what's cool about it?

I mastered the entire build system in about an hour and its the same on all
platforms and it _just works_ and works quickly.

MS: go look there for some inspiration. Building stuff for the CLR is
horrible.

~~~
TheWiseOne
Something like Cake ([http://cakebuild.net/](http://cakebuild.net/)), Bau
([https://github.com/bau-build/bau](https://github.com/bau-build/bau)) or
Psake ([https://github.com/psake/psake](https://github.com/psake/psake)) are
much better than using MSBuild.

------
serve_yay
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
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).

~~~
serve_yay
I really hated the language you use to describe build tasks. It is a very
frustrating mix of declarative and imperative syntax. And of course, who
_wouldn 't_ want to write code in XML?! (XML, the markup language, the one we
use for marking up information like documents and records.)

I was doing fairly complicated tasks with it years ago, and it's just one of
those technologies that feels like it is fighting you at every turn. This was
for continuous integration stuff and developer-productivity tools, not "open
up Visual Studio and click the button". Thankfully much of that has been
obviated over the years by things like NuGet and Octopus coming around.

~~~
useerup
> I really hated the language you use to describe build tasks.

Yup. For some reason that escapes rationality, MS chose to control the build
through Workflow Foundation. And they build a horribly complicated WF
"script". Pretty much universally hated.

But you may be pleased to know that they have now abandoned that, and each
build task can now be described pretty much by the scripting language of your
choosing.

~~~
serve_yay
Ah, that is nice. .NET seems to have a wonderful property where even if they
start out with something dumb, they eventually come to their senses and do the
right thing. Sure can take a while to get there, though.

------
dblock
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 :(

------
clayrsmith
This is just a part of MS larger new open source initiative for legacy
systems. ASP.net 5+ projects will be using DNX
[https://github.com/aspnet/Home/wiki/DNX-
utility](https://github.com/aspnet/Home/wiki/DNX-utility) which is already
open sourced.

------
gnoway
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

        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
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
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.

~~~
camdenre
I don't know why you think it is too late? Do you think people aren't going to
embrace cross-platform .NET?

~~~
vblord
Probably because it just has to do with something related to microsoft. For
some reason, people just hate Microsoft. Even though they produce some of the
best development tools... people still hate them. In the words of taylor
swift, "And the haters gonna hate, hate, hate, hate, hate"

------
faragon
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
what's the core advantage over make/rake?

~~~
rblatz
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
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
>Why would I want to deal with MS on any other platform?

Because C# is a great language.

~~~
retrogradeorbit
Sure. But when you are looking cross platform there are much better languages
than C#.

~~~
rjbwork
IMO, not with anything approaching the install base/jobs/tooling/etc. of C#,
and you get the ability to practically use F# when appropriate.

Also, how many big "enterprise" shops are doing interop between a C-Style
language and an ML-style language? Probably not many, and almost certainly
more are doing it with C#/F# than anything else.

