I'm equally excited for the intentional mono support and "Side by side - deploy the runtime and framework with your application". ASP.NET MVC and Web API are really pleasant and mature frameworks, but configuring IIS has always been really unpleasant and clunky.
I'm hoping that with ahead of time compile option at least will give you some actual feedback as to what's happening. That'd at least be better than watching the browser sit there loading a page for while.
I definitely think these changes will keep existing .NET developers in the fold. People who haven't embraced the Microsoft ecosystem at this point probably won't in the future.
Things I'd say hurt outsider adoption:
1) The ecosystem of freely available .NET libraries is minuscule compared to what you have with Python, Ruby, PHP, Java, and probably even Node. And the quality of .NET's 3rd-party commercial packages are typically worse than what you'd expect from free open source libraries in terms of both software quality and documentation.
2) Going along with #1, things like database/service drivers, web service APIs, etc, are never as robust or feature-complete as their Python/Ruby/PHP/Java etc counterparts. And sometimes they're really late to the party getting just a basic implementation going.
3) Many .NET shops are technologically conservative, for various reasons, and don't embrace the new technologies. If you're a developer excited about these technologies, understand that probably 80% of .NET shops will never touch these changes with a 10-foot pole for the next 5-10 years outside of rinky-dink projects.
4) The .NET library itself is kinda unwieldy, and only becomes easier to work with if you invest in expensive tools (Visual Studio). In the OSS world, you may have to install a few freely-available tools first, but you get the first-class experience for no cost pretty much right away. In the editor of your choice.
5) Once you step out of Azure, advanced deployments of Windows server have a sizable learning curve that rival Linux in terms of difficulty and complexity. In fact, today its probably harder, ever since Microsoft re-did technet to make it way more difficult to get comprehensive information on stuff.
2) You have no idea what you're talking about. ADO.NET is arguably the MOST robust database driver abstraction out there, with support for just about any DB.
3) Simply not true. Conservatism strikes everywhere, especially outside of startups. However, it's up to the developers to decide if a technology is viable for their ecosystem, not you. Just because it's new doesn't mean it's better.
4) First-class experience? Tell me how robust your Javascript refactoring workflow is? Python? Oh, that's right, it's damn near impossible to refactor either one without investing serious time wading through code.
5) IT stuff is hard, whether you're running Nginx/Apache on Linux, or IIS on Windows. It's not, however, more difficult for IIS. Technet was outdated anyway. Look at http://www.iis.net/. It's way more useful than Technet ever was. Oh, and you don't like IIS? It's what OWIN was made for. Use whatever server you want, or be like those cool Node kids and use the framework to run the server!
This is the crux. As Linux developer I can move between languages and frameworks without fundamentally changing my knowledge of the os and my development workflow. I can use ruby, node or python along with docker, vagrant and git. And I can switch between them with relative ease.
I can work on windows, osx or Linux and test production code very easily using virtual box. I can automate the creation of the entire os from rpms so that every time I run a deployment test I know it's a close to production as I can get.
A lot of this might be possible with .Net, but it only let's you work with .net languages.
That is the real problem. There is a fundamentalism divide at the os level and the cost of switching in EITHER direction is to high.
The "Express" versions of Visual Studio have been available since 2005. You can install plugins/extensions in the Express SKU, but it's a solid option to get Intellisense and debugging for students, hobbyists, small shops, etc.
1) What is your system of measuring this? This may be because 99% of what you need to develop a very fully featured app is already in the base .NET frameworks. So there is rarely need for 3rd party libraries unless very specialized. The vast majority of the code we need outside of the framework is very specific to the user's problem we are trying to solve.
2) This is complete and total b.s. Please enumerate an example (or two) of deficiencies of a .NET driver vs a counterpart in each language: Python/Ruby/PHP/Java.
3) Maybe many .NET shops are simply in love with the productivity they get out of their .NET efforts because of the integration between MS stack components from development through deployment.
4) Huh? I guess maybe if you have to install .NET framework on Linux you'd notice it's size. It's not like you have to go installing and deploying it everywhere if you're on Windows. You use what you want and never notice the rest. As for VS, it's actually pretty awesome. I interviewed someone today and watched him use sublime to develop a rails app and marveled at how stone age the process was in some regards (this sounds like a dig at rails and sublime, but I don't mean it to be. Some stuff was done very quickly and easily. Some aspects of Rails and Ruby in particular are really cool).
5) You don't know what you're talking about. I've deployed in 1 click to AWS and to my own dedicated servers with one click. Technet? I've been using .NET for 10 years and have never used Technet once.
Have to disagree that .NET itself is unwieldly. All the 1.1 stuff was back in the age of "GUI/designers for all the things" but now .NET is far better.
As someone has been keep a close look at the new developments of Asp.net (read: the new asp.net stuff, not the old Aso.Net webform stuff, which I genuinely hate) for the past few years, I think it is really becoming something attractive.
That being said, I have also used a lot of nodejs (yes, it is awesome) lately stuff, and tried to pick up things like CakePhp two years ago. I believe that I have a better picture of the situation.
So here it is, 1) Is asp.net going to win over some developers from the other camps? Maybe some, but not a lot.
2) Is asp.net going to win the heart of new developers who has not yet jumped into any camps? I think so, at least with a bit higher chance than before, given that it keeps improve/innovate at current speed.
3) Is the open source community going to love aspnet? Less likely, given the history of relationship between Microsoft and the Open Source community. But the situation will improve, as you clears see that Microsoft is starting to embrace OSS more and more, though still not enough on the fundamental level. That is because Microsoft is not at a position where it was before in the industry.
Sometimes, some people in the Open Source camp just have this blind hate towards anything Microsoft/.NET, without even trying to see what these things are. The same would also apply for people from the .net camp towards the OSS. That has been the situation for a very long time, I hope this would improve over time. The world today is no longer the same as the world yesterday.
"Many .NET shops are technologically conservative" - probably less then there are e.g. conservative Java workshops though, not a valid point.
"In the editor of your choice" - which will feel like a notepad after using Visual Studio - not a valid point really, IDEA for Java is the only exception.
There are some good points hidden there, but the post paints a picture much darker than it really is. I mean based on this post I would never say Unity3d could happen. But it did happen.
Octopus Deploy takes care of this. Each endpoint server has a small app running on it (a tentacle). It can pull or deployment server can push updates to each endpoint. I can deploy to hundreds of servers with no downtime.
I can push builds out of TeamCity directly without even touching Octopus Deploy if I don't want to. Server settings can be set up as part of the deployment.
Web apps, Windows Services, etc can all be deployed and then tweaked with Powershell.
I'm also deploying database scripts at the same time. It isn't hard.
Last year we were still getting Java 1.4 project requests.
Your list appears to be biased towards people who only want the Bazaar. Also, I think it's crucial to acknowledge that "the Web" is just an extension of the Bazaar.
So, here's how I see it:
1) The .NET framework already comes with thousands of free high-quality components, libraries, packages, etc for every type of platform - web, desktop, mobile, services, data, etc. The majority of .NET programmers don't need to travel outside of that for basic needs. Furthermore, I doubt that you'll find FOSS native components that can rival what's available for .NET from companies such as DevExpress or Telerik.
2) The majority who choose .NET don't make that choice because they want to work with the latest whiz-bang NoSQL database or recently invented API. They typically want to build business applications that will be stable and integrate well into the rest of the enterprise. What seems like "late to the party" for you is just prudent, conservative decision making for a .NET dev.
3) Do you think the majority of FOSS shops are working on the bleeding edge? I don't know, but most of the *nix shops that I've seen use old Java frameworks, or they only run RHEL/Centos or are still using PHP and MySQL for everything. Rarely are they doing anything interesting or new.
4) "The .NET library itself is kinda unwieldy..." I don't get this at all. What kind of first class experience are you going to get with any FOSS environment unless you've already invested significant time learning vim or emacs? At least with .NET you have the option of getting a first-class experience without investing any time learning one of those.
5) You didn't list any specifics. What's harder to deploy? Also, what do you need information on that you could not find in Microsoft's vast array of documentation or elsewhere on the web?
Eventually I would like a completely statically typed inferred language, go mainstream(Aka Demand for it)
C# is my best option atm.
I don't like how .NET as a platform/ecosystem/community lags on certain things that are almost taken for granted in other areas, like deployment tools and package managers. Then again, when I worked with .NET those things were my responsibility so I guess their lack affected me more than many .NET devs.
What is not fine is the rest of the ecosystem. Going Microsoft usually means Windows (good luck convincing etc corp. to run on Mono), and sometimes, even things like Sharepoint.
Thanks, but no thanks. I'd pick C# over Java any day, but dragging all that baggage is not acceptable.
"ASP.NET vNext (and Rosyln) runs on Mono, on both Mac and Linux today. While Mono isn't a project from Microsoft, we'll collaborate with the Mono team, plus Mono will be added to our test matrix. It's our aspiration that it "just work.""
What's wrong with VB? It does no more and no less than C# does, with different syntax. Shall we just do away with English, because German is just so much more to my taste?
Someone said the same about Linux too.
I've done .NET development before, and there is essentially nothing that could tempt me back and away from Linux/Clojure/Python/PostgreSQL/etc.
Both are essentially eternal niches; they afford you more ease-of-use if you stay within the mold but their monoculture will make certain things unlikely to happen.
Not even so much because it's impossible, but because it goes against the mindset that led to the platform in the first place.
Until then, everything .NET is a non starter because I don't care for Windows. At all.
Mind you, I don't need it to be open source/FOSS etc.
I have programmed on the Microsoft stack for many, many years, and still make a good deal of coin in .NET and SQL Server, so I'm not coming at this with an agenda. At the same time I can as easily leverage other technologies so I don't feel as grateful when Microsoft catches up.
^1 - I was working at a shop when .NET was first introduced and one chap was making a case for why we should adopt it. His case made a very compelling case for why the shop should have adopted Java years earlier, and it was actually eye opening to me because it was a demonstration of an organization and a team who saw their universe of choices as being defined by Microsoft.
I wonder whether we will be seeing a .NET web server for mac and linux. Hosting a C# MVC app on linux will be sweet.
BTW, if you're not a fan of ASP.Net MVC's style of web framework, take a look at Nancy[1]. It's much more lightweight, and can also run under Mono on Linux.
However, there's 150 comments and no mention of the "vNext" name. Someone else must find the name silly!
The Mono guys already [have such a server][1], although I'm really looking forward to be able to use the Microsoft one to run on Linux and Mono.
Not one of the above has actually improved the product we produce and are all reactionary "we might get left in the shit again" changes.
I'm really tired of it now.
You didn't see an improvement from early versions of .NET to later versions? No improvement from WebForms to ASP.NET MVC? I have a very hard time believing that. The system is SO MUCH more mature than it used to be.
It's the nature of the industry; if you stop moving you'll be left behind.
And anyone who knew web, knew Silverlight didn't have a future from the very beginning.
I've used most of the above. ServiceStack was pretty good but nothing in comparison to Jasper which has much better documentation, a cleaner architecture, stable migration notes and better performance. Look: https://jersey.java.net/documentation/latest/index.html
NancyFX I haven't touched.
NHibernate is a buggy behemoth with a learning curve from hell. It doesn't scale well with project size (we have 2000 tables of which about 500 are NH mapped "model-first") and it stinks. The SQL generated is terrible, it's impossible to debug when it goes wrong other than sift through 50Mb of log4net DEBUG level logs. To add insult to injury, the LINQ provider is so buggy it's like programming with a hand grenade. I've used hibernate in java and NHibernate isn't even a tenth of the way to the maturity and reliability.
Dapper - I really like Dapper. I have used it for data transforms before. However it doesn't play well with low trust as it uses IL emit.
OrmLite - see ServiceStack.
Not bad choices - just choices I either regret or had to make because the whole ecosystem is amateurish outside of Microsoft and unstable inside of Microsoft. Sorry.
Totally agree. In 2006/7 jQuery effectively meant that Silverlight was DOA.
As for me, because I'm in charge of the migration. When its gone I'm not even going to go to the funeral.
> we'll collaborate with the Mono team, plus Mono will be added to our test matrix. It's our aspiration that it "just work
This. is. superb! I love developing on VS with ASP.NET, and I love *nix tooling (ssh is pure fun), I was secretly hoping for this to happen.
I recall CSPROJ files being the primary source of pain for me as I started to transition out of the Microsoft world and into the open source world, as it prevents you from using editors like vim & emacs if you're working in a team environment.
This comment strikes me as a bit odd. While Csproj-files were never pretty they were XML, they were structured and they last but not least: they were mergeable.
Contrast that to the actually horrible file-format that is SLN-files. Yes, it's plaintext, but it has projects named and numbered in sequential order, meaning doing any sort of merge or multibranch development is impossible unless you manually recreate all changes done to SLN files in all branches.
Microsoft going ahead and "fixing" CSPROJ-files, and not SLN-files is just madness. Consider me disappointed.
(Also CSProj files aren't super fun to merge using git and change very frequently. See: http://stackoverflow.com/questions/13479294/why-are-my-cspro...)
Ideally the csproj file should rarely become modified. Talk to any team of more than 2 developers and they'll confirm that pain of dealing with mundane csproj conflicts.
As far as XML versus JSON, I really don't care at all since I don't intend on looking at them or modifying them every day.
Now that they're rolling packages.json into the project file you'll be editing it more frequently than you might think. (Though most Microsoft ecosystem developers will likely prefer to use a GUI of some sort to do so.)
<Compile Include=".\**\*.cs" />
I have issues with the .csproj also, but I don't think json would fix anything, my issue is usually with visual studio and the confguration manager not applying changes...
I have to deal quite often with "Unload Project file" in MSVC IDE, edit by hand, "Load again" - because no matter how good the IDE is (and Visual Studio is a good IDE overall) there are lots of edge cases where it fails (merging multiple settings per project / per configuration / etc.)
1) That the new format will be more convention-over-configuration based and not have to be 100+ lines for a default project.
2) As I've mentioned in the parent post, I hope that you don't have to list individual files in the equivalent of <ItemGroup> blocks - you should instead only need to add an exceptions to whatever convention is being applied.
How do you think they will get around that? Just include a directory? Not that this will affect me much because I'm almost never in .csproj files because the IDE (Visual Studio) does 99% of things for me.
But capability is half of the story. Tooling/ecosystems is the other half (re: MonoDevelop is still not up to the snuff).
This is starting to look like a pretty decent environment to work in.
A year or two ago Microsoft decided to get rid of the subsets because they didn't make sense anymore; "client-server" gave way to "distributed mesh" and it became perfectly reasonable for desktop application to expose a web service port in order to communicate with other apps.
'cloud-optimized library' sounds like a return of the subset idea, but going in other direction. It surely doesn't contain any of the WPF stuff that's used for creating desktop applications. It probably lacks other namespaces that are unlikely to be used in server applications too. I just hope they didn't cut too much out so that it's only usable for MVC/WCF/WebAPI servers. If I want to write my own low-level socket-based service, I hope I will be able to do that.
I sort of remember that the core CLR didn't really rev that much, in that it spent the longest time on 2.x, with only the data access technologies built on top changing what seemed like every other week. LINQ was the next nice additive.
I don't recall exactly why now, but I know that the term 'strong naming' can still instill terror in me. I guess that all goes away if you can distribute a statically linked lump per app. The cycle continues..
I'm typing this to delay the effort of ripping EF out of my project, and do ADO.NET Linq-to-SQL. (I guess. Maybe it'll just be raw SQL at this point.) Unless someone here can answer this question? It's worth a shot... http://stackoverflow.com/questions/23528335/how-can-i-implem...
I miss Rails.
Here's the original post describing how we made it: http://samsaffron.com/archive/2011/03/30/How+I+learned+to+st...
First add foreign keys to to models (e.g. In the Build class add MainlineID for the Mainline object).
Then you can define the configuration:
Public Class BuildConfiguration
Implements EntityTypeConfiguration(Of Build)
Public Sub New()
ToTable("Build")
' Other mappings
' Define one-to-many
HasRequired(Function(x) x.Mainline) _
.WithMany(Function(x) x.Builds) _
.HasForeignKey(Function(x) x.MainlineID)
End Sub
End Class
Public Class MyContext
Inherits DbContext
Public Property Builds As DbSet(Of Build)
Protected Overrides Sub OnModelCreating(modelBuilder As DbModelBuilder)
MyBase.OnModelCreating(modelBuilder)
modelBuilder.Configurations.Add(New BuildConfiguration())
End Sub
End Class
Using context As New MyContext()
Return context.Builder.Include(Function(b) b.Mainline)
End Using
http://weblogs.asp.net/manavi/archive/2011/05/17/association...
var releases = db.Releases.Where(r => r.Build.Mainline.MainlineID == 4);
EF has its fair share of issues and limitations, but that's not one of them.
The modern C# stack can be very pleasant, but it's in an ocean of horrible mistakes and dead-ends that they can't flag as such for marketing reasons.
Although many use nhibernate instead of EF, i have no experience with it... (it's more db agnostic though).
I'm not sure, but i wouldn't advice Linq To SQL though...
In the end, we decided to continue to maintain and enhance our own ORM, because of the special features it has to support the Enterprise niches we work with. But if we had to start over fresh today, we'd definitely avoid EF and we'd probably build upon NHibernate. As far as we could tell, NHibernate had the most mature features and ability to support the market we're in.
If the m-dollar guy shows examples in IE, people will say "Doesn't work in other browsers, does it? Typical Microsoft bubble." If the m-dollar guy shows demos in Chrome, people will say "Ha, even this guy doesn't use IE."
So then you either have to show demos in both, which is silly, or you just ignore this because it comes up every. single. time.
Source: I like a lot of web browsers and do some web demos and work for m-dollar.
It appears to be dormant and has never been used.
I'll also echo what everyone else said. I feel the only reason IE is staying around is so I have something to download Chrome with on a fresh installation.
If you think there is irony, you haven't been paying attention. It's the point of what's been happening.
This ain't your older sister's Microsoft.
You don't need to go further than the recent announcements and the excitement they generated among .NET users to see how dependent on Microsoft they are. It's Microsoft's show to run.