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.
Personally, it's because Microsoft development locks you in, and costs a lot of money. The OS costs money, the server OS costs money, the database costs money, the IDE costs money, everything costs money, and you have to use it, for the life of your app.
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.
It is a lock in (most technology does lock you into certain dependencies) and it does cost money. But, it's all so easy to use now / saves you lots of time. You can roll out anything using PowerShell these days. Or just copy VMs with OS/IIS/SQL already set-up.
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.
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.
As a knowledgeable Microsoft basher, you're right. MVC is better but still a long step away from something great. Some of the internals are crazy bad from attribute thread safety to the numerous singleton piles of crud like the ViewEngines collection and route data. Not only that, the tooling really doesn't scale up well either.
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.
"Singletons are not for managing lifetime as well" - No, but you can replace it with something that does. I.E Single Object with application lifetime vs singleton.
You're right. 100% right -- I agree with you. Let me break it down into to separate points which are better described.
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.
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.
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?
COM is different. The interfaces are well defined between components and processes.
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.
VS lock in is a very real thing. At my current employer, there is no way they could ever come off of VS and .Net because of the lack of polyglots in the office. There is one of us that does Java, 3 that do PHP (only in the last 6 months), and 6 that are set up for .Net MVC. Management just can't spare the costs to retrain, and none of these guys go home and code on non MS platforms.
I could switch languages more easily than I could switch dev environment. The lock in to me is bssically simply that there aren't many other good language+IDE combos out there. There are plenty of languages that are interesting but very few come with a great IDE. I'd love to do Rust or Haskell all day, but I'm sure as hell not going to vim/emacs/sublime from VS. I almost envy those who never started using and IDE and can be productive with a text editor, their threshold to switch language is much Lower. Luckily VS at least supports C++, F#, JS and python so it's not impossible to cover quite a lot of languages in it.
I tried out Resharper for the entire evaluation period and then dropped it. There were a few nice things, but nothing that was just leaps and bounds better than built in VS features. But everyone says it's necessary, so I keep wondering if I somehow missed the killer features.
What are the features of Resharper that make you say VS isn't complete without it?
One of the big ones to me is "move class to its own file". Means when you are sketching up some multi-class API or something you can just type away in a single source file, and as soon as something looks half-finihshed I just alt enter and it creates a new file with the correct name and moves the type to that file including adding the necessary imports to the header. A lot of context-switch time gained.
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.
I didn't find the "move class" feature while I was trialing, but it does sound pretty handy.
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.
In my experience it isn't one, two, or even three killer features. It's the aggregate additional polish and productivity increase gleaned from 10 to 20 minor features that shave fractions of seconds and remove a click or two off of incredibly common actions. And I just use the default settings.
I've tried it a few times now, and never stuck with 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.
I agree the slowness of find (Ctrl+F) and the slowness of the xml/html parsers is still the worse thing about it. I can see how tag soup is hard to parse, but well formed xml should parse in milliseconds. On the bright side, with a good go-to-symbol, go-to-file, go-to-type etc., I search much less for free text.
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.
The text editor is by and far the most important part of the IDE and is the only part everyone will use.
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.
> Integrated debugging (with edit+continue while debugging)
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.
I'm curious. What do you find so great about Visual Studio? After working with it for a while, I came to the conclusion that while it's extremely fast, it's not particularly full-featured compared to Eclipse. The amount of refactoring you can do out of the box is minimal, and the search is ridiculously crippled.
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.
I have Mono projects in production. Xamarin Studio is pretty nice these days. I don't have a lot of performance sensitive .Net code so I don't notice any real difference between Microsoft's and Xamarin's implementations.
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.
Same here, a number of Mono apps in production, both on mobile and desktop. A lot of my recent work has to do with OpenGL-related stuff running on Linux using Mono/MonoDevelop. I have had neither performance-related issues nor stability issues.
Ironically, we have some large-ish C# code-bases that run on everything but Windows.
Personally, I find Xamarin Studio to be quite buggy, often needing several quit+restart a day (I do iPhone apps), a colleague also does Android apps with Xamarin (on Windows) and experiences similar problems.
> 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.
We stopped using Mono after a few months. With .NET's Task Parallel Libraries we saw an enormous performance difference between Mono/Redhat vs. .NET/Windows, with the latter often running many times faster. Tuning the GC and heap size didn't make much of a difference.
.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.
Mono's parallel implementation is really bad, yes. I've had similar problems with it (despite the fact that the Mono SGen GC is usually pretty decent at keeping up)
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.
What you're saying is only true for perhaps the simplest "Hello World!"-level apps. Much beyond that and it just isn't trivial to use those alternative tools effectively, even when you're specifically targeting them and not actual .NET.
I've deployed fairly large .NET applications to Mono with only trivial modifications. They behaved equivalently, even if Mono's garbage collector isn't as good.
We have a C# asp.net MVC web app that we are transforming into a consumer of independent node.js and python web services. I must admit that I sometimes miss the static type refactoring tools visual studio offers when I'm wrestling with grep in node.js code, but my team really appreciates the open source tools and deployment options that come with the OSS territory.
Moreover, their business unit's licensing/pricing team are chasing your code forever to suck more margins from its use.
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.
Having worked on many enterprise .NET projects I can assure you this is not true, at least in the general case. Licensing is definitely a complex beast but I have never heard of, or followed, this requirement
Yea, this is complete bollocks. Not a word of it is true. You may have a shitty thing in your corp that forced you to do this, but that has nothing to do with Microsoft.
thanks for getting the satire :-) few years back i used to work for mankind's largest IT project leading a C# team to develop certain missing parts. Licensing implications for each piece of idea were so immense, we needed to keep architectural decision inline with licensing plans.
It pains me if I am honest. Our CMS is built on .NET and it's like an uphill battle selling it as it's on IIS and it's .NET. I have played around with the idea of reworking it into an open source language and open source database but I would miss Visual Studio and the language a lot.
I think it's less about not wanting to use Visual Studio and more about not wanting to have a Windows VM thrashing resources. I've worked with teams that have migrated to ServiceStack just to avoid running Windows.
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.
Not running into those issues must be really great for you, but does very little to make the experience better for me. I tend to run VS under virtualization with TFS, which is far from a pleasant experience, even on modern hardware.
So on a local machine, in virtualization, you are running an IDE, SharePoint Server, SQL Server, IIS, TFS. If you aren't running it from a separate SSD drive then the problem has nothing to do with the IDE. You have an IO bottleneck.
I'm not sure where you pulled SharePoint and SQL Server from, and running the TFS client is a far cry from running the TFS server.
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.
From your comment, you said TFS. TFS is the server, which include SqlServer, Sharepoint, an OLAP cube, and the TFS server components. The TFS client extension, (which is not TFS) has been baked in for the last 2 versions. So I assume you're using VS 2010, and that is a much different beast. It has a lot more issues, but it's a much improved IDE.
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.
I was referring to Team Explorer which, as of VS2013, doesn't appear to be included out-of-box. Apologies for the confusion.
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.
Team Explorer has been baked in for the last two versions. Regardless, most of your points have little to do with Visual Studio, and a lot to do with Windows and Virtualization. Besides, half your gripes can be turned off in the settings.
If you have to work with the tools daily, then take the time to learn them. You'll thank yourself.
I'm not sure if you're intentionally glossing over the "this happens with or without virtualization" point, but I'm glad you're happy with the tools you're using.
Far and away the biggest problem with the background/foreground issues is COM and its apartment models. A large part of some of the core pieces of Visual Studio are (still) written in native code and are STA bound objects (mostly when they don't really need to be, but that's another discussion).
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 work in a .NET C# environment and I get all of these issues. Sorted in order of most annoying to least annoying, they would be: #2, #1, #5, #3, #4. I don't really mind 3 and 4. I'm just saying this to affirm that your experience is not unique to you.
Sure, but why have features that block the UI for an indeterminate period of time with no way to interrupt? You paid a lot of money and you expect the experience to be good.
Interruptions to flow are indeed high on my list of annoying issues. Blocking the UI unexpectedly to poll an external service for an indeterminate amount of time is frustrating and worthy of resolution.
Okay, for starters, you hit the wrong button. Secondly, pretty much everything is customizable, so edit your toolbars or menus to move those to a slow running menu. The others about code formatting and auto refactoring are easily disabled. Learn your tools.
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.
Use a fast machine. Do not develop in a VM. Do not use a mechanical hard drive. Have at least 8GB of ram. Absolutely do not have any kind of on-access antivirus scan enabled for project output/intermediate dirs or GAC.
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).
This is great dogma for people that control their work environment, but keep in mind that not everyone has that luxury. Hardware upgrade cycles and/or upgrade budgets can prevent people from working on the hardware they'd like, group policy can prevent scoping down AV settings, job role may require frequently hopping between OSX/Windows, etc.
Well, it's fairly easy to keep developers happy. Good hardware and coffee is so cheap compared to finding new developers...
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.
I have done a lot of Java, Scala, etc. IntelliJ & Eclipse are both wonderful IDEs in their own right. A lot of things like ReSharper were in those IDEs before Jetbrains (maker of IntelliJ) made the plugin for VS.
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.
It sounds like you just don't know Windows/VS/IIS as well as you know the other stacks which is entirely understandable since I'm guessing you don't work with them very often.
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.
> For future reference you can compile VS projects from the command line if you want using MSBuild, that's all building in VS does.
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.
> 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.
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
That is certainly the case. But I guess my point is both ecosystems are so completely divergent that it makes sense that .NET would be an uphill battle for shops not running it elsewhere.
I remember looking into MSBuild, but I couldn't get it to work. I must have had some path set wrong or something.
Most every command that can be done with a gui can be done via command line, mostly powershell; which you can use remotely. In fact I would be hard pressed to find any administration routine that cannot be done through command line and is not documented.
The thing that I could use most is a way to automate setting up a reverse-proxy on a given path. I've figured out the steps to make it happen in the GUI. But that is tedious and error prone.
Where would you suggest I go to find the best way to handle this?
Not true. I want still want the IDE compile, type check, and add type-safe completions (When using statically typed languages). I want the IDE to assist me in writing the code. I want my IDE to launch/attach to processes for debugging. Generally, I want the IDE to produce binaries yes, but mostly for my own consumption.
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.
I always have the same problems when moving from linux over to a Microsoft shop. You really do have to approach VS differently than you would any other dev environment.
> 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).
Maybe ten years ago I would have said that, but these days it seems they are typing their "documents" into an email composer or a website form (be it a frontend for blogger, wiki, wordpress, etc).
You mustn't work in an office environment then. The only significant break from MS products I've seen has been Lotus Notes... which was significantly worse than Exchange.
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.
I work for an decent sized international company that not only has a presence on the web it also has factories and all of the complexities that go with that. I would indeed count where I work as an "office environment", I even have the cube, office badge and mailbox to prove it :)
It's not .NET, .NET is a fantastic framework. The problem here is you're not just selling IIS and .NET, you're trying to sell the entire Microsoft ecosystem. There are so many MS components that just don't work on the Open Source world.
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 don't think it's worth mentioning Mono. It's impressive what they've managed to accomplish, but it's nowhere near being a true replacement for .NET, especially for any serious system.
Not so much hate for me, but apathy. For your one CMS, there are dozens based in Rails, Django, Node based ones I've not even heard of, and same for Go. For any of those, I just need Sublime and a server of my choosing. Furthermore, I can do dev on my box (a Mac) with very little spin up time.
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.
The problem does ultimately lie with the tie in, I can appreciate that. I suppose my question was almost rhetorical as I know where the problems lie.
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.
I think people rarely take into consideration the cost of a project beyond the actual software. VS can save a lot of time – this extension is a good example.
Visual Studio's Python and Ruby plugins seem quite decent and free if you're on VS Pro and up. You don't necessarily need to let VS go if you're to migrate to a language supported on more than one platform.
I've been using it regularly for a few weeks now. Granted I'm a novice a Python, but so far I've found it to be outstanding. It offers almost all of the VS functionality that you would expect if you were developing in .NET, and it's quite stable.
.Net is the most popular platform for commercial content management systems($2k->$100k license), with SiteCore, EpiServer, Kentico, Sitefinity and Ektron leading the pack.
If you have problems selling due to the platform, I think the main issue is your target market, and not .Net in itself.
I agree that F# is a great language, but there are a couple projects in which I favor C#.
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.
I've found that with F#'s inlining, you can get significantly better code generated. The C# team has seemed hostile to the concept of implementing many compiler optimizations, and the JIT still does a poor job inlining. (And still no SIMD...)
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.
F# tooling has been improving like crazy over the last ~6 months; most of that work has been focused on refactoring tools, compiler-as-a-service (aka "Foslyn"), and compiler-development tools, so it's not totally out of the question that someone could implement an F# language service for ReSharper in the semi-near future.
What gets me is that CodeRush has had first class support for F# for years now, and JetBrains still hasn't given it any love in ReSharper. Perhaps it's already underway and JetBrains is just waiting to reveal.
The dev tools are good, though I think some of the documentation on msdn needs a lot of cleanup/improvement. It is not uncommon to get routed to older API versions or different languages. That said, it is getting better over time.
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.
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".
In visual studio go to Help -> "Add and remove help content" and that will allow you to download entire topics like .net 4.5 docs.
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).
> 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.
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.
Agreed, MS Visual Studio 2013 must have been written by space aliens for their advanced features and openness to third-party platforms and languages.
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?
Coming from Eclipse and Jetbrains world(Webstorm rocks), I have a pretty hard time adjusting to Visual Studio.
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.
This is a pretty cool research project. I do not use Visual Studio but being able to search for and use code-snippets inline can be quite the productivity booster. Lord knows how many times I use google.
Have you considered perhaps including more data sources ? I'd imagine for example a public code repository like Github or Codeplex will extend the range of possible "How Do I" questions that can be answered.
On an unrelated note, I have almost always been disappointed by the search-quality of Github. I know they have a lot of public code but they don't do a good job of surfacing relevant code results. Imagine for example, how cool it will be being able to type into Github, "How to compute MD5, C++" and seeing the relevant code.
Actually, thinking about it, there is nothing preventing Microsoft Research from taking this tech, and turning it into a natural language web code search service. Now that would be awesome !
There's alot more that can be done with the technology. We wanted to start with a few core partners and drive the quality and relevancy up as we go - so, can we? Sure. It's a matter continuously improving the service
We try and avoid those cases, but it's possible yes. The semantic and contextual approach help you find relevant samples and discussions that are highly relevant to your code, you still have to vet whether the sample makes sense. (Visiting the original sample page is likely to shed more light on those cases where we mis-label)
Static analysis is part of how we grade the samples (using Roslyn). Obviously this tool isn't a magic wand, the goal is to get you as close as possible to relevant results that you can dig deeper into
It's interesting that the example code shown is so clunky. It uses try-finally to manually dispose the resource when the idiomatic way would be to wrap it in a using block:
using (var file2 = new StreamReader(file))
{
while ((line = file2.ReadLine()) != null)
Console.WriteLine(line);
}
It's possible this is a badly picked example but it shows one big downside of this -- the lack of discussion about the sample code that you would normally get at e.g. Stack Overflow or a blog.
The url to the original sample is visible on the bottom right. That said, continuing the optimizations and smarts around the code metrics and semantic understanding will be an ongoing effort around the service.
But yeah, we still have stuff to improve
There are known issues with using "using". If the Dispose() call throws an exception in the finally block, then any exception that occurred in the within the using block is masked.
The easy solution is to make sure that your Dispose() calls don't throw exceptions, unfortunately some of Microsoft's classes don't conform to this (e.g. WCF clients).
Everytime something C# is posted it's all about MS and why some like or dislike C# or .Net, rarely are the comments related to the actual article.
Personally, I think this new feature is cool, but I've come to realise that my visual studio freezes way more then initially, I think this might be because I've got a few addons installed (ex: Demon, Resharper ...etc) I wonder what will be the overall performance impact of this.
Unbelievably true. I installed it on a VS2010 dev VM and it slowed my near-instant loading to a minute or more. It's a standard tool at work, but my word is it a hog.
> The Qeng Ho's computer and timekeeping systems feature the advent of "programmer archaeologists":[2] the Qeng Ho are packrats of computer programs and systems, retaining them over millennia, even as far back to the era of Unix programs (as implied by one passage mentioning that the fundamental time-keeping system is the Unix epoch:
> Take the Traders' method of timekeeping. The frame corrections were incredibly complex - and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth's moon. But if you looked at it still more closely ... the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind's first computer operating systems.
> This massive accumulation of data implies that almost any useful program one could want already exists in the Qeng Ho fleet library, hence the need for computer archaeologists to dig up needed programs, work around their peculiarities and bugs, and assemble them into useful constructs.
That book, and its partner, "A Fire Upon the Deep", are very much worth the read. Many other things in there, that we already see coming true: Computational and monitoring "dust"; biomagnetic manipulation of perception and personality; etc...
And Vinge is an excellent storyteller.
There's actually a third title in the series out, now, that I also quite enjoyed. But the first two, and especially "A Deepness in the Sky", really got my attention.
"I was at a hackathon up at Columbia University last weekend and one of the hacks was a development environment that automatically queried StackOverflow and GitHub as you are writing code so that you always have in front of you the answers to the questions you are most likely to ask. The developer who did the hack introduced it by saying something like "programming these days is more about searching than anything else". That reflects how collaborative the sharing of knowledge has become in the world of software development as a result of these cloud based tools for developers."
A core difference here is the contextual and semantic understanding of the code. The way we search and rank ties into alot of coding metrics and semantic parsing of the code around the web using the new 'Roslyn' C#/VB compiler-as-a-service technology.
Most other experiences base their search algorithms on search engines / textual matching / rely on the host web site's search accuracy, where as we combine search engine smarts with semantic and contextual analysis.
Hmm I wonder if I can make a sublime add on to do this for various languages. I could probably do php pretty easy. Anyone keen to do a node module for it? CSS?
As someone who has recently been hiring .NET engineers, I have to admit that this inspires mixed feelings. On the one hand, I can see huge power from combining AI and search with the structured context of programming. On the other hand, a disappointing number of the people we interviewed weren't software engineers, they were IntelliSync engineers. We'd give them a problem, and their first instinct was to hit a period and start hunting through the method options that IntelliSync gave them to see if one got them closer to their goal. Instead of stepping back and thinking about the problem generally, they'd try to solve it by stringing together IntelliSync suggestions, like stepping stones across a pond.
It's Intellisense. I might have a chip on my shoulder but if you were competent and really were hiring .net programmers you should know that? Especially if you're going to take the mickey.
You get those types no matter what role they hide in. Today I spent an hour with a candidate that looked really promising on paper dodge every question and switch from being "mainly backend" to "mainly frontend" when they couldn't tell me the difference between an interface and an abstract class....
Hah! Yes, I am (or pretend to be) competent, just not when writing HN comments ;). Thanks for the daily serving of humble pie.
I do wonder if there's something about .NET and a business environment that encourages this kind of behavior. When the organization's values are in their business rather than mentoring programmers, when they tell their programmers to "just get it done," you end up with IntelliSyn...Sense programmers? I've worked in various different programmer ecosystems, and I've never seen this pattern so strongly. There are of course excellent .NET programmers, I don't mean to say otherwise. And I got the feeling that several of the people we interviewed had basic talent, they'd just been trained, intentionally or not, towards this kind of behavior.
We started putting VS in front of candidates precisely to deal with the kind of fuzziness you mention. We started with whiteboarding code, but a lot of candidates would have a wrong design, then add a line of pseudo-code that they claimed magically made it work. By having them write actual code, it forced them to be explicit and to deal with unexpected outcomes.
> We'd give them a problem, and their first instinct was to hit a period and start hunting through the method options that IntelliSync gave them to see if one got them closer to their goal.
I use dynamic languages and have never touched an IDE, but I still do this.
If I find out I need some feature provided by libfoo to accomplish a task, then, before I even look up the libfoo docs, I try this, or an equivalent:
> We'd give them a problem, and their first instinct was to hit a period and start hunting through the method options that IntelliSync gave them to see if one got them closer to their goal.
IntelliSense is like GPS for programming. When driving, do you prefer to plan your trip using a map or use the GPS instead? I guess there are still people in the former camp, but most younger people are in the latter.
> Instead of stepping back and thinking about the problem generally, they'd try to solve it by stringing together IntelliSync suggestions, like stepping stones across a pond.
And are they less efficient for diving in right away and using their tools vs. waterfall planning up-front?
But that's just the issue: IntelliSense isn't a GPS. Tell a GPS what your goal is and it will give you an explicit list of instructions to achieve it. IntelliSense can only tell you what your available next steps are. It's really more like a map -- give it your location (i.e. a type), and it will tell you what roads lead on from there (the type's methods). It won't, because it can't, tell you how to string those choices together into a solution. A GPS does, but not IntelliSense.
Don't get me wrong, I love IntelliSense. It digests a huge amount of information for you without forcing you to switch context, like having to look up library documentation or how a particular module was written. But it's only part of the puzzle. What I was seeing in our candidates was that they'd come to rely too heavily on IntelliSense and forgotten how to design. You need both.
GPS works with a small vision scope; i.e. "turn left in 100 meters." IntelliSense (and all other forms of code completion) is quite similar in the field of vision (small), but you are right that it differs in that the goal is not known by the system. Its not like a map because you don't see everything, just a focused little bit.
> What I was seeing in our candidates was that they'd come to rely too heavily on IntelliSense and forgotten how to design. You need both.
I think kids these days have evolved different ways of working given the tools they grew up with. IntelliSense (and code completion) wasn't even a thing before 1997, and many of us developed our core programming habits before that. The question is: are we biased against the process we are observing because it is so unlike our own, and are they arriving at the correct answer as or more efficiently than we would with older ways of doing it?
Design is quite orthogonal to API selection; if they aren't designing, then they should be succeeding on the problem UNLESS you gave them one that required little or no design; like writing some basic boilerplate code. You didn't specify if the candidates were failing on outcomes or not.
They are committed to the language because it makes them profit, yes. What did you expect from a company? A bunch of academics who are committed the language on its theoretical merits alone, even if it causes the company to hemorrhage money?
The kind of "commitment" that you refer to is one that results in perhaps wider acceptance (perhaps not), but /definitely/ will annihilate their existing strategy (lock-in).
It's in no way in a worse place than, say, java. It would be nice if the CLR and Roslyn was open sourced, but I wouldn't make it a primary concern when choosing a platform for a project. The ecma standardization feels at least as important.
Right, but that's just because Oracle has been such a shitty owner of Java. However, at least Java is supported by more than 1 company on more than 1 platform; C# doesn't offer any real advantages over Java (other than some cosmetic language features).
Xamarin is one of the biggest backers of C#/.NET, and the reason .NET is probably the simplest way to create a 3-platform smartphone application today. You can even use F# for that which is even nicer than C# and open source. So the ecosystem has a few open source languages and several backing companies.
I know many of the differences. C# is a newer language, more novel VM, designed from start for multiple languages, C# has linq, unsafe code, unboxed structs, properties, events, delegates (Java now has lambdas), dynamic... But it's not fundamentally different, and offers exactly the same way of structuring applications.
A lot of programming can involve Searching, but it doesn't have to involve searching with plain-text. One would have thought Google would work on this, but they closed down their code search and haven't offered anything else.
I am actually looking at doing this, but integrating it with the searchcode.com API. At the moment its just a question of long it would take me to build a plugin for IntelliJ/Eclipse/Visual Studio. I did look into oursourcing the work but the price as a little high for me to swallow at the time.
One problem with this approach is it requires a change in user behavior. Unless Visual Studio can get a developer to an answer every single time, it may not be sticky enough to form a habit.
Google search reliably produces an answer each time, regardless of what the question or problem is
This is why search is very sticky (and habit forming). MSDN (and even Stackoverflow or Github) suffer from this problem because they only have a subset of content that developers want/need. Google brings all these sources together into a single search.
To those who insist this somehow encourages copy-paste style of programming, think again. What would this so-called programmer do if they didn't have this extension? They'd put this question in Google and copy the first example that works.
This extension doesn't “spoil” programmers any more than Google does. And if you hire this kind of programmers, this is very likely a problem of yours.
Visual Studio could be so much more for Microsoft. Why do they need a phone? Let them make Visual Studio cross platform and developers would come back to Windows as their base platform. All other IDE's pale in comparison. Too bad that advantage is being wasted as far as new developers go.
I'm a young professional developer who has been in the industry for just over a year. I am absolutely in love with C#, .NET, MVC, and the MS ecosystem in general. I'm even using Azure these days.
I honestly can't imagine going back to the dismal experience that was the ecosystem I used in undergrad - Linux/Unix + Java/Ruby/Python/C/C++. The only one of those I actually still enjoy working in is Python, and I can do that on .NET in VS as well. Ruby/Rails isn't really that bad TBH, but these days it just feels like a second rate dynamic version of MVC.
"Programming by example" is becoming an interesting trend these days. VS seems to be the first to implement widely such a feature. This of course, suggests that this small-scale reuse is very common. But could it be a "problem" of modern languages like Java and C#?
I'm one of the creators of Sourcegraph, which does have results for many JavaScript frameworks. You can find examples from all across GitHub, and you can search by function name or full-text documentation.
JS is hard to analyze, but we're working hard on getting better--and the analysis code is open source[1].
It probably will, but for TypeScript and similar variants where proper type context actually exists. Normal JS doesn't even support a reliable autocomplete, much less a compiler-as-a-service based one.
Wouldn't a with(file) statement (instead of a finally block) be much more idiomatic in the example they give? Not to be be pedantic but I think it illustrates a good criticism. How can you ensure quality code snippets that are "idiomatic?"
This is very cool, but I fear that many will label themselves as experienced programmers with nothing but the knowledge of using this tool to piece snippets together.
We're worried about that too. What we're hoping to do as we progress is to use best practices as metrics. Because we can do semantic matching, and not just textual matching, there's a world of possibilities to make results more helpful
We'll always need fantastic developers and engineers :) The goal is to help you find good samples, whether it makes sense and how its used is still very much open to how good (or not) a developer is
This is really cool, I find the microsoft documentation particularly terrible.
I always had a chuckle when the first result for a simple C# concept and the result isn't a MSDN site. I also chuckle when the result is a forum post from 2005 that drops me into a link loop.
Thankfully I won't have to write C# for a long while. I can't say I will miss the MVC stack or the legacy burden you get with forms.
