Rock on, Microsoft — this is great news for Windows developers. As much as the open source community (of which I am a part) loves to rag on Microsoft, they seem to have recognized the threat of platforms moving off of Windows (Steam, iPads, Android, ...) and are taking reasonable steps to encourage development for Windows (make the developer experience better).
This — a reasonable response to a potential threat — is a huge step for Microsoft. Kudos, VS team.
As a (now former) long time Window developer, and even though people like to bash on it, I still think VS (>2003) is the best god damn IDE I've ever used.
And with .NET it leaves everyone in the dust, IMHO.
You've obviously never suffered a large project. Crashes, memory gobbling, random debugger failures, glacial speed, lag, project configuration corruption, UI glitches, refusing to load projects, half complete refactoring operations, search/replace just stops, having to reset environment at least once a day, grey screen of death.
And that's just the IDE. CLR is the only framework and language combo I've used which will quite happily just stop working with no human intervention one day.
It's a bag of shit for me and I resent using it.
For ref, I've been building software on windows since 1994 from win32 to wpf to asp.net to mvc to WCF.
The only positive thing I can say is the money is good, but it's danger money.
Yes, agreed (having worked on middlish-big projects with maybe 40 VS projects for each solution, 45+ minute re-compile times (not from scratch) on the latest gen CPUs, etc) with several hundred million LoC but believe me, if you think that's bad, you don't want to see Eclipse/NetBeans/XCode/etc. with a project a thousandth of that size.
Slightly curious, what kind of projects were you working on that are "several hundred million LoC"... wouldn't 45-minutes be reasonable for that many lines of code?
I ask because I've never even come close to touching a project with that many SLOC and I was also under the impression that most modern operating systems are barely fitting into 100million+ LoC category, correct? This is your chance to redefine my perspective on "big project" haha.
Some C# developers use T4 to generate data access code, for instance. This can amount to several hundred thousand lines of code for a moderately sized database. If there are several large databases being accessed, like is often the case in reality, then I could easily see there being millions of lines of automatically generated code in a single project.
I think when you hit several hundred million lines of code in a solution, a governor kicks in to give you more time to think about just what the hell you're doing.
I know nothing about nothing, but having that many projects under the same solution its the biggest clue that you are doing something very wrong.
Even if you have a reason to have 40 projects in what should looks like one solution you can still create various solutions files with just the subset of projects you need. No one works on 40 projects at the same time.
We have a solution with more than 80 C# projects, and visual studio 2010/2012 handles it fine on modest hardware. I usually hit shift+F6 to build just the current project when I'm iterating on some change. This builds very fast because our individual libraries are small. It doesn't really feel "wrong".
Unless u have a very good reason to deploy and distribute 80 different DLLs it should feel wrong.
Many people think that In order to have a well layered and decoupled application you need to breakup every single piece in a separate project and that makes no sense. Thats what folders and namespaces are for.
For C#, maybe (not enough experience, but I would be surprised if what you say is a good practice).
For C / C++: You do that with static libraries, not shared libraries, and that's the only sane way to work: Have all library projects part of your main workspace, so you can easily debug and fix stuff in them, yet manage them independently.
For production/distribution you can always use a tool like ILMerge or SmartAssembly to merge dlls/exes together into something that makes sense for that particular distribution. I've had plenty of success with both tools.
Saying that, I do get what you're saying. Good practices can be taken to the extreme. Some approaches such as prism, take the idea of breaking the UI up into modules that can be registered with a shell - where on reflection, that type of flexibility is rarely going to be needed.
It's sadly far too common for .NET developers to carve up their solutions into far more projects than are necessary. This can seriously slow down compilation times.
Actually if you are changing a dependency right at the bottom of the chain, it makes things much faster as each compilation unit (assembly) is less likely to be coupled to the changed code.
Large assemblies are the enemy of compilation time as you can't partially compile them (like you can with java individual classes).
Yes but that's not the case if you're changing a dependency in the middle of the chain, as is more commonly the case.
Additionally, as far as I can tell, the main thing that slows compilation down isn't so much the actual compilation step as loading in and copying all the project references. Visual Studio does this separately, from scratch, for every project that you rebuild, since each project compilation runs in a separate csc.exe process.
In that case it's probably sensible to break it up not only into separate projects but separate solutions too.
What bugs me is when relatively small solutions are broken up into large numbers of projects. Very often it's done for no reason whatsoever other than aesthetics. They're often divided up "against the grain" too, putting every layer of your application (presentation layer, business layer, repository, domain model, services, interfaces etc) into a separate project, with the result that a single task requires you to make changes to several different projects.
The general rule that should be followed here is the Common Closure Principle: classes that change together should be packaged together.
Half of those projects could be class libraries. You can't put those in different solutions cause you miss the whole point of having everything tied up.
We don't have hundreds of millions LoC, but we have a couple of million. We solve the problem you are describing with svn:externals, pulling in the DLL/PDB from other project/solutions as needed on svn up.
I agree it's not as comfy as having everything in one big solution, but being able to count your compile time in seconds as opposed to minutes makes it worthwhile.
We used to use several different solutions with subsets of the projects, now though I use the solution load manager extension, http://visualstudiogallery.msdn.microsoft.com/66350dbe-ed01-... which brings down load times significantly. It basically lets you specify how projects should be loaded, so most can be loaded on demand. We have ~150 projects in total, ~10 million LOC, and VS handles it almost as well as a small solution.
I'm pretty sure I've read on an msdn blog that visual studio was 100 million loc total. I would be very curious to know what kind of projects you're working on.
My 100 MLOC figure is incorrect. The blog post actually states: "With upwards of 50 million lines of code, broad changes to Visual Studio can take some time to fully incorporate."
Eclipse is fast, but it needs to be configured well and run on a decent system. I guess the same is true for VS. After all both wouldn't be so popular if they wouldn't scale.
This is one of those anecdotes that just pollutes discussions, allowing people to cheer on their biases. My anecdote is that Visual Studio deals with very, very large projects with gusto (albeit far below the absurd "hundreds of millions of lines of code" scenario described by someone else, which if in one solution borders on insane). The CLR has worked ridiculously well for years on end with nary a hiccup in sight. And so on.
Visual Studio isn't perfect, nor is any IDE (Eclipse...xcode...Geez, turn on the coffee machine because we'll be spilling complaints all night long).
sounds like you should get a new computer. 1994's a long time to go without at least a fresh install of windows - have you tried defragmenting your hard drive?
I've got a nice Dell Precision dual 4 core 2.8ghz xeon, 32gb of ecc ram, 500gb sas 15k RAID, Samsung 840 pro scratch drive and quardro card. What am I doing to deserve this pain?
My 5 year old Lenovo t61 is fine for ALL other tasks in all other languages.
I guess that taste in IDEs is a very personal thing. I am using Visual Studio 10 at the moment to do C++ coding and it is by far, and without question, the worst IDE I've ever used.
I find it slow, buggy and quite unfriendly. My guess is that people pay money for plugins to get it fit for purpose.
IDEs I prefer: Eclipse, Netbeans, IntelliJ, QtCreator
VS is the only large scale IDE I know of that refuses to add a search bar for options. Both Eclipse and Intellij IDEA both have it. Trying to deal with finding what you want in the myriad of options VS has is tedious. Also changing syntax colorings without something like resharper is also taxing.
Thanks, I would have never guessed it was that sort of search in 2012. I would have figured the more intuitive option was to put it within the actual options area. Then again, I guess I should have known better with the way search is in the rest of the Win 8 UI (though I don't use Win 8 enough to instantly think of that, lol).
But if you talk language, Java has never held a candle to C#.
The original C# language and virtual machine was inspired by Java.
Then, C# got:
* Better generics
* lambda expressions
* the yield keyword and compiler magic for iterators
* explicit interface implementation (rarely needed, but very well thought-out for when you need it)
* LINQ!!!
* Type inference
* Dynamic keyword
(I'm forgetting some things, it's late).
Anders has guided the C# language brilliantly ... Java has been outpaced at every step of the way. So many somewhat radical features have been added to C#, and from my standpoint, every single one of them was very well-done.
Language alone does not mean tons of productivity gain. Building software requires more than just syntatic sugar.
C# has all these features yet I have never seen killer tools that changed the .net landscape like Rails did with Ruby. While I would not call those language features smoke and mirror, I argue that they are merely nice to have and not ground nor thought provoking.
At the end of the day, Java ecosystem still move forward way faster than .net. Spring, cloudera, datastax, alfresco, liferay, ehcache, jboss, tomcat, Embedded server like Jetty, and other great, free, mature, serious, and open source tools are available at our disposal vs taking to sales rep to buy licenses, which are a common activity in .net world.
I could pick those up one by one, but time does not permit. You are largely correct that there seems to be more experimentation in the the java open source ecosystem, and that some of the key parts of the same in .Net are ports from java (e.g. nUnit, log4net, nhibernate). Though in all those cases there are alternatives, it's just that the particular tool mentioned is most popular. Possibly due to familiarity.
With maven, I'm not sure that it's a good thing https://www.google.co.uk/search?q=maven+hate and there are lots of ways besides msbuild to do builds and installs. The rake, jake, psake family of tools are all viable.
With things like Cassandra, I don't care what language the server is written in as long as I can connect to it. This is IMHO the way forward, and not just for .Net. Though if you're looking for a noSql db written in .Net, there is RavenDb.
Sir, Maven is an awesome thing. Would you want me to do a query in Google for each and individual .net and the word "sucks"? Since when that matters?
There will be minorities that just happened to dislike everything. There are also people who just happened to use maven in the wrong way and ended up fighting with it.
This suggests that you have never used and experienced Maven. Combined eclipse with m2clipse and you will get awesome development experience. Imagine not having to download 3rd party library manually by visiting their website. Imagine autocomplete of the freshly acquired 3rd party lib via your IDE to also shows you the javadoc. Imagine trying to navigate to the 3rd party class and method implementation without setting up your IDE or messing with path/folder setup automagically. You cannot do any of these in .net nor vs.net.
I know RavenDB but can you compare it with Cassandra, Hbase? Not by many many miles. The latter two are battle tested by top most traffic website while the former has yet to reach that level.
I also argued that the javaee 6 stack provides way better, simpler, and modular approach to building back end systems. There is no equivalent EJB 3 in .net (I will be damned if you do another google query for EJB sucks. the old one is, but not the new one. Also experiencing the tools before making your judgement would not hurt). All in all .net framework for the most part of it have always been behind Java (except in the category of presentation/UI).
I prefer not to continue the discussion when the obvious is there right in front of us: C# has cool language features but honestly nothing has been groundbreaking in the .net world. The last one probably was asp.net mvc and the changes in the core asp.net as some sort of an api instead of the old asp.net webform stack, mimicking the JEE web profile approach.
Rake and the rest can be considered sub features of maven. Not. Even. Close.
> Maven is an awesome thing. There will be minorities that just happened to dislike everything
I don't know maven from a bar of soap, but would you diagree with this recent hn post then? "Why Everyone Eventually Hates or Leaves Maven" http://news.ycombinator.com/item?id=5105164
Now I've had a look at the basics of what Maven does ... http://en.wikipedia.org/wiki/Apache_Maven " It can also be used to build and manage projects written in C#..."
Honestly, if it was that far beyond everything else, people in the .Net community would be talking about it a lot. And they're not.
> Imagine not having to download 3rd party library manually by visiting their website. Imagine autocomplete of the freshly acquired 3rd party lib via your IDE to also shows you the javadoc. Imagine trying to navigate to the 3rd party class and method implementation without setting up your IDE or messing with path/folder setup automagically. You cannot do any of these in .net nor vs.net.
Factually incorrect. The equivalent happens in VS via nuget right now.
The fact that many people in that hn thread said they had no problem with maven? Again sir, what you were doing were just linking gossips as oppose to using it, trying it out, experiencing it, understanding it uses/features.
I can link to many2 .net blog posts how people have left it because it is too limiting but that is not the point. Personal preference does not equal real world evident that suggests that .net is not that limiting.
Last but not least, your nuget can't:
Run unit tests without any setup.
Run integration tests without any setup.
Run code analysis as part of build.
Run code style as part of build.
Package your project and make it ready as dependencies to hour other projects easily without having to import the whole source folder as another project below a solution.
Deploy to hour app server.
Generate javadoc or .net doc.
I recalled there were challenges to use maven for .net projects. Would you want me to query people praise of maven? Or would you want me to query how .net community wishes or is looking for maven equivalent tools in .net and how nuget is just a piece of subset of what maven can do? Or would you like to take a look the current landscape of build and dependency tools and how almost all of them mimic what maven can do?
The equivalent of maven would be msbuild, msdeploy, nuget, and various other tools in which you have to setup manually and requires a lot of effort. In the rails world they required gems, rake, and bundler to match maven capabilities.
I think I've explained too much. There is absolutely no point to continue the discussion if all you do is merely performing google search query of Java bashing because likewise can be done with .net and that would be a time wasting.
Otherwise, let me know when there is a huge revolution in the .net world that shook the software development world because so far you guys just following java footsteps in almost every area except the c# language syntax.
C# - A language that can do (almost) everything: mobile, web, desktop, etc (Java still beat you guys on embedded devices).
VS.NET - An IDE that can do build, run your tests, UML modelling and many more...
Final thoughts on Maven: What I care is a tool that perform build for me and in 2013, validations are part of the build: validate that your code compiles (compiler), validate that your code can be packaged according to the agreeable standard (dll, jar, whatever), some level of behaviour validation (unit-test, integration-test) .
If you disagree then perhaps we have philosophical differences when it comes to good software engineering practices since the beginning.
Eventually you either: build something from scratch to mimic Maven on .NET ecosystems or use various tools (MSBuild, NAnt, NuGET) that perform the same workflow that Maven gives to you. Either way you got nothing like Maven in .NET ecosystems which is a huge loss for me since why would I learn various tools or build some piece of the puzzles on my own when I have _the_ tool that can do what we all have to do on day-to-day base anyway...
You're not saying anything remotely close to display how the .NET ecosystem is richer than Java. Perhaps because it isn't.
PS: Maven is composed by plugins, the fact that some of the plugins can do unit-test while others can do static code analysis are just... awesome.
Sorry but I don't share your view. I am using IDEA everyday (Python). It's great, but it's a HUGE memory and CPU hog (although IDEA 12 is much better). I always lament VS...
Java just doesn't scale, if you want fast code you wont use java. C++ one of the best, and for quick development c#, you can always invoke C++ libs in C# anyway and both are supported in visual studio. If your into webdevelopment even there java is slow.. despite it has some fun libs, but most people use them because their lazy programmers, a good programmer wont rely that much on much external libs
Twitter uses Java. It seems to survive major events fine these days. I'd say it scales reasonably. You also have to take into account huge enterprise deployments.
As for 'fast' it really depends what you mean. Nobody's going to dispute that running a compiled application written in C is going to beat the pants off anything running on top of a VM, but is that speed factor important all of the time? Of course it's not. Most of the time a short wait is perfectly tolerable in exchange for the assistance in writing correct code that languages like Java can provide.
I attempted to write a simple web project in Java to learn it. I haven't used Java before, I normally use Python for web stuff and C# for other misc stuff.
It was hell. I installed JetBeans IDEA quickly enough, but it went downhill from there. My AntiVirus (Kaspersky) fucked with Java 7's networking meaning it couldn't connect to anything, so it took an hour and a lot of googling to fix that. Next step: make a struts2 project. Wait, maven doesn't like the archtype IDEA gives it so it explodes and doesn't install it. Ok, do that by hand. Next install a webserver, which one to choose? Install one, doesn't work with IDEA - have to install an earlier version.
Ok. Finally got a blank project up. Read the docs for struts2, brain hurts, uninstall everything, fire up VS 2012 and write the whole thing in C# and run it on mono. Easy.
This — a reasonable response to a potential threat — is a huge step for Microsoft. Kudos, VS team.