MSBuild is going cross-platform with .NET Core

http://blogs.msdn.com/b/dotnet/archive/2015/09/03/msbuild-is-going-cross-platform-with-net-core.aspx

by kungfudoi • 11 years ago

250 134 11 years ago

blogs.msdn.com

gnoway• 11 years ago

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.

BinaryIdiot2• 11 years ago

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.

Touche• 11 years ago

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

deet2• 11 years ago

Seconded. Performance is the main thing holding me back.

I'm very excited about C# and other .NET languages for server applications, and would like to make it my primary server side environment, but am waiting for three things:

1) A production ready compiler and runtime on Linux (coming) 2) Tooling to support the new .NET project structures and dependency management (coming, it seems) 3) A production ready server solution with reasonable performance. On Mono, .NET Linux server apps consistently score near the bottom of benchmarks, essentially ruling it out. (Who knows? It seems too early to know whether this will happen.)

kenbellows• 11 years ago

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/

tracker1• 11 years ago

For that matter, Mono has been sharing the parts of the new .Net Core as they come out and make sense to do so...

swozey2• 11 years ago

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.

nathanaldensr• 11 years ago

Good Lord, yes. It takes forever for my TeamCity build agent AMIs to spin up and actually connect to the TeamCity server. It would be awesome to replace that bulky Windows build agent with a Linux one.

fiatjaf2• 11 years ago

Anyone who does not like MS because of the $ cannot at the same time like Java.

Someone12342• 11 years ago

Indeed. And they cannot play the "but Java is OSS" card anymore as Oracle has made it pretty clear that Java's APIs are proprietary and that you will be sued if you do anything not authorised by them (which effectively removes the 'open' in "open source software").

Say what you will about the Android Java situation, but it doesn't exactly scream "this is open and free software."

BetaCygni4• 11 years ago

It's not a question of $ or of liking MS, it is a question of trust. Microsoft can and will suddenly discontinue entire solutions like Silverlight. I know of a company that is in real trouble because they first rewrote their entire application in Silverlight and now have to do it again in HTML5...

Java on the desktop is almost dead due to the horrible JRE by Oracle. On the server and on Android it is alive and well, and the community is big enough to keep it going even if Oracle loses interest. It will also make its return to the desktop one day when someone figures out how to make it suck less, as the language and the available libraries are awesome.

edwinnathaniel3• 11 years ago

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.

snuxoll• 11 years ago

.Net has F# though, which I adore to no end. Can even avoid MSBuild with FAKE.

manigandham• 11 years ago

Can you/someone give a quick rundown of why maven is really so much better than everything else?

tomjen34• 11 years ago

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.

tychuz• 11 years ago

My reason would be: I can choose from a ton of C# positions, meanwhile Kotlin would have what? In my and neigbour countries I can find exactly zero Kotlin job offers.

CmonDev2• 11 years ago

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

edgyswingset2• 11 years ago

I'd argue that just because a language runs on a platform with a potentially large number of third-party support (JVM) doesn't mean it's going to be nice to use.

For example, I ended up having to write Java code when dealing with large XML data sets in a Clojure system, because the current offerings simply didn't let me do what I needed in fluent Clojure code. I suspect Kotlin has those same kinds of issues, just amplified because it's a lot less widespread than Clojure.

V-23• 11 years ago

Nicer in what sense? I do like both, I'd take either of them over Java on any day, but whereas Kotlin is maybe better suited for functional style programming (immutability out of the box, data classes etc. - however .NET people always have F# for this stuff), it's hardly on the same level as C#.

For instance Kotlin doesn't have reified generics (if I recall correctly they actually attempted it, but it's too hard to get it done on JVM), Kotlin doesn't have yield-return semantics, Kotlin's equivalent of LINQ doesn't use deferred evaluation. Kotlin doesn't have async/await like C#, which is a real gamechanger when it comes to asynchronous programming. It's very nice and promising, but it's not in the same league.

As far as JVM universe goes, Scala could give C# a better run for its money.

