back to article Visual Studio 2013: 50 Shades of Grey not a worry for MONSTER dev TOOL

How good is the latest iteration of Microsoft’s monster development tool, Visual Studio 2013? Visual Studio is the product that has to follow all the twists and turns of Microsoft’s developer story. Unlike Visual Studio 2012, which introduced a controversial makeover that removed most of the colour from the IDE, this is a …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    Edit & Continue

    "A debugging feature called Edit and Continue now works in 64-bit as well as 32-bit .NET applications."

    Seriously, you just throw that out there and move on? Its probably the most important change made to Visual Studio in the last 3 versions! Currently, zillions of developer hours and massive amounts of developer sanity are lost to compiling the damn code every time you make the smallest change. When a recompile takes 20 minutes, you can lose hours of work, every single day, from stopping the app, making a small change, then restarting it. The work around (write a 32 bit app, then just before deployment, convert it to a 64 bit app) is basically impossible with a large scale app, which is why this feature has been requested so strongly for the last decade. Finally, we can actually write proper 64 bit apps without tearing our hair out in frustration!

    1. Anonymous Coward
      Anonymous Coward

      Re: Edit & Continue

      MS sell poorly test shit and won't push bug fixes. Did you expect anything else?

    2. JDX Gold badge

      Re: Edit & Continue

      I can rarely get Edit and Continue to work in 32bit, which is a shame because in C++ it would be such an awesome feature if it worked reliably.

      On the other hand with native code I can see why it is hard to achieve...

    3. Rusty 1

      Re: Edit & Continue

      "When a recompile takes 20 minutes" - that, right there, is your problem.

      If a trivial, localised, code change is taking even a small fraction of that time to be compiled, deployed, and running in your target environment, you need to fix what is causing the time to be lost. Whether it is the architecture (code, deployment, or execution), the tool chain, the build system, or whatever else, do yourself a favour and fix it.

      1. Ken Hagan Gold badge

        @Rusty (Re: Edit & Continue)

        I cannot upvote this enough. Twenty minutes is enough time to rebuild several hundred thousand lines of code. (And that's *your* code, not someone's header file.) If your project structure means that you are doing that on a regular basis then you need to restructure the project's source code.

        Edit & Continue is such a marginally useful feature that I'm surprised they ever developed it.

        1. This post has been deleted by its author

    4. Anonymous Coward
      Anonymous Coward

      Re: Edit & Continue

      Yea. I just recently went into C++ and C# and endure this each day/hour. Coming from a Java background, I find it quite humorous that the C# advocates always maintain how great C# is. While the language *does* have certain good features, the tooling is sooooo far behind. The instant incremental class compile (only compile what you've changed) makes me much more productive.

    5. Anonymous Coward
      Anonymous Coward

      'Its probably the most important change made to Visual Studio in the last 3 versions'

      Dead on! How MS got away without including E&C 64-bit is baffling. For RAD development especially, its crucial!

      I've never understood how they managed to convince developers to migrate to .Net without including E&C from day one. Even when it was introduced post 2005, it didn't work as expected, as it lacked the power and flexibility of E&C in Visual Studio .... But hey, I'm just a RAD guy, and maybe for full-life-cycle projects its not as essential....

    6. Anonymous Coward
      Anonymous Coward

      Re: Edit & Continue

      "When a recompile takes 20 minutes,"

      I'm sorry? You have heard of modular code haven't you, or is your entire system in one massive source file?

  2. James Chaldecott

    Windows Phone not Silverlight anymore


    "The tools for Windows Phone are similar, though in this case you are coding to Silverlight rather than the .NET Runtime, unless you choose C++ native development."

    WP8 isn't based on Silverlight, it uses a platform sometimes called "WinPRT" or "Windows Phone RunTime". I believe that under the hood it's essentially the same beast as WinRT (as used for Windows 8 "Windows Store" apps), but with a different API set exposed. There are compatibility shims built in to allow WP7 (i.e. Silverlight) apps to run on WinPRT without source code modification.

    IIRC VS2013 doesn't support writing WP7.x apps.

  3. Anonymous Coward
    Anonymous Coward

    Visual Studio

    "Eclipse for the .Net generation"

    Both are giant sacks of bloated shit.

    1. NotInventedHere

      Re: Visual Studio

      And your suggested alternative would be...?

      1. Yet Another Anonymous coward Silver badge

        Re: Visual Studio

        vi and make - are the weapon of a Jedi, an elegant weapon of a more civilized age

        1. Anonymous Coward
          Anonymous Coward

          Re: Visual Studio

          "vi and make - are the weapon of a Jedi, an elegant weapon of a more civilized age"

          Agreed, though I'd include gdb and strace too. If a coder needs an IDE as bloated as VS or Eclipse before they can do their job then either they're a shit coder or the APIs they're working with are poorly designed rubbish.

          I wonder, does VS still require the coder to select what type of app he is developing - cmd line, service, GUI etc - before he can write a line of code or has Microsoft made it into the 80s yet? I don't know if its a limitation of the compiler or the shit OS its running on but it made me crack up when I first saw it.

          1. thenim

            Re: Visual Studio

            Double bollocks, anyone who thinks an ide defines the programmer is a misguided, egoistic buffaoon. Write code in what you are most comfortable and productive in, not someone else's misconceptions...

  4. ColonelClaw

    That's not fair

    How come Microsoft's own programming app gets a really nice looking and productive interface, whilst as an end user I have to put up with this godawful Ribbon shite?

  5. dogged


    what's hard about setting up TFS?

    Admittedly, getting it to integrate properly with Sharepoint 2013 was a pain in the arse (but mainly because the previous admin had bungled the 2010 integration...)

  6. Peter G Green

    Visual Basic 7. Get rid of all the .NET rubbish and give us something useful for a change.

    [And yes I still have to develop in VB6. Why? Because it's just too good to be abandoned.]

    1. Anonymous Coward
      Anonymous Coward

      Do you by any chance travel to work by horse-drawn barge?

      1. Anonymous Coward
        Anonymous Coward

        'Do you by any chance travel to work by horse-drawn barge?'

        Hard to believe, but RAD features such as E&C worked a lot better, and had more flexibility in VS6. I haven't used it since 2003, but I'm tempted to point out that smug comments like yours show a certain level of inexperience... You may feel high-handed putting down that VS6 programmer, but seasoned developers are way too classy to make offhand comments like that...

        1. Anonymous Coward
          Anonymous Coward

          Re: 'Do you by any chance travel to work by horse-drawn barge?'

          I'm tempted to point out that smug comments like yours show a certain level of inexperience

          Touched a nerve? 25 years+

          It's more the ".Net rubbish" comment that's deserving of ridicule imo.

      2. david 12 Silver badge

        Do you by any chance travel to work by horse-drawn barge?

        Edit & Continue? C# continues to try to catch up with interpreted BASIC.

    2. stephajn

      "Too good to be abandoned"

      "And yes I still have to develop in VB6. Why? Because it's just too good to be abandoned."

      Reminds me of the same attitude someone I worked for for about six months had with regards to FoxPro for DOS. To this day his product that he pushes on people is STILL FoxPro DOS based. Sucks for anyone buying a brand new computer nowadays since they are all 64 bit. But this guy is so set in the past about how easy FoxPro is to get a fully searchable grid of data with one line of code that he fails to see what people are demanding now. And he wonders why he had to close down his office and work out of his home....

      1. Alan Bourke

        Re: "Too good to be abandoned"

        Yes he should immediately embrace the cool shiny thing that all the kids on the internet are talking about this week, regardless of whether it's the best tool for the job or whether the existing application does everything users need.

        The lunatic.

  7. Anonymous Coward
    Anonymous Coward

    'The one thing that spoils this easy deployment '

    VS 2013 sounds like its about to trip itself up on daft things such as the 'multiple sign-ins' issue...... I don't have the luxury of full life cycle development. I have to deliver when I say I will, and I don't know if MS tools deliver on that promise anymore.... MS used to be a champion of RAD, what happened to that idea, and the old-school KISS rule?

    I'm a firm believer that software should evolve to be simpler and not ever more complicated. Pushing the cloud while not making the process seamless is breaking sound KISS rules. This will undoubtedly leave more holes in web apps. This isn't sound progress... Add to that the MS penchant for lock-in, and it sure makes me want to make a run for the door...

    Basically VS2013 is too cloud centric. All it will take is one massive world wide screw up or privacy breach in the next few years to force a retrenchment.. When will this be? Who can say. But its coming as the cloud primarily makes sense for short-term or short-sighted cost saving, whereas the long term risks are unknown and still being considered. Sure, the cloud is the future, or our possible future, but until we have vastly redundant telecoms infrastructure, and we solve the privacy and security issues, its just an over-hyped minefield.... But hey, try telling business leaders not to put anything into the Cloud today that they don't understand...

  8. Anonymous Coward
    Anonymous Coward

    Visual Studio w/ Linux...

    I'm a long standing MS straight shooter, and I'll be honest and say I made good money! But I'm thinking its time to defect. So I'd love to know how advanced developer tools are shaping up on the Linux side?

    Why defect? Basically I don't believe in MS anymore .... I don't believe in their vision, I don't believe in their direction, and I don't think they do either, that's why they keep changing course... If there are more long term MS developers like me losing faith, MS may stagnate over time, like a cancer. Its clear to most that outside of its Server platforms, MS is in turmoil. All they need now is for one major PC maker or internet vendor to really push a viable alternative with a windows VM included for legacy apps....

    Personally I hope Value and Google get traction, and then Asus, Acer etc join in with all Linux / FOSS boxes and devices. I honestly think it will be better for the developer and user community...

  9. btrower

    I Confess

    Executive summary: The world does not work on VS20xx developed code and is not likely to -- ever. We need better tools.

    I confess that I too go to VB6 when I need to hammer out a quick GUI application. The last code I delivered into production for a client was C# developed in Visual Studio, but the clunky tools for building user interfaces and the tortured dependencies are too agonizing for someone used to effortless RAD tools like VB6 or Delphi.

    I write lots of little tools to assist me in doing various tasks. I go to scripting if its manipulating OS stuff like copying files, Vanilla ANSI-C when doing simple utilities that don't need a GUI and VB6 when building a GUI application. I use perl, PHP and vanilla HTML when building web back-ends. Web stuff expected to be maintained for clients use packaged stuff like MediaWiki backed by MySQL or SQLite. To the extent possible, I use open source code for everything as a matter of self-defense. Except for venerable tools like VB6 the only things that have survived over the years have been things for which the source was available. When VB6 is finally dead and buried its demise will be entirely attributable to the fact it is not open source.

    I am ever hopeful that some genuinely usable open source cross-platform RAD tool will appear, but so far everything has been disappointing. As time goes on, we appear to be moving further away from what I consider to be powerful and expressive tools that produce small, self-contained or minimally dependent software.

    I am not now and never was a fan of .NET which to me seems to be an almost sinister extension of DLL hell deeper into the development process.

    I was marginally OK with write once debug everywhere Java until it became a vendor dominated dead end. But even before then I had dropped it due to security issues. Beyond that, I don't like Java much. It may be 'C++ without all the guns, knives and clubs', but it seems like they added sticks and stones as replacements and that is not really an improvement. Worse, rather than picking up a stick to do battle with knife-wielding languages, it requires that you instantiate and run a factory-factory to build a factory to create the stick before you have a stick to pick up. It hardly matters how elegant and capable that stick is after you have been stabbed to death waiting for it.

    I have done work in just about every language. I constantly review new stuff. That includes programming paradigms. C and BASIC have some serious limitations, especially with respect to OOP, but their limitations are outweighed by the fact that they work when written and long after delivery into production. They are also both very nimble. You can develop and deploy things in less time than Java programmers spend discussing their object hierarchy and which GOF techniques they will use or how pure their pair programming regime is.

    Most of the software I actually use started as someone scratching an itch and they had something working, if imperfectly, very quickly. Good designs should call for something that can be built and tested almost immediately.

    Like others who work in these aging languages, I am something of a dinosaur, but you know what? Us dinosaurs wrote the world's working code upon which we all depend. Literally tens of millions of people use things running portions of my code every single day and have done so for years. Likely most of the code that actually gets run to do useful stuff in your life goes back decades. I am pretty sure a lot of banks still use COBOL coded systems whose inception date goes back nearly half a century.

    C is the most portable language I use and the most ubiquitous of my code has been written in C. This is not a coincidence.

    As a developer, I only care about producing working software. It ought to be obvious but that means software that is actually operating in production, not some variant of hello world in a textbook or shaky example code the author warns is unsuitable for real use. Getting there and staying in environments like Communications and embedded systems requires code that simply works, compiles cleanly today and can be expected to compile cleanly in the years to come.

    I would never specify current versions of Visual Studio and .NET for an important production system that had to remain in operation for any significant length of time.

    It was entirely possible more than 20 years ago to build capable and reasonably light-weight development tools that supported 'rad' RAD. I have no doubt that it is *possible* to deliver something just as good or better today. There are a lot of seasoned professional programmers out there and eventually we will join forces to make it happen. When it does, it is a safe bet that merging ANSI-C will be easy if not effortless. I am not sure how safe a bet it is that merging C# or Java will be, but my hunch is that it will be difficult if not impossible.

    The long suffering software developers of the world deserve better than VS 20xx.

    1. Anonymous Coward
      Anonymous Coward

      Re: I Confess

      "Executive summary: The world does not work on VS20xx developed code and is not likely to -- ever. We need better tools."

      If I could upvote this more I would. Those of us old enough to have written code in the days when memory was measured in Kilobytes are often ignored by the cool new kidz.

      Android 4.4 requires nearly 2Gb of storage just for itself and "should" run in 512 Mb of RAM. We stand in awe at how "modern phones have more processing power than a 1990s mainframe". But ignore that all that power is sucked up just running an email client.

      I can recall the days of VB6, being able to sit with a business user and bash out a quick-and-dirty application for them more or less in real time then walk away with confidence it would keep working.

      No, we didn't have deep Computer Science constructs such as generics, delegates or lambda functions. But for 95% of Line-of-Business applications being able to bang it out in a week won over spending three months designing a beautifully pure architecturally perfect platform. Yes, there were times I was knee deep in VB6 code and wished I'd written it in Java, or C++ for that matter. But there were plenty of other times when the speed of connecting everything up and plugging in a tiny bit of business logic *while the user who needed it was there* made me much happier.

      Good programmers write good code no matter what language they are using - bad programmers can make a mess in C#, F#, Erlang ...

      Today we not only have gigantic frameworks, but the prevalence of the internet means it's nigh on impossible to have confidence your code will work, keep working, and deploy nicely to a new server too. If it's not Patch Tuesday tripping something up, it's a minor undocumented glitch buried somewhere deep in the recesses of the millions of lines of code on top of which your three text boxes and a button app sits. Anyone who tells you every single deployment they have made with .net went without a hitch has either been amazingly lucky; is a genius who has someone psychically absorbed all the workarounds required for various non-working pieces of the framework; or has only written tiny simple "example code" systems.

      The people who comment that no-one should take 20 minutes to compile an application seem unaware that the world has been in recession since 2007.

      A former employer has staff still using 2006-era machines. Hard to justify buying new shiny-shiny when staff are being ushered out the door to the dole queue.

      But customers still want their new systems, so the poor programmer has to run at least VS2010 on a wheezing 2-4Gb Core2Something. Should the coder need a fire-breather of a new machine with "more processing power than a Cray" just to create a tiny little tool that makes querying someone's database easier? Probably not.

      It is the pareto effect at work - as the old joke goes, 80% of problems can be solved with duct tape and WD40. But as programmers we have a horrible tendency to dismantle the entire house just to fix a light switch.

      1. silent_count

        Re: I Confess

        I agree with you both however I won't go on a rant because it'd be longer than the original article. Have a well deserved beer from another programmer who sick of the fads that grip our little part of the world.

      2. btrower

        Re: I Confess


        Thanks for the vote of confidence. Excellent post by you as well.

        Neil Young said the following:

        "I like to play with people who can play simple and are not threatened by other musicians thinking they can't play. So that eliminates 99 percent of all musicians."

        Substituting for thee and me:

        "I like to program with people who can program simply and are not threatened by other programmers thinking they can't program. So that eliminates 99 percent of all programmers."

        We all have some fine programming ideals in theory and some bad habits in practice. I find that people who have been at it longer tend toward simpler and less rigid ideals and better more practical habits in practice.

    2. JLV

      Re: I Confess


      Nothing worse in programmer land than a feature than gets you 80% of the way there and then leaves you hanging on the remainder. By then you've based your estimates on the promised productivity :(

      how I turned my back on Studio...

      This would be at least a decade back, forgive the fuzziness of the details. Version xyz of Studio was supposed to wrap database access to tables.

      i.e. "if you have a table X than insert.X is just a slight configuration away"

      At least one IT journal reviewer (might have been Dr. Dobbs) praised how great it was.

      I hadn't worked on Studio for years, so I figured I'd kick the tires. Took a simple database edit example and ended up with what looks like a semi-workable solution in C#. Not what I wanted, but close. To tweak, I figured I'd look at the generated code.

      A mess. A horrible mess. Auto-incremented variable names that bore no relationship to the table names, confusing spaghetti, no hooks to adjust anything in user code, horrible formatting. No way I could adjust it as my requirements changed, it was a one-shot deal. Hey, I've rolled my own code generation tools, often. A blindfolded monkey on a bender would have done a better job than Studio.

      I bailed right then and never looked back to MS's tools. Well, actually, that's untrue, I worked with SSIS 2005 for 3 months and its generated XML-based code made the above abomination look like pure limpid poetry.

      Years later, I asked someone who did work on Studio what I had done wrong wrt to the table wrapper generation. His answer "Dude, no one uses that feature".

      If you got to automate, make sure it actually works under the hood. Otherwise, simplify manual coding. Much as VB6 or Cobol would not be my first choice, I appreciate that you can use a simple text editor to get your work done. If C# allows that, cool.

      1. btrower

        Re: I Confess


        I could live with the tortured code if it was stable. Unfortunately, Microsoft breaks compatibility and orphans stuff faster than you can develop and deploy a large system into production.

  10. This post has been deleted by its author

    1. Zmodem

      Re: NOT BUYING IT.

      .NET came along

      visual c/c++ wont have a executable filesize of 2mb for nothing more then a message box popup or take 10 mins to load

      .NET is the crapest code that exists

    2. Anonymous Coward
      Anonymous Coward

      Re: NOT BUYING IT.

      If progress means going from booting in two seconds with the IDE -however crude- instantly available to having to load -wait for it- about 262.144 times more code just to write hello world, I'd say we've gone back. All caps or not.

      There was some undeniable simplicity and instant gratification for these machines. All lost now in the PC world.

      1. Zmodem

        Re: NOT BUYING IT.

        they are all just frameworks with sdk object class written in pure c++

        using visual c, its fast on windows and linux, you can import .dll and other c++ downloadable classes etc

  11. Anonymous Coward
    Anonymous Coward


    "Worse, rather than picking up a stick to do battle with knife-wielding languages, it requires that you instantiate and run a factory-factory to build a factory to create the stick before you have a stick to pick up. It hardly matters how elegant and capable that stick is after you have been stabbed to death waiting for it."

    That pretty much sums up what I feel about .Net now.

    I'm grateful to Microsoft purely in that their dominance in business computing has given a consistent field for me to develop a career in. Standardisation even if de-facto and not ideal has proven quite helpful in that regard.

    I am now, however, switching to Python and PHP for my own purposes and attempting to switch to open source web development as a career after using .Net since framework 1 days. The reason is simple.

    In PHP I can turn on support in Apache/IIS/whatever in moments with virtually no installation requirements, drop a few plain text files in and get a working environment (simplistic terms but fairly representative). I can code in a simple editor like GEdit or Komodo Edit or move onto some reasonable IDEs with minimal effort.

    With .Net I need to marry up versions of Windows and Visual Studio, possibly upgrading solution files, install masses of dependencies for all the fancy add-ons and extras that seem all the rage in the .Net world, learn the 7 levels of abstraction in the codebase, learn the latest database ORM (XSD> No, Linq. Linq? No, EF. Whatever). And even then the chances of deployments going smoothly are remote. That's assuming of course that you've got the latest 5GB of IDE going reliably.

    As for the future? Well my PHP/Python will be readable, editable and usable for probably decades to come. My C#? I'm not so sure.

    To put it bluntly, open source tools remain usable as the Microsoft stack becomes ever more bloated and convoluted.

    1. Anonymous Coward
      Anonymous Coward

      Re: Complexity-creep

      Not to mention the irony of the platform fragmentation: there are so many different APIs under the "Windows" name that if it you want to write a program today under Windows you have first to read and understand 4 different product roadmaps, all subject to change at the whim of the next MS CEO, of course.

      Apple developers have a much easier life: just two platforms to support, and expect Apple to break backwards compatibility without a sweat. No server apps.

      Linux developers... well, that's another discussion.

  12. Anonymous Coward
    Anonymous Coward

    Don't trap yourself

    VS is like a hard drug: easiest way to instant gratification, dependency for life. If "life" were only the few years you think someone will tolerate using what you think is a limited hack created quickly to solve an immediate need, that would be fine.

    But software has a nasty tendency to survive way beyond its intended lifetime. See a number of comments in this thread or watch out for Windows XP desktops still being used around. Or the number of "we don't know who created this or when really, we've been using it for ages" Excel macros that have become business critical pieces of software that in some places are key components of business processes.

    Anything you create today, someone will want to recompile, or change it in five years. By that time, half of the technologies MS supports in this multi-headed monster will be phased out, not to mention the tools used to create them, and the operating systems where these tools run.

    Don't be trapped.

This topic is closed for new posts.

Other stories you might like