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$"?
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."
I read somewhere that Microsoft's structured the patents/licenses in the .NET ecosystem in such a way as to make that kind of lawsuit unlikely. Can anyone comment if that is true?
I think the most important part is that the new cross-platform .NET core framework, CLR, and compiler (Roslyn) are under permissive open source licenses (MIT for fx and clr, Apache 2 for Roslyn). You can see licenses and patent pledges here: https://github.com/dotnet/
Disclaimers:
1. Microsoft employee until they notice I'm hanging out on hacker news instead of replying to e-mails and "fix the glitch".
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.
> 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.
In all fairness all technology companies are like that. Hell even open source groups are like that. If the community disappears why would you continue to invest millions into it when better solutions are coming around the corner? Silverlight, for a while, was absolute king in video streaming (you could squeeze much more quality out of it than flash) but like with everything on the web unless it's strictly standards-based you're going to run the risk of it being discontinued when better standards come around.
I don't think that's really a fair knock against Microsoft.
> 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.
Good luck with that; it's going to take a desktop OS who can make a Java GUI framework feel native and not horrible and at this point I don't know why any of them would invest in this.
It might not be fair; it's just that in my mind one moment Microsoft was hyping Silverlight and the next moment they were discontinuing it. That's not a nice way to treat your customers.
What Microsoft should have done is to make it compile to HTML5. Something like SmartGWT is a great way to write interface in Java. It may even be the way the Java ends up on the desktop again.
I always find it a bit puzzling when people blame Microsoft for the death of Silverlight. As an in-browser technology, Silverlight's success depended entirely on the willingness and ability of third-party browsers to support it. It just needed one browser to gain a significant market share and then refuse to play ball to pull the rug right from underneath Silverlight's feet. This is what happened in 2010 when Apple blocked it from the iPhone and the iPad. Sure, that move was aimed at Flash, but Silverlight took collateral damage from which it never recovered. That wasn't something that Microsoft could control.
@Silverlight:
are you much better off if you've wrote a Java Applet at the same time ? (I think this was the right thing to do in Java back then)
We were trying to use Java Webstart, but we gave up, because of the fact that some modern browsers just block the Java plugin.
I have to use a Java applet for some customer VPN's I am connecting to and the only browser this works for me is Internet Explorer to connect to those VPNs.
You can still write Winforms applications and this is some really old technique. Maybe you are still able to use MFC, but I haven't tested that in a LONG time.
That's true, but at least Java applets died a natural death instead of being axed.
I checked the history of Silverlight and the first version was released in 2007. jQuery was released in 2006 so Silverlight was a classic case of "too little, too late".
Real Java applications run well nowadays, so much so that you don't notice it's Java (except that you always have to give them more memory...)
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.
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.
I gave up on activating windows agents programatically, I keep one powerful windows build server running, it spins down at night after regression testing, then back on during the day when employees come into the office. The pocketbook definitely feels it, though.
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.
> 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.
.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.
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.)
There has been work on performance and more to come (source: ASP.NET Community Standup podcasts). The stated goal is to be in the ballpark of the top performers. You can follow the progress here:
Very happy to see a focus on performance on the roadmap.
I've actually seen that benchmark page, but all the results it lists are for the Web Server running on Windows (perfsvr), where Linux is only used for load generation.
Any idea if the results are similar with the server running on the Linux machine (perfsvr2)?
> 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.
Oh, God, thank you! I've been hunting and hunting for something to replace CruiseControl. I had no idea this existed. Is there an easy way to turn this into a CI?
Maven manage your module/projects from building, dependency management, generating project website (if you want to), deals with packaging, and deployment (if you want to), and many more (via plugins).
Maven is essentially NuGet+MSBuild or Ant+Ivy or Bundler+Gem+Rake without having to manage build tasks manually.
Those tasks are:
1. Compile code
2. Compile test code
3. Run unit-test
4. Run integration-test (separately from unit-test)
5. Setup paths for running unit-test (say you want to use different config/resource files for your unit-test)
6. Package your artifacts _without_ the unit-test artifacts
Maven has these built-in and in a non-disruptive manner. Don't have unit-tests? Maven won't run anything for you.
You have unit-tests source code and assets that you don't want to be included in your final build? Maven will handle that out-of-the-box-no-config needed.
While people might prefer to use "one tool that does its jobs beautifully/correctly", the reality is that you need at least 2 things to build the project: tool to manage your dependency and tool to build+package your project.
It's the only build system I've ever seen that's truly declarative. You can't put random turing-complete computation in the middle of a maven project definition; you can only invoke well-defined plugins (if you want a custom build step, you package it up as a plugin - written in ordinary java, unit testable and all the rest of it).
The result is there are no "snowflake builds". One project tends to build exactly the same as any other; virtually every project uses the same source directories etc.. It makes it really easy to be productive straight away when switching projects. And the limited build steps mean the IDE integration can be very complete.
Yeah and last time I used it at work (2012-2013) it didn't even support incremental builds. Even the company's best Java developers just accepted this as normal.
I think maven did not push incremental builds because there was not a big need.
Most people code Java in an IDE. Both Idea and Eclipse do incremental builds inside the IDE. So as you are coding, you are incremental building.
Every place I have used maven, maven was used for the build server and the final release. Spinning on a webpage changing some code? You are using your IDE for that.
(Now scala is a little bit different, so we have SBT with incremental support as a pretty ground level thing)
Adding to all the good points that others mentioned, this sort of consistency only grows in importance in large companies where developers support many different projects. It allows you to focus on the business problems rather than spend time getting used to dozens of variations in the build themselves.
We had this problem with Ant many years ago. Everyone did their builds differently and half of them were subtly broken.
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.
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.
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.
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
>Kotlin's equivalent of LINQ doesn't use deferred evaluation.
Wow, I'm pretty surprised at that. Any kind of list comprehension/functional sub-language over collections seems like it ought to be deferred/lazy from the ground up. I'm doubly surprised at that from JetBrains.
Unfortunately it is so, so I wouldn't recommend it for large collections, or wherever performance considerations come into equation.
Let's peek at Kotlin's sources (_Filtering.kt):
public inline fun <T> Iterable<T>.filter(predicate: (T) -> Boolean): List<T> {
// note how it's allocating a new ArrayList<T> -
// Kotlin doesn't have a "new" keyword, but it's initializing it here
return filterTo(ArrayList<T>(), predicate)
}
And it redirects to filterTo:
public inline fun <T, C : MutableCollection<in T>> Iterable<T>.filterTo(destination: C, predicate: (T) -> Boolean): C {
for (element in this) if (predicate(element)) destination.add(element)
return destination
}
With this approach, if you're chaining several of these operations, you will end up allocating quite a few arraylists, one by one.
Note that without something like yield-return in place, writing your own collection-transforming extension functions with lazy evaluation won't be so clean and easy either
Since it has 100% interop with Java, you could work around this problem by using something like Guava - Iterables and FluentIterable are based on iterators as they should.
They use static helper methods, all you need to do is to snap out some extension functions in Kotlin to serve as bindings to Guava. The only problem, especially on Android, is that Guava's notoriously big.
Kotlin is good, I'm not hating on it, but mature? Not yet. Nicer than C#? Best of luck, but not with this type of shortcomings
* new (lazy) extension functions would be getting in the way of standard ones, you would need a paralel naming convention (perhaps one borrowed from LINQ, where map = select, filter = where, fold = aggregate and so on) and developers would still confuse one with another.
* unless we agree on one canonical implementation, yours would be different than mine, easy to see how it could become a mess.
If there is a better approach which removes these obstacles, someone let me know
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.
The fact that it integrates with Java isn't what I'm getting at. Developing in Clojure eventually forced me to write some Java, which I didn't want to do. I just don't see Kotlin as somehow solving that problem.
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.
That is true. I assumed I would eventually go into business for myself and see no reason to use C# - besides Kotlin is very young, there is still plenty of time to get in on the ground floor so to speak.
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.
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.
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.
Are there really that many people building .NET projects on non-Windows systems? It's been my experience that companies that are using .NET are pretty much full Windows everywhere.
Roslyn needs cross-platform MSBuild to build itself for every platform (without Mono). Same with corefx.
So even if you're currently using or thinking about using .NET xplat and don't have any plans to use MSBuild, this move is necessary for us working on .NET to get xplat builds working.
I'll definitely be. I live in the nix terminal, and that's where the tools work best for web development. But the current day job is C# apps. I dream of hacking code legitimately in a nix.
I'm writing Mac, Android and iOS apps using Xamarin in C# using a shared PCL that is 99% the same code across all platforms. This might not be all that common, but Xamarin has seemingly been gaining momentum over the last couple of years.
I've mostly spent time on the Mac side of things so far, and have helped out a colleague with the mobile stuff. Recently they've added a lot of documentation for the Mac side that covers basically anything you want to know - or at least it covered all the stuff I wanted to know when I first started the Mac app 12 months ago.
For mobile, Xamarin Forms can be a little difficult to wotk with, but it's getting better all the time. I don't really want to bother with learning native development at the moment, and because we have a pile of calculations and logic in our shared PCL Xamarin is working out for us.
There is some criticism that the pricing model makes it expensive for people developing at the low end of the mobile market ($1 or $2 apps), however I think that's more a failure of that kind of market in general rather than a problem with Xamarin pricing itself.
It's been the case so far because Mono feels like a second class citizen, but when MS will release officially .NET on other platforms maybe it will change.
My experience as well. I did build some older stuff back in maybe 2010 using mono and NAnt as a hobby of course and I still use NAnt today in 2015 but all it does is invoke MSBuild. These days I don't build any .net software on non Microsoft platforms.
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!
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.
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).
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.
> 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.
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.
cmake is certainly worth looking at. Doesn't take much to get up and running with it, it's pretty straightforward to use once you're set up, it takes out-of-source builds seriously, and it's got fair support for adding custom build tools (something you'll have a devil of a time getting working nicely in Visual Studio). Reasonable ecosystem as well, with a good supply of online examples and drop-in helper scripts for locating common libraries. (Compare and contrast to, e.g., MSBuild, boost jam, or JamPlus - all of which, even MSBuild, might as well by comparison have about 0 users each.)
Not to say that it isn't awful in many respects, though. It often feels as if it has been designed by 3 people, none of whom talk to one another, and all of whom have different ideas about how things should work. For every time there's some easy setting that nicely handles every platform for you there's another where you have to carefully distinguish between VC++/gcc/clang/etc. and add compiler-specific flags to some random string. And the scripting "language" is unhinged.
Still - compared to a normal project that targets N platforms, where you might well have to deal with N build systems, all appalling, if you use cmake, you'll only have to deal with one.
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.
> 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.
If you're making libraries, console applications or doing modern websites it's pretty easy to get your build working without Visual Studio.
One - ELEPHANT SIZE - problem is that for some reason Microsoft only ship the Windows SDKs as part of Visual Studio. Meaning that you'll need to install the IDE at least once to get a build running (you can copy the SDKs around after that).
Microsofties - I know that a lot of dev-div people will be reading - can you shed some light on this situation? What's the reasoning behind not shipping the SDKs separately. I've never had this problem with Java..
FWIW, you can install MSBuild without Visual Studio. It's part of the Windows SDK. If your target system is not supported, you have to run it on a supported system and choose the "Download for installation on a separate computer" option. Then copy the resulting msi and cab files to the server and run them. See http://stackoverflow.com/questions/12944502/build-asp-net-4-...
However, after I did this, I had to find build targets that Visual Studio installed and copy them from my workstation into the same directory on the server (i.e. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications).
Yup, that's how I make a build server: clean windows image, MSBuild, then copy the utils, build targets, reference assemblies etc over from a machine containing VS.
It's such a pain that a famous ex-Microsoftie started a connect request for it:
This works fine until you have to build a project with a 3rd party commercial library requiring licenses (.licx files). I just spent a week trying to put together a vagrant vm to build such a project finally giving up and adding visual studio to its provisioning script.
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 :(
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.
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.
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.
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.
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.
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.
I used fake in anger. I wouldn't recommend using it compared to more mature alternatives for serious projects. It seemed strictly worse than using NANT & invoking msbuild. Yes, xml is horrible, but NANT is mature. Both tools don't understand file dependencies. From that perspective they are inferior to make.
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"
In my opinion, Microsoft should think about making their compilers/linkers make-friendly, e.g providing cross-compilers ("cl.exe", separated compiler and linker).
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.
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.
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.
All good stuff.