MSBuild is going cross-platform with .NET Core
blogs.msdn.com
blogs.msdn.com
All good stuff.
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.)
https://github.com/aspnet/benchmarks
Just keep in mind that the work just started (and it was recently put on hold to get the Linux version - beta 7 - out the door).
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)?
"Kestrel hit 151k RPS just now for plaintext test with pipelining (depth 16). Lots of known things to fix still, big gains to come #aspnet"
"have a fix in the works that'll give us another 5-10% & a list of other things to attack after that. Fun stuff :)"
Say what you will about the Android Java situation, but it doesn't exactly scream "this is open and free software."
Portions of .NET are under ECMA and ISO standards: https://en.wikipedia.org/wiki/Common_Language_Infrastructure...
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".
2. Not that smart and definitely not a lawyer.
Shh, they might find us.
The crux of the Oracle v Google suit is basically, "It's Java, but it's not Java Java."
If you take a look at the MS patent promise, the way it's authored specifically allows for the very same kind of suit.
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.
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.
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...)
And yes, you can still use MFC ;)
that is like saying, o my god, i think the rotting corpse that has been lying in here for 3 months is dead!
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.
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.
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.
IMHO FAKE syntax is not for me.
.NET has F#, nice. JVM has Scala, JRuby, Clojure, etc. But that's a matter of taste/opinions.
I think it works with AppVeyor and Team City: http://cakebuild.net/dsl/build-system
Note: I've never used Cake myself, but have seen it recommended alongside Fake.
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.
http://kent.spillner.org/blog/work/2009/11/14/java-build-too...
See https://cwiki.apache.org/confluence/display/MAVEN/Incrementa... for proof. That may have been implemented in the meantime but the fact is that maven had no support for incremental builds for at least 10 years (released in 2002). Amazing.
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)
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.
We had this problem with Ant many years ago. Everyone did their builds differently and half of them were subtly broken.
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.
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
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.
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)
}
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
}
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
Easily? Proper implementation isn't so trivial, look what it takes for Guava:
https://code.google.com/p/guava-libraries/source/browse/guav...
https://code.google.com/p/google-collections/source/browse/t...
https://code.google.com/p/guava-libraries/source/browse/guav...
Plus:
* 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
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.
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.
Having dealt with it for years, it's unadulterated pain and bad performance and nothing else.
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.
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.
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.
What's not to love!?
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.
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..
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).
It's such a pain that a famous ex-Microsoftie started a connect request for it:
https://visualstudio.uservoice.com/forums/121579-visual-stud...
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.
Imperative XML makes me choke.
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.
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.
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.
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.
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.
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#:
This recent announcement means that a multi-platform FAKE in the near future looks like a good bet.
No, into the trash it goes.
Because C# is a great language.
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.