Slashdot Mirror
Microsoft Releases Visual Studio 2017 (visualstudio.com)
Reader Anon E. Muss writes: Microsoft on Tuesday released Visual Studio 2017. The latest version of the venerable Integrated Development Environment supports a variety of languages (C/C++, C#, VB.net, F#, Javascript/Typescript, Python, etc.) and targets classic "Win32" desktop, Universal Windows Platform (UWP, also known as "Metro"), .NET, ASP, node.js, etc.). A "Community Edition" is available at no cost for individual developers and those working on open source software. "Professional" and "Enterprise" editions are available for corporate developers, at prices sure to shock whoever has to sign the check.
crappy summary for the slashdot crowd. we know what visual studio is - what we want to know is what, if anything, changed
Or it is so cheap that will shock the one signing the check?
At least they dropped Foxpro support.
nuget
Microsoft,
It's 2017 and Visual Studio is still 32-bit.
Sincerely,
Developers
My MSDN account shows both 32-bit and 64-bit are available for Professional.
I code all my apps in COBOL
Fully licensed blockchain psychiatrist
There's VS for Mac.
The Professional version is $500 (license, not subscription):
https://www.visualstudio.com/v...
That seems very reasonable.
Enterprise is quite a bit more ($6K for new, $2.6K to renew), but it is part of the MSDN Enterprise (previously Ultimate I believe, that's what my license is called at this time), you get access to almost everything MS has ever made (want Windows 3.1 or DOS 6, it's there, want enterprise SQL Server, it's there).
Here's the link to the prices:
https://www.visualstudio.com/v...
BlameBillCosby.com
The people who have not shock whatsoever signing that check are usually not spending their own money.
The IDE is 32bit. The compile, debug, profile etc chain are 32bit and 64bit.
There is probably no reason for the IDE to be 64bit since it does not come even close to use enough memory to justify that. I have opened a few visual studio projects in 2017 and most of them don't use more than 200 MB. Resource usage so far is about half that of VS 2015.
Computer modeling for biotech drug manufacturing is HARD!
Now if they would just make it standards compliant and add basic endian macros, it would be even greater!
Anons need not reply. Questions end with a question mark.
I use and like VS quite a lot, but am not precisely an early adopter. At the moment, I am mostly using the 2012 version and, eventually (= when forced to do so), the 2015 one. Actually, I am not even sure why I stopped using VS 2010 because it was quite reliable. I have seen some problems with 2012, but have gradually got used to them. I haven't used 2015 much, but don't think that I like it: it consumes too many resources, even for my a-bit-old-but-quite-powerful desktop computer.
I am currently downloading the 2017 Community (clarification which is perhaps still required: fully-functional free version, which has nothing to do with the old VS Express) and everything looks OK so far. The downloading interface seems nicer than the previous ones. Microsoft promised this version to be much more modular and apparently they delivered. I am saying apparently because the options are there, although the size is still quite big anyway (over 7 GB after having chosen the most basic options).
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
In the last VS I had to add a compiler option to stop you from sneaking your snooping crap into my code, what is it going to be this time?
Yours,
An Ex-VS user.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Does anyone know if they've fixed the privacy concerns about the Community edition yet?
Last time I checked, there were multiple inter-related privacy policies that seemed to apply, but between those and the general terms it seemed clear that they could upload more-or-less anything (including, say, your code) through their telemetry processes. You also needed a Microsoft account to even continue using the IDE after a few days.
This sort of nonsense simply shouldn't be necessary in real world development tools.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Don't be ridiculous. That's what we have EMACS for.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Unless you have specific use cases 64-bit doesn't always mean better. Most apps don't need the extra address space, and jumping to 64-bit means doubling your pointer sizes, which increases memory usage, reduces locality, and puts a larger burden on cache.
In VS's case they did the math and 32-bit was better. They've said this for years now. It's not a bad thing.
I'm assuming you meant Visual Cobol...
https://www.microfocus.com/pro...
BlameBillCosby.com
wasted cycles are wasted cycles.. sloppy javascript cruft is annoying.
Only if you ignore their snoopware push.
Table-ized A.I.
What? We have a minimum of 16 GB to run that bloatware because otherwise just editing text files is slow as hell due to swapping. VisualStudio needs at least 8 GB in order to edit text files. That requires more than 32 bit.
Same here. Trivial projects are fine with a 32-bit IDE. Running 2017, my devenv.exe right now is 1.4GB by itself and has ~50 child processes, which total another 2GB or so. If I open a XAML file, that usually doubles shortly thereafter.
Instead of making the IDE 64-bit to hold all the relevant data structures in a clean fashion, they wind up duplicating data and increasing CPU load by utilizing subprocesses. It reminds me of someone using segmentation to avoid migrating from 16-bit to 32-bit. Sad!
I run multiple instances of VS of various versions (2008, 2010, 2012, 2015) at any given time. Each instance takes around 300MB, on average. One of the larger solutions (87 projects in that solution) takes close to 1GB.
All of them run fast enough unless there's something else weird going on (not uncommon, but not a daily occurrence).
You need 8GB just to run one instance and that instance runs slowly? Whatever you're doing, you're doing it wrong.
And, BTW, the devenv.exe binary is 32-bit and won't take more than 4GB of memory, so you're also technically incorrect. (The best kind of incorrect?)
I don't see what people find interesting or exciting about .NET Core -- it's just a rebranding of the compact framework with some additional supported platforms. Honestly, the entire point of it seems to be to try and entice people to use Azure for hosted stuff and only use small parts of the framework for desktop apps (pushing them towards the "Universal" appy-store apps and away from full Win32 style desktop).
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
yes slashdot also showing ad for 21st development wares, MicroFocus Visual COBOL. Get it while it's hot!
But you should be able to create an offline installer
You might as well just have posted, "I don't know anything about software development."
"Old man yells at systemd"
After testing it for some minutes, I found two interesting issues: .NET Standard), which are only present in C# (no more duplication of everything C#-VB.NET?!). And here I found a not so pleasant surprise: after creating a new .NET Standard project and the opening window including (sorry about the crappy indentation, but the editor forced me to use less 'junk' characters):
... VS complained about not being able to find the System namespace!! and the class being wrong because of not finding System.Object!! I guess that this has to do with my initial selection of modules (perhaps VB.NET not supporting the new projects is another consequence), but come on!! How can the code generated by default be faulty?! This isn't a bug, this is pure terrorism! LOL.
.NET versions to be improved during some time (e.g., various years) before using them, to avoid "peculiarities" like the aforementioned one or simply because of being happy with my current version. But I will do a small exception this time: I have to develop a reasonably big C# code during the next weeks and do feel like trying VS 2017 (by assuming that it can keep up). So, I will write the third and final part of this post in some weeks, after having got a proper feeling about this new version.
- It loads pretty quickly. Right after restarting my computer, the fastest one is VS 2012, then 2017 and, finally, 2015. But, when executing them for a second time, 2017 becomes even faster than 2012.
- It has some new project types (.NET Core and
using System;
namespace ClassLibrary
{
public class Class1
{
}
}
I usually let new VS or
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
it's just a rebranding of the compact framework with some additional supported platforms
When one of the supported platforms is now Linux it's a pretty big deal. The people that are interested in web applications but like to work in a programming language that doesn't suck no longer have to be shoehorned into Ruby or, heaven-forbid, JavaScript.
Try installing that "64-bit" version. Pretty sure devenv.exe is still going in "Program Files(x86)".
See: https://docs.microsoft.com/en-...
About **still** using msvsmon.exe to debug 64-bit in 32-bit VS...
Ya, cause windows on windows is such a great idea for core applications.
No I am not making this up either. Also a beta version of Visual Studio for Mac is available too as well as better Android and IOS support. VS since 2015 also comes with Java and Android emulators as well via Hyper-V.
MS is getting quite serious about being cross platform
http://saveie6.com/
The community edition is not the crippled express editions. You can even make professional software with it too. THe only difference is the MSDN subscription and corporate Team Foundation features for teams and groups.
THe Community Edition even comes with Git and Git tools to use for things like Github.
So why is everyone whining? Things are not free to make and like Redhat there is CentOS for those who do not need enterprise support but is there for those that do.
http://saveie6.com/
Given that Windows has more or less become defacto 64-bit with just a few 32-bit outliers on tablets, it doesn't make much sense to remain 32-bit any more.
ANd yes replying to myself I also want to address the grand parent for things like SQL Server.
If you want the full thing go to www.technet.com and download it? It timebombs after 180 days but MS allows you to run it and Windows Server Enterprise editions free for non production or business use for IT professionals in virtual or stand alone machines. The Community Edition comes with SQL Server Express but I downloaded both the SQL Server for Linux 2016 and the regular win64 SQL Sever 2014 and Server 2012 R2 that I run in Hyper-V on my desktop.
http://saveie6.com/
Now Satya has to do the song and dance, "developers, developers, developers ...." .
But this time the music will be arranged by AR Rahman, and the famed dance coach Puliyur Saroja who directed the dances of the Superstar Rajnikant will choreograph the performance.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
My main criticism of it is is that it's a pain in the ass to configure. Just like Atom, Brackets, Sublime etc., it does away with a proper settings dialog and configuration is by editing a JSON-esque file. Even if this makes sense for advanced configuration it really sucks just to configure some simple thing.
I used to get hired to create VFP layers to bridge SQL Server, AS400 and other databases to other apps because it just worked and worked well.
Wasn't a "real" Windows app in some UI ways, but when you needed to push/pull data to and from disparate back ends and integrate that data into COM based Outlook, Word, Excel and other Windows based applications, there was nothing better. We'd have C# guys come in and try to migrate VFP apps and they'd whine at the requirements to do things that are simple in VFP.
In 35 years of heavy relational database focused consulting on different platforms, nothing was as easy to use or as powerful as VFP.
So there!
Peace is easy to achieve, just surrender. Liberty is much harder get/keep.
With the HPC C++ project I am working on even with the Intel tools loaded and after using stuff like Vtune and a debugger I am getting about 200MB of usage with VS2017 and under VS2015 I end up with about 500MB of usage. I also do not see a bunch of children processes. At least from my experience VS2015 is faster and lower resource usage than Eclipse or PyCharm.
At least with C++ the resource usage seems pretty minimal.
Computer modeling for biotech drug manufacturing is HARD!
+1
I am jealous. The 26 project solution (~6500 *.cs files, ~500 *.ts) I've got open in 2015 has Task Manager reporting ~1.5gb of use... granted ReSharper adds to some of the CPU/memory usage as well.
One of these weeks/months/years we will break up this monolith... until then, much CPU/clock time is spent paging things to disk rather than allow the process to grow to a size it would use more of my local machines memory.
With any luck I'll be able to throw 2017 on the machine this evening & give it a look.
Help Brendan pay off his student loans
It says 2017, but that might be misleading -- it does not fully support C++x14 (release notes say "better" x14 support. I'd like to see "full x14 compliance & support"). And they're a ways from full x17 support.
You get spoiled using Clang/LLVM
Ian Ameline
I've read the pages where Microsoft attempt to justify this decision, e.g. https://blogs.msdn.microsoft.c.... I don't buy it. It's institutional laziness and resistance to change first and foremost. Choosing on a per-application basis whether to make it 32-bit or 64-bit is madness, especially in the situation here where you force every plugin and library being loaded to be 32-bit. You're developing a *system*, but it's really an agglomeration of different bits with little coherence or common direction. Linux distributions got this right. The whole installation is x86 or amd64. No confused mess of the two, x86 compat libs aside. We didn't agonise over minutiae, we did a complete conversion by treating them as two separate architctures, with biarch and multiarch for running legacy code. As is typical for Microsoft, they didn't have a transition plan, leaving much of their product line 32-bit only despite most developers and user having fully transitioned to x64 Windows over a decade or more back. Meanwhile on FreeBSD, Linux and MacOS X 32-bit is a distant memory on 64-bit platforms; the transition was done well over a decade back for many distributions as amd64 rebuilds were completed. What's tragic is they did the exact same thing with the 32-bit transition. Remember what a mess it was in the mid-90s to mid 2000s with a jumble of 16- and 32-bit code? It's exactly the same mess today with 32-bit and 64-bit code! They need some direction from the top to pull their fingers out and go 64-bit only, or do builds of both. If the BSD and Linux distros can build code for >10 architectures then I'm sure Microsoft can manage two, or three if we count their arm port (which is even more limited due to their x86 depenence, who would have expected that... Maybe build all your code on all architectures and x64 and arm could be first-class citizens.)
Instead of going "yay VS 2017" I googled "Couldn't install Visual Studio 2017 community edition"
SHIT TON of hits. More than a million. Sad, just sad.
Did you do a quick review of those reports to see how many of them were from Nov/Dec 2016, and referred to one of the release candidate versions?
You might want to note that release candidate installations are usually created for the purpose of discovering the problems which occur for different users with different environments etc, so they appear to have served their exact purpose, and enough people were enthusiastic about VS2017 to both participate as an early tester and post reports about their problems. Looks like an acceptable software rollout process to me.
If I had a DeLorean... I would probably only drive it from time to time.
A relative works at a bank programming exclusively in COBOL, and does quite well. That language will be around for quite some time.
"Who are you?" "No one of consequence." "I must know." "Get used to disappointment."
Go use Clang then? It is included in VS 2015 and VS 2017
http://saveie6.com/
If they are child processes they run in their own 32-bit space and don't count against the memory uded by the parent process.
I once installed the 2015 Community edition on a Windows 7 system to check it out, kick the tires, etc.
It shit all over the system, there was no integrated installer (of the type there is when you install Microsoft Office) and it created 'restore points' for every single package and component that it pulled down and installed. I wanted to maybe check out some Visual Basic and C++ and dabble with it a bit.
It installed the whole SQL tool chain, server, etc. There really weren't any options for installing just the components to run VS on a standalone machine, in the fashion that there was with Visual C++ 6.0 back in the day.
The VS installer basically shit all over my system, and uninstalling it would have involved manually uninstalling each component part using the Control Panel. The 'restore points' were totally consumed going way back in 'history' because it set a restore point for each and every fricking component.
Have they gotten any better with that? I am a little bit afraid to try installing it to find out.
What's really bad is that the QB64 that compiles an enhanced version of Microsoft's QuickBASIC has one code base that compiles a 32 bit and a 64 bit IDE. Granted there are limitations such as the 32 bit IDE only compiles 32 bit programs and the 64 bit IDE compiles only 64 bit programs, but it has that feature.
Thats because tthe object oriented features were buggy as all hell. I have never worked with a program that was as buggy as Foxpro.
Ignore the object oriented stuff - and it was rock solid. Its as if all the code Microsoft bought was solid, and everything they added was swiss cheese.
In Soviet Russia the insensitive clod is YOU!
Your experience with other ides means Visual Studio should be 64 bit? Nope, sorry, try again. Everything else is 64 bit? Not a good justification.
Your scenario of lots of stuff doesn't make sense for VS. You would have a current config and target for each project, but that info is mostly for the build chain. The IDE loads some metadata, but you're more likely to run out of memory due to larger pointers than anything else.
There are good ones out there, but you haven't really made an effort here.
VS2017 has a new installer that's supposed to be better at managing components, languages, etc. I haven't tried it myself though, so I can't give a recommendation either way.
Irony: Agile development has too much intertia to be abandoned now.
Meanwhile, in other news, Bram Moolenaar releases vim 8
it's pretty easy to OOM Visual Studio with huge C# projects - the language service just brings it to its knees.
but for a file->new->todo-list product launch demo it works just fine. ship it!
Yes. For at least 12 years
The last time I installed VC (taking several hours)... it was not able to completely un-install. It wrapped itself around IE and popped up a debugger every time IE encountered a buggy web page.
It is not just about memory. Twice as many registers, 64 bit integers, faster syscalls and so on.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
I code all my apps in COBOL
I app all my apps in Intercal.
That seems to answer my question of "should I upgrade?". Actually I have a more general question, apart from 2017 allowing me to leverage the synergy of the cloud in more cromulent ways than before, is there any reason to move from 2015? Specifically, have they improved the compiler diagnostics or PREfast analysis in any significant way (2013 and 2015 were identical in that regard)? That's what I really want a compiler for, the rest is just window-dressing.
I'm sure I read somewhere that the extra registers are part of the processor package and not limited to 64bit use - you just need a compiler which understands how to use them in 32bit mode...
The only reason to stay 32-bit is legacy dependencies, native extensions and so on. Staying there because 3.5GB is good enough for most people (where have we heard that sort of argument before) isn't a good reason. Ironically Microsoft themselves recognize these limits themselves and have written blogs about how they've strived to reduce memory consumption that was hitting the limits. Even some of their scenario improvements still leave consumption in excess of 3GB.
Installing VS2017 overwrites a dll shared by VS2008 that handles the debugger. So with this new release, devs now need to run VS2008 inside a VM for it to work properly.
I've run out of memory in large projects on other IDEs.
It means that your "other IDE" is a memory hog.
Visual Studio is quite light for the amount of features it offer, you won't get to 4GB that easily.
In fact, that limit pushes Microsoft to reduce their memory consumption. That alone is worth staying at 32 bits. Software eating up all your memory for no good reason is one of my pet peeves.
And no it's not that other IDEs I use are memory hogs, and more a reflection that some software projects, such as the ones I develop in those IDEs are extremely large. Not just to develop against but when they're debugged and the IDE sags the weight of a large project with all its symbolic info, debug state and profiling that's going on. Indeed in some cases there might be multiple things being debugged at once.
I have finished my analysis of VS 2017 much sooner than expected because of deciding to continue writing the aforementioned code with the 2012 version. Without getting a too bad impression about it, I didn't feel comfortable enough to continue; additionally, I found what IMHO is a serious issue which should be fixed right away.
As already pointed out, the modularity of 2017 is very appealing and allows a very light environment which is certainly quick; as quick as the much older and under-featured 2012. Note that, during the installation, I selected the main C#/VB.NET desktop and web options and some basic Visual C++. For me, just this issue makes this version more appealing than 2015.
In its default configuration, 2017 has much more coding helps (all the bells and whistles automatically appearing when typing or moving the mouse or similar) than 2012 and 2015. This is one of the defining features of VS with respect to other IDEs, but Microsoft might have brought things way too far on this front. Nothing of this seems to affect the VS usability (quick and responsive; additionally, all these functionalities are likely to be easily disabled) and that’s why I cannot say that is completely wrong. Small details helping to improve your coding experience are certainly nice, but including too many details which virtually nobody would ever use (e.g., showing some information when placing the cursor in certain area which can quickly be retrieved in 3 different ways) doesn't seem too logical. All this is even more relevant by bearing in mind the usual evolution of VS releases: first versions full of bugs which usually take over 1 year to be fixed. They have an excellent underlying framework (almost none of the new features since VS 2008 have improved my coding experience in a relevant way), why unnecessarily making it buggy or kind of joker-of-all-trades-master-of-none? I think that Microsoft should eminently focus on delivering reliable and bug-free versions, rather than on continue adding not-too-useful features.
In general terms, I felt quite comfortable working on VS 2017 (at least, before discovering the problem below), but by basically using it as VS 2012. Note that I continued a C# (library + console) project created in VS 2012. Right at the start, I saw a curious error-over-reporting issue: a simple 1 error in 2012 clearly stating the problem (wrong definition of a class) vs. 88 in 2017 (one for the wrongly-defined class and 87 for further references to that class). I saw also other weirdnesses like expanding a tree of sub-folders in the project window which got suddenly closed. But all these things happened just once or twice and I was kind of expecting them, so I didn't really mind any of this (on the other hand, this should be seen by Microsoft as bad news: I do expect random errors and glitches in a first VS version because this has always been the case!).
The real deal breaker was the problems with the debugger: it plainly doesn't work as it should. I tested the created-in-VS-2012-a-bit-complex code, also new-2017-extremely-simple projects and the behaviour was always quite chaotic via ignoring lines for no clear reason. For example, I usually write codes including something like string string1 = "whatever"; string1 = string1;, where the whole purpose of the second line is to hold a break-point (where I will see the string1 properties via the popup window); VS 2017 skips the break-point in this second line! And this skipping-lines behaviour occurs in other situations, what makes the whole debugging process very uncomfortable right away (I have relevant experience in different IDEs and languages, VS and C# among them; I don't need to spend even one minute to try to fully understand the unexpected behaviour of a debugger to know that I don't like it). Hopefully, this is just a buggy behaviour and Microsoft hasn't actually modified the way in which the VS debugger has always worked. Another issue I didn't like too much about debugging was the fact that the break-poin
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.