Slashdot Mirror
Microsoft Officially Releases Visual Studio 2015 and .NET 4.6
rjmarvin writes: Microsoft has announced RTM of Visual Studio 2015, the latest version of its flagship IDE, along with the release of .NET 4.6. The release includes a new set of DevOps services featuring the Build vNext cross-platform build service, the IntelliTest automated unit testing tool, and a Dev/Test service delivered both via the cloud in Visual Studio Online and on-premises through Team Foundation Server. Soma Somasegar, corporate vice president of the developer division at Microsoft, highlighted three main themes Microsoft focused on with VS 2015 in an interview with SD Times: developer productivity, "a holistic set of DevOps services" and giving developers choices when it comes to tooling toward the goal of building Universal Windows Apps for Windows 10. VS 2015 and .NET 4.6 are available here.
MSPHB jesus we just lost 7 billion on a phone. no one wants our tablet. everyone hates our cloud. we need to release something quick or im out of a job. Whatcha got dev?
dev: another windows is sure--
MSPHB: can it. Everyones up in arms about mandatory updates and the spying it does. whats next.
dev: XBox reports call of madden 19 band of halo brothers is ready to ship! truly--
MSPHB truly some stoner will appreciate it. i need something NEW. something with WOW.
dev: well...uh....
MSPHB what the hell is on your screen...is that...we dont have a visual studio 2015....
dev: so, yeah, its mostly just something we use here, in house. kind of a joke, kind of for realsies...its--
MSPHB: got it, good. Stick the word devops on it, mark it up 60% from last release and throw some words out of the buzzbook on the box.
Good people go to bed earlier.
now, if they just know what they want to do with UniversalApps ..
Will be, err, actually smartphones with Windows ? Which ones ?
I want to buy, by Christmas, a Windows phone .. maybe a flagship like Lumia 940, let's say..
But is MS able to manufacture & launch such things ?
A lot of strange things happen in their court..
PS
I really like the MS band, I would buy one, if available
Yet another set of .NET patches that probably won't install automatically and require manual installation. Something to look forward to next Patch Tuesday. Meh...
In Windows 8 it slapped a six inch phone UI based on touch on a full fledged 28 inch desktop/laptop screen. Again a fiasco.
It used to talk about "multi-platform support", which on close examination turns out to be support for both WinNT and Win98. Now it talks about Universal Apps. But it is only Universal "Windows" Apps. Again Universal "windows" Apps but limited to Windows10. Where do they come up with names? Do they play some kind of buzzword bingo?
Next they will come up with different editions, from ultra tied down dimwitted home user edition all the way to super professional ultimate platignum azure eye-candy business corporate executive edition.
All these antics used to irritate me so much those days. Now I laugh at myself for having taken them seriously.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
You'll probably get flamed here for calling free software users sad and pathetic. I guess that's why you forgot to login.
Oh really?
http://developers.slashdot.org...
http://developers.slashdot.org...
http://developers.slashdot.org...
http://developers.slashdot.org...
With 2012, our project only takes about twenty minutes to open. With the 2015 beta we tried, it took over forty-five minutes to open.
I am surprised no one has mentioned clang or Android support. If you install mobile it will even install Chrome. No you did not misread that folks
http://saveie6.com/
Release . . . the Windows Phone!
I've never had a problem with this. Perhaps your workflow is sub-optimal?
LOL Darkain.
Hmm. Nothing for VS 2008 or 2012. The attitude must by cyclic.
To be honest, I'd couldn't have seen even half of the stuff that they shipped every being there when Visual Studio 2013 came out. An Android emulator? Okay. Upcoming Objective-C support? Hum.
It's a big bet that there is enough demand for better cross-platform code sharing for people to start using the Xamarin environment, and it's even a bigger bet that mobile developers will want to bring iOS and Android applications onto Windows.
There is some method to the madness. The Windows Runtime (the engine underneath Universal Apps) and the Core CLR have some compelling technologies that may have appeal outside the Windows ecosystem.
The Windows Runtime is interesting. It is almost completely oriented around asynchronous APIs. Any operation that will (or can) take more than about 50-100 milliseconds will need to have an asynchronous form. Now, the trick is that async/await in C#, promises in JavaScript and Futures in C++ makes consuming that API tolerable (in C#, it's really not hard at all). It is oriented completely around try to make sure that applications can't block and become unresponsive. In short, if you make it harder to do the wrong thing, it will happen less often.
But, the first form was oriented only towards Modern (metro) applications, and we all know how that turned out. The Universal Apps is doubling down on the underlying runtime and support and seeing if they can get better adoption. Hard to say, but it'll be interesting to see how it turns out.
The other interesting front is Android; there's a bunch of libraries that provide alternatives to core Google APIs. I'm fine with that; alternatives are always good. And the Android subsystem in Windows 10, that's interesting.
Anyway, it may bring some hard-core Visual Studio shops into the mobile space, because you can still say "it's all VS". Lastly, it was a price drop. Ultimate doesn't exist anymore, and it's replacement is half the price. Even Premium was more expensive. I half expect more price drops and incentives to drive more people into the ecosystem.
I have had this happen in other projects.
For some reason VS will just decide it does not like your project for some reason. It will start doing *bad* things. I usually give up and just reset the whole project and start a new 'clean' one and just move over everything. That usually clears up whatever is in that xml/sln/csproj goop that is messing it up.
Visual Studio is now advertising partial but significant C++11 support, and they claim only 3 minor features of C++03 are missing.
Of course, this is quite far from the truth, as it is riddled with bugs and nothing really works, but at least they're trying.
Apparently, you've never used a code repository or worked on a team of developers. (No, not even CVS, since even that handles this scenario correctly.)
Let me give you a big-boy-coder lesson. When you work on a team with other people, you have to make changes to the same files as other developers at the same time as they're making changes to them. When you commit your changes, there may be conflicts with the other changes that other developers have made. A "diff tool" is probably the most basic way to determine what changed and how to fit the two versions together so that the combined changes don't break everyone's stuff.
If you check a makefile in, it will be subject to the exact same rules as everything else, and when two developers make changes to it at the same time, you will need to merge those changes in a non-breaking way.
A Visual Studio project file is just a fancy makefile. It's a build script that is used by VS and MSBuild to manage what is and is not included in the build of a given piece of software, and how the build process treats it (some things are compiled, some are precompiled and used for linking, some are resources, some are raw content, etc.). When there are conflicts in that build script, you have to resolve them, and until you do, VS is unable to load a valid project file.
All of that has exactly dick to do with partial classes. Partial classes are just a means of having autogenerated code in the same logical class as hand-written code, while keeping the autogenerated code in a separate physical file from the hand-written code. That is literally the only thing partial classes are supposed to be used for. You have a single class definition split across two or more files so that a code generator doesn't overwrite your non-generated code.
But you're a Java zealot, so keep on with your shitty 90's-era language, your crusty build systems, and your classpath bullshit.
Well, has it changed much. I read the summary above, and it was 100% gibberish. Honestly I understood nothing of what it said. Buzzwords and bullshit. All I know is that there's probably a new version. So, what's the difference between having no MS stories versus having unintelligible MS stories?
Except for those who were high-school students and couldn't afford to run a dedicated Linux box because they had to share the computer with the rest of the family.
In pre-2000: "MinGW? Sure, it can be put on the computer. Linux? No way, that requires doing a 600+MB partition (or whatever) and is too hard to use for those nor familiar with the command line. "
Apparently, you missed the news from a while ago about Microsoft releasing the CLR under a free software license. Check it out.
I've been a Slashdot reader since back when it was called Chips & Dips. Back then, Microsoft deserved the M$ appellation. Today, not so much. They're cooperating a lot more with the libre software community. Now, you can either shake your fist at them and scream how they'll never be forgiven for their sins... or you can smile, extend a hand, and welcome them to the party.
The world works better if more people choose the latter. And that applies to life in general, not just Microsoft. :)
The problem is the makefile is XML, which can be ordered without losing any information. The diff tool is likely line-by-line. Therefore, there are "conflicts" because the file is reordered separately on two machines.
Your ad here. Ask me how!
No, the TFS diff tool is total bobbins. I get conflicts constantly, particularly in the XML project and filters files, from simple stuff. Oh no, horrors! One person added a file under a filter, and one other person added a file under a filter! PANIC!
To be fair, I use BeyondCompare instead of the inbuilt diffs, and BC fails those as well. But there are numerous other times that TFS flags up conflicts in source files, and you open them up for a manual merge in BC, only to find that there aren't any conflicts. Seriously, Microsoft, this isn't hard. Fuck it, you're rich - just buy out BeyondCompare. While we're at it, VisualAssist have proven that you can do a half-decent job of C++ code navigation and refactoring. Why don't you buy them out and ditch your abomination of a C++ Intelliense implementation? That piece of junk has cost me far too much lost time.
go to channel 9. there's a video showing just how visual studio code (linux or mac)can share the project with visual studio(2013 or the new one) on windows.
since they use git it's really a step in the right direction.
I didn't see anything useful on their page--have they made the bloody application 64-bit yet? We've had tonnes of problems with it crashing with extensions like Visual Assist and a couple custom plugins. The whole environment runs out of memory and brings everything attached down with it. It's pretty ridiculous.
I think you will find a lot of people here just want somebody to hate. MS has dropped proprietary platform-specific extensions in favor of chasing standards compliance, their big-ticket product MS Office is now available on Linux with Office365 (and native apps on OS X, iOS and Android), they're soliciting and responding to feedback from the community (Windows Insider and XBox kinect, back compat and internet connectivity) and they are releasing a lot of open source software along with the patent promise.
They're doing exactly the sort of things you would want a company like that to do because these days MS is a different company run by different people operating in a different environment. And when you consider that despite the 20-odd years of Windows hate it is still the dominant desktop operating system by a very wide margin, the last few years of change are a good thing.
Buying out BC is probably one of the smartest moves they could make for Visual Studio, but perhaps one of the worst things that could happen to BC
I can't tell if the "developers, developers, developers, developers" was intentional or not.
Windows updates you can time with a calender.
https://www.youtube.com/c/BrendaEM
It is sad and pathetic that the quality of newer OSS development tool releases has become so poor that they're no longer note worthy.
While we're at it, Python Tools for Visual Studio 2.2 has also been released at the same time. In addition to VS 2015 support, this is mainly a bugfix and do-small-features-that-never-make-the-bar release. If you're a Python developer on Windows, please give it a try, especially if you've never heard about it before. Feel free to tell me that we suck so long as you also file a bug in the tracker. ~
(Full disclosure: I am a developer on the PTVS team.)
Microsoft got its start as a publisher of BASIC interpreters and continues to maintain Visual Basic. In the line-number era, before DEFSTR and DIM...AS statements, all string variable names in BASIC ended in a dollar sign. For example, this was valid code:
In addition, comment subjects on Slashdot are limited to 50 characters, and M$ saves seven.
emacs would be a great IDE if only it had a decent text editor
Does Viper count?
Or, you could just BC...
The compiler and linker have 64-bit versions. Add this environment variable
PreferredToolArchitecture=x64
and the 64-bit compiler and linker are used from an IDE build (this is for C++). The IDE remains 32-bit.
You do need special considerations for XML files though - there are several solutions
The weakest solution is to rely on the ability of the target user to spot diffs and correctly merge XML files. And also not to use automatic merging, ever, because the nature of XML files means that conflicting changes may not occur in adjacent lines.
---
The next (and inadequate) solution is to order the XML consistently - you can do this in your diff tool, or you can write your tools to produce a reliably ordered file in the first place.
Many tools that work on XML files exhibit what I call "juggling" - the elements and attributes change order when you change the value of them or their siblings, because the software is directly using the DOM to manipulate the file - and does this by creating new objects and removing the old ones from the collection. This is a real PITA for text-based diff tools because not all the changes will even conflict with each other (element sequences are often spread across multiple lines, more so if you put attributes on their own line to enhance the ability to merge).
So, you can either write your code to write a consistent order - usually by serializing a fresh XML stream from a model when you write the file.
Or you can add a layer that re-orders the document when you diff it - many of the available diff tools will let you do this. For some files, I used to write an XSLT sheet (to re-order elements consistently). For attributes, I wrote an extra option for Tidy that sorts attributes - doing that plus laying them out on separate lines is sufficient for many files. I've gone as far as writing custom tools that unpack HTML written into an attribute (with all the escape sequences that entails) into a CDATA section for clarity, runs it through Tidy, and then repacks everything after you're done.
---
Intermediate : I've thought of taking this a step further and converting the XML to a directory tree of text files designed to merge well, principally to make things clearer for end-users who currently have the kind of diff-tool-plus-converter described above but still occasionally make merge errors.
---
The next step is to write tools to specifically diff your model. This is probably a bridge too far for most developers, because we have the kind of brain that can abstract a text representation of the model and map it to the actual model that will be created. For end users, it may well be advisable.
Diff / merge tools are a field that need more work - currently the main users are developers who can cope with them being a bit immature. But we will increasingly see collaborative tools based on the kinds of version control that we take for granted, and normal users will need to be able to do this stuff too.
I've had cases where I had to restart VS when debugging Azure web services, and that was in VS 2013. It's pretty rare though, to be honest.
> I cannot fathom why any rational actor would choose to develop anything but .NET in Visual Studio.
Two words: CODE COMPLETION
Dafuq?
"At my current job, we use Visual Studio to write web services in C#. The experience has shocked me."
What is wrong with it, or more likely: what are you doing wrong?
"the 260-character limit of path & file names"
That's a filesystem limitation, not a VS issue. But what on earth are you doing that requires anything that long in a Web Service? Are we talking old SOAP web services or modern REST/Web API services?
I stopped upgrading after they took away the icons, have they brought it back in 2015? is it worth looking? why not just create a skin for it and let who ever wants to use it ?
Have they added new refactoring after learning from "resharper"?
SOAP, you got it. We're moving away from it - not fast enough, but there's plenty of inertia here - but you add a few service references to your project, deploy under My Documents/Visual Studio/Projects and 260 characters run out pretty quick. I'm embarrassed to say that it didn't occur to me that it was a limitation in the filesystem rather than VS/TFS itself. There are other problems I mention which I think I can safely blame on VS alone.
What do *you* use VS for? I would love to hear a compelling argument for paying to use VS to write, e.g., Node.js or Python. Maybe my negative experience is attributable to still using VS 2010 at work - then again, that we even still have 2010 (because somebody's slow to upgrade) is an argument against a paid IDE in itself.
They'd make millions.
Don't fault automatic merging. That's not the real problem. Automatic merging of patches to XML documents works quite well.
What fails is the diff tool used. It usually assumes unstructured text. With C code, that means the braces of an extra level of indentation are usually misinterpreted - the first open brace is matched with the first closing brace, not the last. This isn't particularly bad. With XML and unique tags, even this problem doesn't exist, as the new open tag is textually different. But once you have a list of identical tags, the typical diff tool mis-parses the addition of an extra instance of that tag in the middle of the list. The content of that tag is detected as the first new line, not the preceding opening tag.
A diff tool that parses the XML can compare actual tags and spot the entire new tag, generating the correct patch for auto-merging.
I use it for C#/MVC/WebAPI(REST) business apps. No node.js or python at work, although I do play with it outside of my work tasks.
Yes, if you're still using VS2010 I bet you're running into some issues.
One thing you might try is to make a \Code or \Source directory and move your projects there, rather than in \My Docs\VS\Projects - that does add a lot of unnecessary characters to the path name.
Very glad I'm working for a company that doesn't sit on it's hands with Visual Studio. Already have VS2015 installed on my work machine and I'm cleared to use it as soon as I get one our proprietary add-ins rewritten as a VSPackage extension. (They just nuked the old-school Add-Ins support in VS2015.)