Of course it's not fair comparing Kotlin to C# - for numerous reasons - but if we do it anyway, it's got to be honest

naasking• 11 years ago

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.

lmm2• 11 years ago

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.

rbanffy• 11 years ago

Does building .net projects require MSBuild?

godzilla82• 11 years ago

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.

akshayB2• 11 years ago

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• 11 years ago

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

vblord• 11 years ago

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"

akshayB2• 11 years ago

If this was done in 2005, I think it would have been a different story

UK-AL• 11 years ago

What do you mean totally different? Outside of silicon valley and start up world .net and Java dominate.

wsc981• 11 years ago

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.

ZenoArrow• 11 years ago

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

You might want to check out FAKE, it essentially lets you write MSBuild configurations using F#:

http://fsharp.github.io/FAKE/

This recent announcement means that a multi-platform FAKE in the near future looks like a good bet.

serve_yay6• 11 years ago

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.

Someone12342• 11 years ago

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

duaneb• 11 years ago

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

This is an excellent reason to avoid MSBuild. IDE lockin is a nightmare.

Might be unavoidable for Visual Studio, though.

serve_yay6• 11 years ago

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.

GFK_of_xmaspast• 11 years ago

Cmake will produce files that msbuild can operate on.

bad_user• 11 years ago

It's not Maven.

to3m2• 11 years ago

I hated it too. I don't recall a single good moment about using MSBuild. I never once felt like I'd figured it out, nor that I was getting to grips with it. But perhaps its brilliance was just beyond my ken.

It was astoundingly verbose, rather poorly documented (I didn't think much of the official book either), extremely short on any kind of examples that might be usable with slight tweaks when you're getting started, and seemed to make unnecessarily heavy weather out of the simplest of tasks. Your debugging options are rather limited (especially if something goes wrong in one of your DLLs!), and I for one found the log files very hard to read.

(On more than four occasions, I also lost a lot of source files after doing a build|clean. I never managed to finger MSBuild for this directly, but there aren't that many programs that are invoked on build|clean, and fewer yet that rely a filing system watcher to tell them which to delete, so I know where my suspicions lie.)

I also have vague memories of finding out that only certain constructs could be made conditional, and that there were no facilities for abstracting conditions, making some of my files very repetitive and long-winded - but to be honest, at this point, I've blanked most of it.

CmonDev2• 11 years ago

Fork it and change it to your taste! Welcome to open source.

mordocai• 11 years ago

They didn't want to change it. They wanted to throw it away and replace it. Not exactly a fork.

serve_yay6• 11 years ago

Eh, I write JavaScript now.

wangii• 11 years ago

what's the core advantage over make/rake?

rblatz• 11 years ago

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.

aaronbrethorst• 11 years ago

    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.

dblock• 11 years ago

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

cptnbob3• 11 years ago

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.

CydeWeys2• 11 years ago

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.

plorkyeran• 11 years ago

I doubt that anyone would choose it for other stacks, but this means that you don't need a separate build system for building your existing .NET project on non-Windows.

cptnbob3• 11 years ago

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.

serve_yay6• 11 years ago

Shit, I would probably build out an entirely separate build system and then just call it with MSBuild if I had to.

jahnu• 11 years ago

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!?

drfritznunkie• 11 years ago

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.

beastway• 11 years ago

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• 11 years ago

Why would I want to deal with MS on any other platform?

Because C# is a great language.

retrogradeorbit2• 11 years ago

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

rjbwork3• 11 years ago

You can't win if you're not going to reward companies for good behavior.

retrogradeorbit2• 11 years ago

But on the other hand, how many times are you going to put your hand on the stove and get burnt before you learn?

BigChiefSmokem• 11 years ago

Because Microsoft keeps me employed and making money.

m0v_eax• 11 years ago

There are people other than you that matter.

faragon• 11 years ago

In my opinion, Microsoft should think about making their compilers/linkers make-friendly, e.g providing cross-compilers ("cl.exe", separated compiler and linker).

clayrsmith• 11 years ago

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 which is already open sourced.

MSBuild is going cross-platform with .NET Core

Related Stories