C# and .NET get a bad rap for being created by Microsoft. But one thing that can't be ignored is how polished their development tools are. I absolutely love coding in Visual Studio.
To many young developers these days, and IIS server is the thing your company keeps in the closet to some sluggish legacy monstrosity which has been replaced for years with a better open source solution, but can't be put out of it's misery because it still holds some data that might be useful sometime.
Is any of this true? I have no idea. I'm just letting you know the rap it has, and the perceived reasons for that rap.
Getting a web app built on .NET/MVC4/IIS running on mono isn't a trivial endeavor, and the open source implementations rightfully tend to lag behind the closed implementations.
.NET seems to be well worth the cost of running Windows, but the consequent platform and vendor lock-in is still a concern for us.
Maybe you should contribute a better one. ;)
Deploying everything can be one-click. VS even has git integration now.
The old IIS is like you describe. But, the latest IIS is fast and easy.
In all honesty this is what I find from most unknowledgeable Microsoft bashers. They tried out the MS development stack with Classic ASP, Visual Basic 6 and SourceSafe 15 years ago. Then in their head they're contrasting that to the latest RoR tools with github. Many are not even aware of ASP.NET MVC and how different it is from ASP.NET.
Now, this isn't to say there aren't knowledgeable Microsoft bashers but this is what I find from many of them that aren't knowledgeable.
I can only say after managing a project with 400 controllers that it doesn't scale up to complex UI or even medium sized projects well. Also we're reaching 5 minute edit, compile, run cycles (on E5 Xeons!). Also production debugging (which is inevitable one day) is a PITA on CLR based projects.
It has become the opposite of all promises. It's like wading through tar.
To be honest after over a decade of .Net experience and over a decade of Win32/COM etc before that, I'm tired of it all.
I wrote my first Objective C+Cocoa application last week (an RPN calculator) and it's where I'd rather be. It was fun and frustration free. I tried to do exactly the same with WPF/C# a few weeks ago and it was horrible.
You complain about singletons, then prefer a language where the use of [sharedInstance] is extremely common. Objective-C is singleton hell. Both in third party code, and core libaries.
C# is vastly nicer than objective-c, and I'm a iOS developer. I'd rather use C# or Scala with a IoC container to handle the lifetime of objects, rather than using singletons.
The difference is that your Objective-C/iOS application doesn't consist of thousands of threads which require synchronised access to these objects. It's a pretty static thing with an event loop. Possible a couple of background worker threads.
For a desktop application or even mobile application it's fine but for a massively scalable back-end enterprise system it's a pain in the butt.
Singletons are not for managing lifetime as well. They are a container for an object -- nothing else. Lifetime should be managed separately i.e using a container/service locator or something. Everything I've seen Cocoa-wise is pretty decoupled so far. There are some crimes but only inexperience seems to require them.
And since you attribute those problems to .NET, your solution is a small project (which incidentally uses another technology).
Not dismissing your argument as a whole, but you have to admit you made at least one giant logical fallacy right there.
The problems with the project scaling are primarily down to the infrastructure: MSBuild and the C# compiler are damn slow as is the whole rip up and replace assembly system in .Net. When you have something at the bottom of a dependency chain that is quite deep (with any enterprisey project), you have to recompile all consumers and therefore everything that depends on them and so forth. A single line change means you end up compiling the entire system on top of it. All 200Mb of DLLs need building again. That's a long time. Not only that, when it comes to testing and runtime dev (i.e. using the web front end), reloading assemblies and performing JIT is really expensive and time consuming.
Every time you do something, mount everest is destroyed and recompiled twice: one to IL and once to native. This is expensive and seriously screws productivity. It doesn't scale development-wise. Simple as. This is not specific to my current project - I've consulted at various companies since 2002 and that's exactly what it has ended up for everyone, every time.
Going back to LLVM/XCode. I'm not particularly experienced with the specifics of the abstraction that Apple provide, but I've spent 20 years building monstrous bits of C on top of Unix/Linux with GCC and Sun compiler suite. That's what we're still dealing with but we have LLVM which slings code out much faster than anything we've had before. We also have incremental build support (individual .o files per source file), faster linking and a runtime system that doesn't require recompilation.
I'm not saying it'll realistically turn into anything better at the end of the day but one some points:
1. The Xcode tooling is like lightning, even with a 200,000 line C project I imported from a previous project.
2. The startup time is 487ms compared to the same thing in C# of 2.2s to first output and 10.5s to it actually doing something.
Think I've explained myself better now. Sorry for the initial confusion.
This just isn't true at all. Even in COM days it wasn't true. With COM, if you preserved binary compatibility you didn't need to re-compile a client if you compiled a new version of a DLL it calls. In .NET it's even more forgiving. Sure, if you change something major like delete a bunch of properties that are used in the client then you have to recompile the client. But in many cases you don't.
Beyond this, if your architecture has 200 DLLs, it might be completely appropriate but it is a suspect architecture. I manage a .NET project that trades $4 billion of fixed income instruments per day, interfaces to three trading platforms, interfaces to 13 custodial systems and 7 different data providers. It uses about 25 DLLs and is quite manageable.
Finally, how often do you recompile a DLL that is "quite deep" in the dependency chain? Generally, such low-level DLLs should do very little. For example, maybe it's appropriate to change them if you change from Oracle to SQL Server but how often would that happen?
In .Net, any contracts that break between layers in your dependency chain force a rebuild of all layers above it. This is not unusual in .Net projects as the components are bound at runtime.
There are not 200 DLLs - there are 200Mb of DLLs. Total count is 122 DLLs.
This particular beast handles integrations with over 100 systems using vastly different non COTS integration methods, has over 2500 tables, 950 domain objects, 400 controllers, 45 databases, 200 API endpoints, async background processing and piles of MSMQ queues. Data volume is terabytes. It's a behemoth and it's been around for 33 years in various forms.
If you, as we do, change architectural components and APIs, dependencies are broken. The main case for this is when we version our API. We have up to 3 API versions in production. When someone introduces a new API version, the oldest is deprecated and all the historic versions are ported to the newest internal API. This is where it becomes dependency hell.
However it's a fine way to avoid technical debt!
While developing with MS technologies, you must accompany any code, tests and documentation with a "My License" folder with "licensing.cs" files to calculate, the implied licensing costs of each piece of code you develop along with all required MS components down to the metal. Finally, you must make sure the relevant "My License/licXX.cs" gets updated with changing licensing policies.
Next to your developers, designers you must staff an MS certified licensing specialist, or for larger projects a License team with a director level position to analyze, plan, design, test, negotiate and pay licensing costs.
The memory model is, IMHO, where Microsoft is pushing the limits of the existing C# language.
What has Microsoft changed in the .NET memory model that makes you think they're pushing the limits?
From what I can tell, the .NET memory model is one of the things that has changed the least. The languages have changed a lot faster than the memory model.
One problem I'm running into at the moment is I'm trying to port a vendor's reference SOAP Service over to Mono/Linux and their provided secret sauce DLL is blowing up when calling their objects' constructors. I'm yet to pin it on Linux or Mono. Here's hoping the vendor is Mono friendly and willing to debug it. If not we're going to have one oddball Windows server in a sea of Ubuntu EC2 instances.
Ironically, we have some large-ish C# code-bases that run on everything but Windows.
What are the features of Resharper that make you say VS isn't complete without it?
I think it's because I find the VS interface incredibly cluttered anyway, and Resharper just makes it worse. The right click menus are already 10 miles long filled with useless clutter and when it starts mucking around with the already edging towards overwhelming intellisense pop-ups it just annoyed me one too many time.
After 2 weeks of trialling it then only thing I was really using was the "go to implementation..." but I've long since given up on the ridiculousness of making everything mockable anyway so it's only occasionally useful.
The worst thing about VS is how slow it can be sometimes, even on incredibly powerful machines. In the end it's a glorified text editor and everything should be secondary to that.
There's nothing more annoying than pressing ctrl-f (find) and then have it pause for 1/2 a second because it's trying to parse a massive html tree for intellisense you don't even need because you're just trying to delete a single node you know the name of.
The text editor is only a tiny part of an IDE, the bits that are added are quite important. Integrated debugging (with edit+continue while debugging), integrated version control interface, integrated build system, integrated profiler and much more makes it so much more productive than having to e.g. do debugging with recompile/restart turnaround times.
That's the main reason to use an IDE, in my mind, along with the ability to display the call sites of a function.
> integrated version control interface,
Never noticed any advantage compared to a shell with git or git-svn, personally.
> integrated build system
Depends what you mean by that. What's precious is the ability to detect errors before doing a build or testing anything. "Integrated build systems" in general I find often fall flat on their face when something outside of the IDE touches the files.
It's also the thing that's most important to flow, to producing, not navigating or testing.
That it can pause and stutter when you're just trying to do a simple edit is pretty silly.
I love VS and it's one of the things I always miss whenever using something else, but there's a lot of annoyances and a lot of sub-par features and some you should never use features.
I notice you said "integrated version control interface", if you're talking about TFS, it's terrible. Stop using it. The interface is terrible, all generic tables that you can't tell apart. It's a massive effort to see file changes. And worse than all of that, the actual version control system is shockingly bad, even compared to SVN, let alone Git. You're a madman to be using TFS, it's so bad.
Next big thing is navigation. Go to type, go to symbol and go to file are super quick and means I never go to the source tree to navigate the solution.
Symbol search is incredibly useful, that was a revelation when somebody told me about it. But Visual Studio has had that since at least 2010, I think maybe 2008. Resharper's is a bit more complete, but I think the VS built-in one is a bit faster. The VS native implementation is Edit -> Navigate To, the default key combo is ctrl-comma, but I think Resharper takes that combo for its own purposes.
I haven't lived with it long enough to find out if it's as easy to break as Eclipse when you install the wrong combination of plugins, though. Oddly enough, its vim emulator plugin is much better than what I found for Eclipse, which I find quite ironic.
[1]: https://wiki.gnome.org/Projects/Vala/ValaForCSharpProgrammer...
I don't get all the hate?
fortunately those days are over and they've become mostly irrelevant, but everyone knows that given half a chance they'd do it again...
Everyone I know for the most part types their documents in Microsoft Word on Windows computers. Sure, they got smartphones and tablets for the media consumption and facebook, but they don't even know an alternative "big boy" OS exists. They think Windows == computers. Which I think means MS is anything but irrelevant (no matter how hard I try to stuff opensuse down everyones throat).
MS Office is the defacto file format for office work, and MS Office on non-Windows platforms (ie. Mac) is so bad as to appear intentionally crippled.
Microsoft makes most of its money with its business products, so it's not cheap. Some companies just simply don't want to pay the Microsoft premium.
I also should have mentioned Mono, but that's a different topic.
http://visualstudiogallery.msdn.microsoft.com/0e53eaf6-b031-...
After trying VS for a couple of projects I found it completely baffling and backwards.
And I don't think this is because VS is bad, but because the way I approach software is completely different. I want to be able to compile things from the command-line first and use the IDE to edit the code. The way this happens makes it much harder to use other tools I like such as Jenkins. I can't ssh to a windows server.
On the other hand I can see where somebody might be frustrated that they' can't remote desktop into a linux server or had to learn a new config language instead of having a GUI.
IIS is another beast altogether. I've had to help customers set up their servers and the instructions are a set of screenshots that are hard to follow and easy to skip. Most apache/nginx configs clients can copy/paste fragments into their configs to get things working.
I could have 1000's linux servers up by lunch, but it would probably take me all day to configure one windows server. You probably have a better solution for this, but I've not come across it.
For me VS C# probably wouldn't be too bad if it didn't require running windows.
For future reference you can compile VS projects from the command line if you want using MSBuild, that's all building in VS does. As far as IIS is concerned you can maintain all it's configuration via config files so an experienced Windows admin could have 1000's Windows servers up by lunch too. They'd probably take all day to get a Linux server up though.
I remember looking into MSBuild, but I couldn't get it to work. I must have had some path set wrong or something.
Err, no - MSBuild, is basically a clone of Ant, except that it is meant to be generated by Visual Studio. This is completely backwards from what happens in say Java/Scala with Maven, SBT or Gradle.
The advantage of having the build process external, as happens with Maven and Maven-like environments, is that you can easily automate things by writing plugins, plus you're not tied to the IDE at all. You need to push your artifacts into a repository? There's a plugin for that. You need to sign your artifacts with a PGP key? There's a plugin for that. You need to automatically increment the version number on releases? There's a plugin for that. Etc, etc... and all of these can be used in continuos integration processes.
Plus, MSBuild doesn't handle dependency management, which is completely retarded. You've got NuGet now, but again, Microsoft had to over-engineer it, to make it IDE friendly and thus the ease of setting up your own Maven repository is gone.
And have you tried building MSBuild projects on top of Mono? Try it. It's fun ;-)
Basically only a .NET developer that never experienced other environments could claim that MSBuild/VS.NET is satisfactory, but for the rest of us, it's like trying to do software development with early-2000 tools and IMHO, that's where the entire .NET ecosystem is.
MSBuild does not require Visual Studio
> The advantage of having the build process external, as happens with Maven and Maven-like environments, is that you can easily automate things by writing plugins, plus you're not tied to the IDE at all. You need to push your artifacts into a repository? There's a plugin for that. You need to sign your artifacts with a PGP key? There's a plugin for that. You need to automatically increment the version number on releases? There's a plugin for that. Etc, etc... and all of these can be used in continuos integration processes.
The equivalent of plugins for MSBuild is Tasks
> Plus, MSBuild doesn't handle dependency management, which is completely retarded. You've got NuGet now, but again, Microsoft had to over-engineer it, to make it IDE friendly and thus the ease of setting up your own Maven repository is gone.
Yes it does via NuGet, and again NuGet has no dependency on the IDE
> And have you tried building MSBuild projects on top of Mono? Try it. It's fun ;-)
Yes I have, what's your point?
> Basically only a .NET developer that never experienced other environments could claim that MSBuild/VS.NET is satisfactory, but for the rest of us, it's like trying to do software development with early-2000 tools and IMHO, that's where the entire .NET ecosystem is.
Thanks for the personal and professional attack at the end there, nice touch
Not necessarily true, I believe some versions of Visual Studio have their own compiler which is different to the one used by MSBuild:
http://blogs.msdn.com/b/ed_maurer/archive/2008/06/11/a-tale-...
Where would you suggest I go to find the best way to handle this?
You want a text editor, not an IDE.
I want to be able to access the compiler external from the IDE so I can automate builds/deployments easily.
Now I want both types of builds to happen in as close to the same manner as possible so they're consistent, but both are important.
Assuming that running Windows is a non-issue, the parts that really, really bug me are:
- Background operations suddenly become foreground operations that stall the IDE with a dialog saying "A background operation is taking too long."
- Misclicks spinning off long background tasks that stall the IDE.
- Automatic refactoring/code analysis that will stall the IDE.
- Incredibly aggressive automatic reformatting.
- The Microsoft Account agenda. VS2013 wants me to sign-in with my Microsoft account on so many different occasions: settings sync, Azure, Windows Developer account registration, auth refresh, etc... which wouldn't be so bad, but I'm signed in via Windows 8 already, adding insult to injury.- Nor misclicks stall IDE
- Nor automatic refactoring analysis stall IDE
- Automatic reformatting is a once click option to disable and is not terribly aggressive in VS 2010 up.
- wants you to. Not forces. So, by the way, do JetBrains, NetBeans, Oracle ...
That said, my experiences with Visual Studio only serve to underscore the point that my peers would prefer to avoid running a Windows VM altogether if there are open-source alternatives that are good enough.
As far as virtualization, why are you working in a virtual environment? What are your machine specs? What is the emulator? I'm genuinely curious, because I haven't encountered any of those issues.
Virtualization is kind of a red herring here, because as mentioned before, this happens on an array of workstation-level hardware (quad-core Xeon/i7, 16-32GB configurations, SSD).
The point is that virtualization makes these already-painful existing issues much more pronounced, such that my peers actively want to avoid spinning up a Windows VM for a project. These experiences, whether agreed with or not, were largely responsible for the immediate revulsion my team felt to Windows-based solutions. I can't begin to explain how excited people were at the prospect of not having to use Visual Studio anymore when ServiceStack rolled out at my prior company.
My use case for virtualization is mobile development spanning iOS, Android, Windows 8 and Azure-backed services. The last few companies I've been on-site at outfit their employees with high-end MacBooks, with developers occasionally using virtualized Windows under protest.
If you have to work with the tools daily, then take the time to learn them. You'll thank yourself.
I'd be inclined to agree with you if it were just me or one machine, but these are characteristics that I'd use to describe Visual Studio across a number of machines, projects and teams over several years.
I find a 100project C# solution (200mb deploy) to be perfectly snappy when using & fast to build. There are and have been zillions of annoyances with VS but perf hasn't been one since I set my machine up properly (in the office most of the developers complaining about build perf could cut 75% or more just by excluding certain dirs from AV scan).
I'd be as upset by a group policy demanding I scan my VS intermediate dirs on access as I would be by a no-chairs policy at the office. It's a dealbreaker.
Converting off of STA in legacy code is extremely difficult due to the transitive nature of it as well as the fact you likely have very large and complex types which were never written to be thread-safe because the STA protected them from that (let's not talk about re-entrancy though :)).
It is getting better since managed code has MTA semantics by default, but even with async code all it takes is one person calling Wait on a Task on the UI thread...
A huge sync API surface that is publicly callable also doesn't help. Even if you want to make things async under the covers you generally can't since callers are expecting synchronous semantics and there is no (good) way to make work async, present a sync calling surface to callers, and not block the UI thread (if you say nested message pump, you lose :P)
I'm not talking amazing hardware either, just a computer I put together myself.
They're free, period. You don't need Visual Studio Pro -- you just need to install the isolated shell.
Contrast that to your scenario. First, I need Windows, which is fine for most, but not me. Then, my prod setup has to be Microsoft based. I've yet to find a $5/month IIS-based host with SQL Server (apathetically, I haven't looked much). Oh, and Visual Studio. I can probably get by with Express, but at some point I expect I'll find a wall that forces an upgrade.
Microsoft has come a long way, but when I started years ago, I couldn't swing a Microsoft-based environment. VS was prohibitively expensive, and my parents' crappy computer couldn't run it. But I could learn PHP for free, run it locally through XAMPP, and be off to the races. Microsoft's never won me back, and your CMS is paying that price.
I wanted to redevelop our CMS in MVC (we missed the MVC train by about 2 months so it's Web Forms) as I like how much more lightweight it is but to be honest, I would rather completely redevelop in another language as it would help our adoption rate with our clients.
The painful thing is, I know how powerful our CMS is (to our clients at least) but it's such a hard sell.
We normally deploy onto our own cluster BTW as we roll out core updates through our own servers so everyone feels the benefits of new modules and admin updates etc so the hosting is generally taken care of.
If you have problems selling due to the platform, I think the main issue is your target market, and not .Net in itself.
One reason to favor C# is that it just has better IDE support, hands down. In addition, if I'm working with C# devs it's just nicer to use something everyone already knows.
As far as the language goes, though, perf sensitive stuff often makes more sense for me to do in C#. This is a combination of reasons:
1) I generally have a better sense of the IL that a given C# program will generate. This is both because I am a C# compiler dev and because C# is closer in form to the .NET IL than F#.
2) I have a better sense of the actual machine code that will be generated for C# code by the JIT. This is almost entirely because I am a dev on the C# compiler.
3) The language/framework teams are very data driven. The population of F# developers and F# code in comparison with C# developers and C# code is like a drop in the bucket. There are hundreds if not thousands of C# developers for every F# dev. It is almost a statistical certainty that C# JIT hot spots will get optimized before F#.
4) The fastest F# is usually very imperative and is essentially the same as the C# code.
Even in C#, imperative style will be faster. Without better type systems and much better compilers, that won't change (but F# could implement fusion a la Haskell). It may be "essentially the same", code, but with 1/20th the type annotations. It adds up.
I've not found a case where there'd be an excellent C# programmer not capable of using F#. Sure, if it's a little project and it's required that "random" C# programmers be capable of working on the codebase, fine, OK. Otherwise, the benefits of the language outpace the minor learning curve.
Your co-workers won't learn it unless boss says so.
This tool definitely helps with C#.
One thing I like about Apple developer docs (on developer.apple.com) that MSDN doesn't have (at least didn't last time I looked) is the ability to get a PDF covering specific topics. These are useful when I would rather have not deal with a browser while developing.
http://msdn.microsoft.com/en-us/library/export/help/?returnU...
If I do the following google search "developer.apple.com keychain", it gives me a web browsable version with a pdf link in the upper right. If I click the PDF link, I get the content for "every page" which means, in this case, the "keychain services programming guide".
I have yet to be able to do the same under msdn.
You can even throw whatever you download on a network, and anyone can access it from there rather than individually needing to download it. That requires setting something in the registry though to access from the network (let me know if you want to know though).
Visual Studio still has an option to install all MSDN content on your hard drive, for offline access. It's the traditional Help Viewer model.
This only covers language and SDK documentation -- not the magazine articles and other random stuff.
The one thing that bugs me when these types of threads start is the hatefulness of others to bash MS for trying to make a profit and lock in when everyone else here is trying to earn a profit on their must have technology.
Why single MS out on this? Isn’t this what your trying to do?
For example, I am used to having a class information(methods, variables, etc) or similarly Javascript function information in Structure window updated whenever my cursor moves in the code window.
In Visual Studio this apparently is not possible automatically, and you have to make a custom hotkey to force this behaviour.
http://stackoverflow.com/questions/546113/visual-studio-auto...
How do people work through someone's else's code in VS? Do they really read every single line or use Object Browser?
I understand that Jetbrains Resharper fixes many of these issues, but that is not vanilla VS then.