This is extremely exciting. The lack of a 'No-compile developer experience' has been one of the biggest annoyances for me and my team. It actually has lead to influencing our coding patterns: since we can "refresh and see new code" for anything that is in the view templates (Razor *.cshtml in our case) we have become increasingly in favor of putting code there (or in javascript frontend 'thick client' code) to take advantage of not needing to recompile. It's not like recompiling is slow (maybe 5sec in our case), but it still breaks your flow and more importantly requires stopping the debugger if it is in use. In some ways the code has improved, in some ways it hasn't, but in either case it feels like the tail wagging the dog when you are changing how you structure code based on your tool's inadequacies.
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.
From my experience, the initial compile is fast, it's the app pool recycle and JIT on first page load that leave you in the hallway playing chair mounted sword fights.
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.
Putting code in razor views is a very bad idea, have you tried .NET Demon for continuous compilation?
If you write tests you might want to consider NCrunch?
As a .Net developer, I find all of the recent announcements from Microsoft really exciting. I just wonder if these type of things are enough to sway people's opinions regarding the platform. There is just so much baggage in the developer community when you say .Net or Microsoft (edit: as one of the three comments at the time of this posting proves). Are these moves just going to stave a potential exodus of .Net developers or will it actually lead to new developers picking up the language?
> Are these moves just going to stave a potential exodus of .Net developers or will it actually lead to new developers picking up the language?
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.
1) This is ridiculous. Third-party commercial packages like what? Have you even looked at Telerik's offerings, or DevExpress? Plust, you haven't really needed commercial libraries for the past few years. Search nuget.org, it'll have just about anything you need.
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!
Wow. These .Net guys really missed the point didn't they? I agree with your points completely. The question was 'are these changes enough to bring people over to .Net? '. Most of the responses are all along the lines of: your points are wrong .Net is awesome... If you are using windows.
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.
> 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.
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.
>> 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
When I was considering which language to start learning as a newbie, this was a major reason I was attracted to the Rails ecosystem: I can use a "stone age" tool and don't have to deal with yet another learning curve (i.e. a complex IDE like Visual Studio).
Microsoft had a long history of failing to cultivate a proper open-source community around .NET - they're playing catch-up now and have opened up the development of many of their key tools, but they're late tot he party at that front.
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.
In reference to #1, check out this summary of module counts for each package manager[1]. The TLDR is that Java, Ruby, and Node.js dominate in terms of module numbers.
This is definitely an important question, but I do not have any data on it. If I had to guess, languages with package managers that are harder to use might have better quality. ie: npm is super easy to use, so there are tons of crappy node.js modules, while maven is harder, so the Java modules out there have more polish. Without data, however (how would you even measure it?) I cannot say for sure. Perhaps you could compare number of modules installed past some percentage threshold? If 90% of node modules never had more than 100 downloads, but Java had only 20%, that would be pretty telling to me and might lead to a reasonable weighting factor.
.NETs growth is only modestly better than Ruby or Java, but considering one should expect there are more opportunities for creating new packages, even just ones that copy what is already available in the Java ecosystem, I'd say this is to be expected.
I think you are rather unfair about .NET, most likely because you don't know much about it, or you have not used much of it.
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.
5) I really don't get this point. I never deployed to Azure and in my work I have a Windows Server VM with IIS on top of it. All I do is clicking publish in VS and pointing the right website. Where is the complexity in this?
You deploy into your production environment from within the GUI development tools without assurance that what's going into production is in version control and independent of the peculiarities of your personal machine when MSDeploy doesn't have a clear rollback process.
This suggestion is ridiculous. You can right-click Publish from the Visual Studio integration, but at no point are you told about packages or the ability to rollback.
That's what I meant by "clear" ... there is no clear ability to rollback from a VS-initiated MSDeploy.
"The ecosystem of freely available .NET libraries is minuscule compared" - examples?
"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.
re 5) advanced deployments of Windows server have a sizable learning curve
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.
It seems like you're missing the point of why most .NET developers are using .NET. They don't use it because they want to be part of the FOSS wild-west hack-fest (aka "the Bazaar"). They use it because they want "the Cathedral", where things are well-integrated and work as expected.
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?
As someone who recently moved from C# to working with Node, Angular and Python full time, the recent announcements definitely make me want to go back to using .Net again. I love where all of the new stuff is headed.
I've worked with various languages C#, Python, Ruby, Objective-C(I was an iOS developer) but I prefer strongly typed languages for larger projects, and the refactoring tools that it allows for.
Eventually I would like a completely statically typed inferred language, go mainstream(Aka Demand for it)
I moved away from C# and .NET about 4 years ago, and use all those things too. The recent developments are great, but I view them more as a cool glass of water for people in a hot place (not hell, far from it).
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.
Yes, those are standard now because they're "old" in the rest of the industry. It remains to be seen if newer tech that is starting to become standard outside of the Microsoft ecosystem today (containers, for example) will be integrated fast enough to matter.
Starting with Windows 8, Hyper-V (Microsoft's virtualization platform) is built into the OS - and one of the goals with it was to be able to virtualize different environments invisibly to the end-user.
The Hyper-V team have also been actively committing to the Linux kernel for many years now, and I'm happily running a 6-node Cassandra cluster on my Windows 8 dev machine right now using Hyper-V :)
So it's not there yet, but ground has been broken.
The C# language is fine, F# is also fine (let's pretend VB does not exist). The CLR is fine (and, in some cases, even better than the JVM).
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.""
He clearly did, and I echo his sentiment that the chances of Business X buying into the strategy of going .NET but without the ecosystem (what in most people eyes is the safety net of guaranteed support etc) are very close to zero. Even more so when they start trying to hire .net devs with strong linux devops skills.
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?
> It does no more and no less than C# does, with different syntax
They're basically equivalent [1] and I (personally) would rather MS drop the engineering efforts they have in place with VB.NET and focus them on C#.
[1] In one or two places VB.NET has more functionality than C#. It has syntax for the CLR's Exception Filters whereas C# does not (although I believe the C# dialect that Roslyn supports is going to change this).
When I was a fresh graduate, I swore I was never going to program in VB.
Now I've grown very used to the VB.NET syntax, and when I go back to other languages, I hate two things:
- case sensitivity and
- the semicolon (;)
I can live with curly braces ({}) :) though having each line be its own statement is very convenient.
There are several things to dislike about the VB.NET syntax (Dim being the most egregious), but I think many languages could adopt some of its benefits.
Groovy in particular did away with the semicolon, and I'm glad :)
It will never sway a large part of the community. What Apple is to selling integrated hardware, Microsoft is to integrated software.
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.
From my POV: as soon Mono becomes a first class citizen (starting with a robust, cross platform IDE to hosting on Linux without hassle/shortcomings) I'm sold.
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.
They're headed there - it's not a coincidence that the new compiler (Roslyn) was announced with full Mono support and Miguel de Icaza standing next to Anders.
While the announcements may be very exciting if your lot is in with Microsoft (^1), for people on mixed platforms and with real technology choice it just seems reactionary. That Microsoft moved configuration files from XML to JSON is really Microsoft's technology choices in a nutshell.
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.
Of course it's reactionary; the entirety of ASP.Net MVC is a reaction to web frameworks on other platforms. The key, I think, is that it's a very positive way to react. In the past Microsoft always took the negative road, trying to destroy competition, rather than the positive road of integrating and collaborating with competition and letting their products stand on their technical merits.
>In the past Microsoft always took the negative road, trying to destroy competition, rather than the positive road of integrating and collaborating...
Wait, what? Have you never heard of the phrase "embrace, extend, and exterminate" before? What you describe is simply step one of their modus operandi.
I think the only difference between the 1990's Microsoft and the one we have today is they aren't as good at the exterminating part. They still extend things like crazy, but either they really are trying to play nice or they just don't have the weight to exterminate much any more (that wasn't already swalloed by them). My opinion is it's likely a mixture of the two.
It may also be a product of age / experience. If you were involved in the 90's tech industry, it's very hard to forget MS's era of "embrace, extend, and exterminate".
I view Apple's closed ecosystems with a similar sense of apprehension.
"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.'"
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.
They're already providing a .NET web server. That's the 'self-hosting' examples Scott shows in the article: when you run the application that way, it becomes a web server for your app. It's just like a Node.js application. For a production deployment on Linux I'd probably run the app using Mono on a localhost port, and run Apache in front of it with a reverse-proxy config pointing to localhost.
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.
I'm really looking forward to the self-hosting features. I have a few client (Windows Forms) applications that would be so much better within the browser. Opening that door for client-side web applications where network connectivity is a major issue would be so helpful.
However, there's 150 comments and no mention of the "vNext" name. Someone else must find the name silly!
vNext has been used for a while with ASP.NET and visual studio development. The next release is canonically called vNext (version next) until a formal name is given prior to release.
I write code on a Mac and script-built VMs seem to be the way to go. Sharing host folders the VM mounts and letting the actual code run on the VM is much closer to the server environment (leading to much fewer surprises). While it may hide a bug that would manifest itself under OSX (or other Unix) it's a useful setup.
Having said that, I've also worked a lot with slimmer environments - venv on top of the native OS - with reasonable success.
I've been through EVERY ASP.net update on every version of .net and every MVC update from CTP2 onwards, dealt with WWF being canned and rewritten, moved APIs between old SOAP stuff (asmx), WCF and WebAPI and rewritten swathes of ASP VBnand C++ COM code, ported EF stuff to later versions and worked around piles of framework bugs including the MS11-100 fiasco. That and been left royally in the shit with silverlight.
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.
Not one of the above has actually improved the product we produce
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.
The difference between webforms and MVC was huge... (no more postbacks)
But i think Microsoft is slowly finding the correct way of doing things and yes, there is a lot of influence of NodeJS (Owin) and RoR (Scaffolders). But it's easier to change between the same platform (and still using C#), then changing between web technologies.
The above user wasn't required to switch to Silverlight, some web applications in my company still use Asp.Net 1.0 and it still works (not my projects, thank god)
Good point, I'm thinking in terms of code quality, which can be seriously improved by using newer language features. I mean, you could write C# without using generics or LINQ or extension methods or a dozen other meaningful improvements, but I can't imagine someone doing so on purpose.
You would get a null reference exception if you unrolled that into a loop, too. You should know what your data is going to look like and if any elements could be null or not. Don't blame LINQ for your lack of null checking.
Definitely but that gurantee is thrown away the moment you pull a 3rd party black box in.
I'm suggesting it's feasible but not necessarily perfect and when it does go boom, which it does when you have 100 million HTTP hits a day, you need to be able to find out precisely where it went wrong. LINQ makes that damn hard:
In my opinion, it's not really any different outside of the Microsoft bubble except outside you're dealing with different vendors. In the time that all these technology changes by Microsoft, node.js came out of nothing, PHP got namespaces and package management, Python 3 became a thing nobody uses, Rails has several high-profile security bugs, etc, etc, etc.
It's the nature of the industry; if you stop moving you'll be left behind.
Interesting how different people have vastly different experiences. I've been using .NET since pre-release 1.0. Once I ran into my first reactionary "we might get left in the shit again" change I stopped using anything that wasn't in the core framework. I don't go near ORMs, and I don't touch LINQ either. I have code running in a project now that's 7 years old, and I cannot improve it, even after revisiting it many times. I love using Visual Studio, and I love writing .NET code. I try new things when I hear about them, but nothing has compelled me to change.
This reads like a standard list of a cocooned MS developer.
With ServiceStack, NancyFX, NHibernate, Dapper, OrmLite, etc out there could you have just been making some bad choices?
And anyone who knew web, knew Silverlight didn't have a future from the very beginning.
The only bad choice was the foundation on which to build the product. The above technologies are pretty much a response to the world being better elsewhere. Unfortunately the responses are pretty immature, poorly documented with bad support reputations and virtually no backing.
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.
Have you tried LINQ to DB (not LINQ to SQL) the successor to BLToolkit? We've had good results with it, but we like to keep our queries and datalayer as simple and thin as possible.
As for the company, we've got over one million lines of c#. As new subsystems appear they are being moved to other technologies (Angular + Java + Jersey + maven + guice + Jetty + Redis + postgresql). This takes time. The amount of code is tiny compared to the old implementations and the time to market and reliability is awesome.
As for me, because I'm in charge of the migration. When its gone I'm not even going to go to the funeral.
I'm more sorry for those stuck on .NET + Windows stack.
Been there done that. Modern Java + its ecosystem blew .NET + Windows out of the water, the earth, the solar system pretty much.
PS: Language syntax is probably solving 1/10 of my day-to-day needs. That is to say while C# might have a nicer features in terms of the language, the rest (lib, jvm, tools for jvm, IDE, frameworks, portability) are way below Java.
This. Most of the code I write is gluing stuff together rather than inventing new things which is what I'm paid to do.
A lot of people say this stifles creativity and is boring but the productivity is off the scale. I've built things that would cost £50000+ in dev time and licenses and take 3 months in .net in a couple of days in Java without spending a penny (reporting, messaging, email processing, document scanning, parsing, bulk processing, ETL, matching, logging). This is because someone already did the leg work and released it with an open source license meaning no license cost. Not only that, the ecosystem, Unix based deployment platforms are all easy to automate so jobs only get done once and stay working. Sure you can throw out an ASP.Net MVC web app quickly but that's the easy bit.
We can put £500,000 a year back into open source projects through time investment and donations if we replace .Net and still do better than break even on the dev cost.
Finally switching away from the horrible XML-based CSPROJ files to a more sane JSON format (that hopefully doesn't require you to list every. single. file. individually) is the feature I'd be most excited about if I was still using .NET.
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.
Finally switching away from the horrible XML-based CSPROJ files to a more sane JSON format
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.
SLN files are also horrible, I agree. Fortunately you don't have to frequently edit SLN files, unlike CSPROJ files (which are currently edited anytime you add/remove a file from the project). Both should be changed, but CSPROJ is what kept me from developing in vim during my day job back when I was making the shift. Me circa 2007 really wishes I had a JSON format without individual file entires...
I'm actually a little bit disappointed in the switch. The existing tooling around msbuild projects is great. The only "problem" is that by default Visual Studio adds item references each individual file instead.
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.
Agreed that individual item references is the primary evil for this file.
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.)
You actually don't have to list every single file in a csproj. You can use this MSBuild syntax to include all file recursively:
<Compile Include=".\**\*.cs" />
The downside is that VS doesn't automatically pick up on the file system event notifications in that case, so you have to unload/reload the project whenever a file gets added.
I imagine that if you do that, and then add files from within Visual Studio, it'll rewrite the csproj file with the individual file references. My company has had a fair share of csproj file pain caused by Visual Studio not understanding everything that's possible in csproj files. In our case we like to import some variables that give the install path and version number of our core libraries and we use those in Reference elements, but Visual Studio won't show the variables in the GUI and provides no way to add a new reference that uses the variables through the GUI. If you add a reference, you have to follow-up by hand-editing the csproj file, and it's easy to mess that up.
No, not exactly. In my experience, if you have the recursive wildcard in there and then add a new file from within VS, it'll put it in as an explicit entry next to the implicit wildcard. Then, next time you open the project, it'll import the file twice (once via the wildcard and once explicitly) and fail to build because "your class is defined twice."
I've always found it weird that they don't fix this, especially given how easy the fix seems to be:
1. When a file is added, VS could re-run the wildcard matches to see if they match the new file. If they do, don't add an explicit entry.
2. VS could turn the file list into a unique file list before passing it to the compiler.
Can you elaborate on why a json format would be better for a csproj ?
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.)
I personally find the human readability of JSON to be superior to XML in this kind of configuration scenario, but I think what I really meant to say was that switching to JSON hopefully provides them the opportunity to redesign the file format from the ground up to be more sane. My specific hopes:
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.
Readability when not using VS, for one. If you're rolling your own csproj (or need to edit it) to use with MSBuild, or some other build system, JSON is easier to read than XML.
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.
Yes, just wildcard include all *.cs files. You'll still have to list any potential embedded resources explicitly in your CSPROJ, as well as list any exceptions (please don't compile example.cs, for instance), but why add each and every .cs file to the CSProj explicitly?
Visual Studio doesn't open all of the *.cs files listed in the CSProj file, they're only pulled in by MSBuild while building. Also MSBuild supports wildcards today and it is plenty fast - it is just Visual Studio that screws it up.
As far as "exclude single files from build easier"... if you want to optimize for that why not invert the paradigm? Instead of listing every file that IS included, list the ones that aren't.
That's a fair point, but now you can develop in VS on Windows and target pretty much every platform out there. They've also announced official support for Cordova, and they have the whole Xamarin thing going on. VS already has Python support, and Node.js tools are also being added.
This is starting to look like a pretty decent environment to work in.
For a long time the CLR came in 'regular' and 'client' versions, where the 'client' version was a subset that didn't include server-type namespaces. There was also a Silverlight variant. These were pretty similar to the various JRE distributions, if you're more familiar with the Java ecosystem.
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 think he is referring to running different versions with different CLRs side-by-side. It means Platform-as-a-Service friendly. Since in PaaS you usually don't own the machine, you just run code somewhere. You don't want to be tied in with is framework X installed on the machines or not. You want to be able to pull in what ever framework you like, as you would do with node.js for example
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..
How realistic is it to use a self-hosted OWIN server running ASP.NET vNext on Mono? What can we expect in terms of performance? I was always under the impression it was pretty far away from being a viable option, Microsoft help or not.
I started a thread on the Mono mailing list a couple months ago about web hosting performance on Mono ( http://mono.1490590.n4.nabble.com/FastCGI-Performance-td4662... ). It turns out the default implementation for FastCGI is really slow. Some members of the community have created a few different implementations. The fastest one currently is a thin wrapper over evhttp which can handle over 100k requests per second on a simple benchmark. There are other discussions as well about how to improve performance.
Yet another piece of mature web-development puzzle that Microsoft is trying to emulate. That's great, and good luck to them, but my recent efforts with trying to use Entity Framework suggest that this may not be a viable solution for a long time to come.
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...
Another plug for Dapper. I tell people it's an ORM for developers who aren't afraid of SQL. It doesn't hide the database, or force you to pretend it's not there. It excels at taking your rows of data and transmogrifying them to objects.
THANK YOU for this link. It's extraordinarily on point for me. My boss went to the recent MSDN conference in Chicago, and he came away with the conclusion that we should not use it, so it may be out of my hands at this point. But your article is still awesome, and serves to illuminate exactly where the limitations lie.
You should definitely also check out ServiceStack. Dapper-like ORM, amazing web service capabilities and awesome serializers all in one place. Supports everything too (Mono, Xamarin etc).
My VB is a bit rusty, but you will need to define associations in the configuration.
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
Inside your context you load the configuration:
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
Then you can use the Include extension method (or eager loading) on the DbContext to populate the object.
Using context As New MyContext()
Return context.Builder.Include(Function(b) b.Mainline)
End Using
I had seen that linked writeup before, but was confused, because much of that code looked unnecessary for EF6. I relegated it to only being applicable to version 4. Indeed, all I needed to do (as below) was use .SelectMany(). That being said, though... Wow, your Fluent API-fu is strong.
EF is nearly the same. Really, the Linq-to-SQL story is embarrassing - it was released in .NET 3.5, and deprecated in .NET 3.5 sp1 when they released the first public version of Entity Framework... which was so horribly bad that it was barely usable.
I actually develop everything in EF first, if we need to continue the project further, i'll integrate a DDD-pattern.
If the app is going slow, i'll switch EF with Dapper. For Db hogs, i use Stored Procedures with the SqlQuery on the DataContext
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...
My company built our own ORM; it predates Entity Framework and other alternatives being viable. Recently we considered whether it's worthwhile to continue maintaining our own ORM or if we should switch. As part of the investigation our CTO spoke with a roundtable group at the Microsoft Build conference, and the consensus was that EF was not mature enough to meet our needs. This came from some people who are involved with developing EF.
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.
I have never been a fan of EF, mainly because my background is more on the database side. That said it has its place but to do everything blanket EF is not always a good idea.
You're dead on. This was the missing link for me. I'd seen .SelectMany() in examples of self-referential tables, but not as the main tool to traverse sub-child relationships.
In MVC5 the security layer works on OWIN, I'd like to see the rest of the stack like routing also decoupled from modules and handlers, fingers crossed for MVC6.
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.
I guess you weren't aware that Hanselman also owns an iPhone :P
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.
Good catch, but not terribly surprising. Developers don't use IE except when they have to test for non-standard behavior. IE hopefully will soon go the way of the dodo - I no longer see any reason for it to exist.
I would most definitely like to also know why? There are many developers that work using Microsoft technology, everyone organisation does not build their services or products on open source.
I shouldn't feed a troll but, look at job descriptions from banks/insurance companies/science/education/betting/automative/health based companies. Do you see a simple word being related to rails?
ps: I know of some that do, most don't, and they pay a LOT more than all the 'cool' companies.
> ps: I know of some that do, most don't, and they pay a LOT more than all the 'cool' companies.
That's fine if you are working for the money. Personally, I prefer the "cool" companies, even if they pay less. For some people, wearing a tie and spending 40 years working for a big bank or large insurance company and then retiring is an option and I respect them. It's not for everyone, however.
What is so 'cool' about those companies though? Not trolling.
Google -> Adsense are their main profit and from where the real top dogs go, the rest work in projects that most of the time go to the crapper. A lot of their big name projects are based on C++.
Facebook -> No idea, but they were using PHP and C++ right? (sorry, I don't follow much of FB engineering)
While I don't want to piss on Rails or Django or whatever, I've hardly seen a lot of companies that do use them to be working on really cool projects (and not another CRUD app for social horse riders to exchange organic cucumbers (hyperbole)). A lot of the 'cool' stuff that is happening in our world seems to be coming from more fringe languages (R, Julia, Haskell, Scala, F#) or old mainstream (C, C++, C#, Java) than the Ruby/NodeJS camp. If we go mobile, then we are even talking have to acknowledge both mainstream languages to develop are Java and a superset dialect of C - Objective C.
So honestly, if you take the beer and ping pong tables out of the equation, what are the advantages of these self-entitled cool companies over the others? (Btw, most big companies have pool tables, table tennis, gyms, beer, wine, XBoxes etc as much or more than the startups, they just don't post pictures of them on their blogs).
The other day I had a meeting with some folks in a company that uses .NET and the CEO showed up in a gym shirt, shorts and sports shoes. You're conflating the technology with the places it's typically used, there are places that use RoR where everyone wears a tie.
I agree they tend to be hidden behind the scenes companies. But those companies can be nice companies to work for(Sane work hours, good benefits, not expected to work overtime etc).
That's no longer completely true. While the core continues to run on Windows, SQL Server and .NET, pretty much everything around it is Linux-based and without that additions, the system would be unable to maintain its current performance.
Microsoft is still the one leading .NET, defining what .NET is and what technologies it includes (and which it doesn't). While Mono is a nice subset that runs on non-Microsoft OSs, .NET is pretty much a Microsoft-centric technology.
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.
Technically, Windows is no longer a windows technology, since Wine exists, but still it's mostly windows. Can you even run Visual Studio on another platform?
Visual Studio is still pretty dependent on Win32 / x86 under the hood - a lot of the UI was ported to WPF and more of the tooling, including the compiler, is being ported to C#.
So no, I think VS for Mac / Linux is still a ways off. They're moving in that direction though - wouldn't be surprised if they bought Xamarin in order to make it happen.
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.