Live data from Hacker News

Visual Studio 2013

blogs.msdn.com

71–80 of 201 posts

Re: Visual Studio 2013

#71
post #44

Earlier quoted context omitted.

> Often the problem with these queries is that there are not enough devs complaining to MSFT. No PM/engg manager is going to ignore a bug/problem if it shows up high in customer requests. Note that you switch between "devs" and "customer" there. I argue that the real problem is that for VS those demographics are different. Devs in "Microsoft shops" don't go out and decide on a complier, they use VS because that's all…

>But you're right, that clearly the "devs" have preferences. The problem with your mechanism is that they don't express them to you in customer service requests. They just job-hop to another environment, doing Javascript work, or Linux, or Ruby. And you never hear from them. >Basically, the way feedback works in this world is with feet, not bug reports. If you build it they will come. If you don't they will leave. Is…

Well, just to address the first point there is undeniably an "exodus" from Visual Studio. Just look at all the code shipped to run in browsers, or iOS, or Android, or on node or rails. A decade and a half ago a far (far!) greater fraction of that was spend in a Microsoft IDE.

But that's really not the point. The upstream discussion was much narrower, and focused specifically on C/C++ support, which frankly sucks in the windows world compared to the renaissance we're seeing in Unix with our dueling multi-architecture full-support C++11 implementations.

I'm not nearly expert enough to comment on how good or innovative the .NET support in VS is, but I'm perfectly willing to believe it's great.

Re: Visual Studio 2013

#72
post #64
post #58

Earlier quoted context omitted.

> ... they use VS because that's all there is On Windows there are lots of compilers to choose from.

There are other words around those words. ajross is describing a corporate environment where the choice is sometimes made for you.

I understood Microsoft shops as Windows ISVs, if he meant companies 100% committed to Microsoft tooling then you are right and I made an hasty comment.

Re: Visual Studio 2013

#73
post #59
post #17

Yet another Visual Studio, yet another truckload of "features" that do nothing to help day-to-day, heavy-lifting programmers. (And which probably help by adding bugs or just bloating the system). Sigh. I am hoping they have made substantial improvements that are not mentioned in this blog post.

Try R# with VS.

Try R# with VS in a solution with 54 projects and ~ 1.5MLOC...

It stinks!

Re: Visual Studio 2013

#74
post #41

Earlier quoted context omitted.

C is officially deprecated. Personally I would like to see proper C++11 support instead of playing around with C++/CX and while they are at it, either provide a native compiler for .NET or improve NGEN's optimizer for C++ performance level. Given that Microsoft had .NET native compilers for Singularity and Windows Phone 8 .NET apps are compiled to native code, it isn't as if they don't have the tooling already availa…

What do you mean by C being officially deprecated? As a whole this can't be possible as codes like the Linux kernel are written in C.

I think he meant in the context of Visual Studio 2013. Imagine doing a build of the Linux kernel with Visual Studio 2013?!?

Re: Visual Studio 2013

#75
post #46

Earlier quoted context omitted.

> intellisense randomly breaking and putting a red line underneath half your statements There's a reasonably simple solution with which you can solve the red line problem, if you're talking about the C and C++ projects: http://connect.microsoft.com/VisualStudio/feedback/details/5... "Posted by JoeWoodbury on 25/02/2010 at 10:16 (...) The solution is to add the location of the stdafx.h file to the include path list. T…

It happens regardless of precompiled headers, so I don't think that's the issue. I do think it's an include problem, but I don't know why.

It's precompiled headers and it can be proved: If you would try to turn off precompiled headers in your project and rebuild it, the compilation would fail in all the files in which you see the red lines. It's because your project has subfolders and the files in the subfolders reach stdafx only by accident of having the "use precompiled headers" turned on. So once you fix the include path, and that you can do on the project level, your project will compile independently of "use precompiled headers" settings and the intellisense would work too. I know from experience, I fixed the big projects on which I worked.

EDIT v2: Looking at the project you cited in the reply of this message and the file: http://code.google.com/p/freetype-gl/source/browse/trunk/dem... on the computer on which I don't have VS, I still have an idea what the reason for such errors are: the project authors use something like:

     #elif defined(_WIN32) || defined(_WIN64)
Now think about it: when intellisense parses the file, can it assume you're building a 32-bit version? No. Can it assume you're building a 64-bit version? No. So intellisense doesn't use the header inside that elif at all. Setting defines in the project can fix that.

Re: Visual Studio 2013

#77
post #55
post #40

Earlier quoted context omitted.

You can install several versions of Visual Studio side by side - keep an old version for maintaining legacy projects, use a new version for new projects.

Except you cannot have .NET 4.0 and 4.5 on the same machine, given the way 4.5 overwrites 4.0.

Version 4.5 was designed to be backward compatible to version 4.0 and is indeed an in-place update. Therefore after installing version 4.5 you will no longer have version 4.0 assemblies but you can still target version 4.0 using the backward compatible version 4.5 assemblies.

Nevertheless I have read some worries that some bug fixes (may) break backward compatibility and therefore projects targeting version 4.0 developed on machines with version 4.5 installed may behave differently when run on machines with only version 4.0 installed. If this is a real problem, that is if there are observable changes and therefore version 4.5 is not fully backward compatible to version 4.0, I can not tell.

UPDATE: There is a published list of breaking changes [1].

[1] http://msdn.microsoft.com/en-us/library/hh367887.aspx

Re: Visual Studio 2013

#78
post #65
post #55

Earlier quoted context omitted.

Except you cannot have .NET 4.0 and 4.5 on the same machine, given the way 4.5 overwrites 4.0.

[deleted]

Reality speaks otherwise,

http://www.west-wind.com/weblog/posts/2012/Mar/13/NET-45-is-...

http://stackoverflow.com/questions/11458159/how-to-keep-net-...

Re: Visual Studio 2013

#79
post #41

Earlier quoted context omitted.

C is officially deprecated. Personally I would like to see proper C++11 support instead of playing around with C++/CX and while they are at it, either provide a native compiler for .NET or improve NGEN's optimizer for C++ performance level. Given that Microsoft had .NET native compilers for Singularity and Windows Phone 8 .NET apps are compiled to native code, it isn't as if they don't have the tooling already availa…

honest question, is the Windows kernel written in C++? If not, what does that team use to build it if "C is deprecated"?

At Build 2012 it was mentioned that the C code that still exists was being made C++ compatible.

Similar to what GCC did before changing to C++ as implementation language.

Re: Visual Studio 2013

#80

Earlier quoted context omitted.

The full version vs. service pack distinction doesn't really matter to me.

It makes a lot of difference to some PHB's, though. I'm pretty sure I can upgrade to a service pack. Changing versions, OTOH, probably requires approval from management.

It sounds like you have bigger problems than can be addressed by the hard-working people in Redmond.
Post reply on HN