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.
Another version of .NET means update times get increased again. Christ all fucking mighty, Windows has become a dog.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
you don't see the huge time savings seasoned developers will get with the new features.....It could cost $2000 more per license and it would still pay for itself within a year.
Really? Which features are you thinking will be worth that much? The improved Azure integration? The slick Agile planning tools? The brand new XAML editor?
"First they came for the slanderers and i said nothing."
> no more free development for .NET 4.6 with visual studio
Community supports the vast majority of useful features... and really, what's the problem with it costing money if you want more than 5 developers or have a $1M+ turnover company? You're still allowed Community if you're using it for classroom learning, academic research, or open-source development.
If you're working for a company that presumably makes money from writing software (in one way or another) is it really so bad to give some of that money to a company that helped you do that with their product? If you hire a developer, their salary is far more than the $1,119 it will cost you for VS Pro with MSDN ; do you really want to waste their time by making them write their code with a text editor and build it with just the .NET SDK tools?
I usually prefer SharpDevelop for my .NET dev but I've not done any in a long time - I'd be inclined to give Visual Studio a go, even if I've found it's prior iterations to be far too handholding and patriarchal.
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.