Visual Studio 2017 Launch [video]
launch.visualstudio.com
launch.visualstudio.com
Is this available in VS 2017?
Edit: and live unit testing! I was looking forward to that until I found out it was only available in the enterprise version. (And yes, here you have an edge on Java anyway I think)
I'm a dev on the C#/VB IDE experience (and i've written and maintain many of the Refactorings for those languages). C# and VB do support refactorings like 'Extract Method' and 'Move to Separate File'.
We've also exposed a full analysis and code manipulation API through 'Roslyn' so that community members can contribute even more refactorings through extensions.
One reason this may not have been clear is that previously we didn't strongly indicate to you that a refactoring was available. i.e. when you selected some code to extract a method, you would then have to use ctrl-dot to get the list of things you could do. Now, in VS2017 we pop up our 'Lightbulb' whenever refactorings are available. This helps make the refactorings much more discoverable and we've seen a very large uptick in people invoking them now that it's much clearer that they're available.
If you use VS2017 and find issues with our fixes/refactorings, or you would like us to add more, please file feedback at https://github.com/dotnet/roslyn Thanks!
Some gifs I prepared a while ago to explain what I mean (it seems that the parenthesis problem has been fixed in VS2017 though):
It was still slow, but somewhat less so. :)
Every new version I give it a try to see if the perf problems are fixed, and every time I have to turn it off after a few hours.
Core support is coming; first beta just released. I believe that targeting a constantly changing tooling set was/is quite a challenge.
Will try reshaper as well before deciding to buy any of them.
Beware: I'm pretty sure I failed a job interview as I was so used to Resharper, when I needed to do a test on a PC without I was fairly lost. They had no interest in my setting up unit tests first for the programming tasks so it might have been just as well.
Same here.
Thanks for the updates.
For some reason I though Reshaper would be incompatible with NCrunch but I will try them together now.
- Resharper supports "Extract class" and "Move to separate file".
Wishful thinking?
The download link takes you to a page ( https://www.visualstudio.com/vs/whatsnew/ ) where the main download button doesn't actually appear when the window is resized below a certain width, and there's no obvious indication of what's going on. This really confused and frustrated me.
https://www.visualstudio.com/thank-you-downloading-visual-st...
I attempted to create the offline installer [1] but the vs_community.exe just silently quit after some mintues, having downloaded only some certificates.
The custom download idea is easily planted with malware and all those bad things. Also, please consider upgrading from SHA-1.
> We understand that a lot of customers want an offline installer for Visual Studio 2017. Even though we don't offer an ISO image, it's easy to create your own.
1: https://docs.microsoft.com/en-us/visualstudio/install/create...
1. Visual Studio 2017 is a huge product, because we support so many types of development: from Android to UWP to C++ to Unity to Linux. If we were to still offer a 'full' install, it would come in at over 50GB. That's one huge ISO image!
2. We surveyed hundreds of people during the previews and RCs, and people told us that they had historically used an ISO for two reasons: (i) because they wanted to download once and create a network install for enterprise deployment; (ii) because they had a shaky internet connection and wanted to be sure they'd downloaded successfully before installing. A single monolithic ISO isn't the best solution for either of those scenarios - it's just the one that people are habituated to over all these years.
3. For the former (enterprise deployment), we have a full administrators' guide that provides detailed guidance on how to deploy the product: https://docs.microsoft.com/en-us/visualstudio/install/visual.... This includes PowerShell scripts, examples of using the installer to create and update a network cache, descriptions of how to deploy Visual Studio in a fully offline environment, and so on.
4. For the latter, we've worked really hard to improve the robustness of the installer. The componentization work we've done means that the smallest install is one-tenth the size of Visual Studio 2015, making it far more likely to succeed. And other typical installs are smaller too. We download VS in small packages that are more likely to succeed, and we use multiple ways (WebClient, BITS, WinInet) to download those files to minimize problems with AV and proxy software. If you want to download first then install, you can use the offline guide to cache just those pieces that you need, which we've just rewritten for RTW: https://docs.microsoft.com/en-us/visualstudio/install/create...
5. Because of the nature of our product (rapidly updating, lots of third-party components), an ISO is problematic. We don't have the rights to redistribute several large components (including Android), and others update on a rapid cadence that often includes critical security fixes, meaning an ISO image is incomplete, often outdated, and potentially insecure. Most customers assume that an ISO would support offline installation, but that's not true. And so we fear that offering an ISO will just creating more disappointment.
Lastly, we're listening to requests for an ISO and paying attention to the feedback we're getting; at the same time, we're hoping that this is the release where we can gently move forward to a new model that better supports delivery of developer tools at a fast, well-maintained cadence.
Hope this is useful context. And again, we're listening :)
Tim Sneath | Visual Studio Team
I feel an ISO including only standard packages from Microsoft itself would solve a lot of issues.
Layout is really crappy around blocked files or corporate firewalls. It feels untested in anything other than a completely open environment because some of the package downloads can fail silently with a fuzzy enterprise proxy. Creating layouts for patches seems dependant on what direction the wind is blowing, I think 2015 Update 3 took about 4 tries to download everything correctly and only way to verify was reading through the logs. Also that one needed a random Windows KB update on Windows 7 which was extra fun.
Better handling for layout around error handling and validation of downloads would be a boon. It would be great if there was a way of verifying an already created layout. Is there any way?
- During the installation, the installer can download the smaller needed updates. SQL Server installation does that.
- A company can download the 50GB file once only and put it on a network drive and the developers can install it from there. It saved bandwidth for the company instead of each dev downloading the same bits over and over.
- What about the machines that are not connected to the Internet? You mentioned there are ways around this.
I am fine with none ISO's but I wanted to post the counterarguments.
The command line I used:
vs_Enterprise.exe --layout z:\VS2017_RTM --lang en-US
...
Download of 'https://go.microsoft.com/fwlink/?linkid=823168' succeeded using engine 'WebClient'
Download of 'https://go.microsoft.com/fwlink/?linkid=833503' succeeded using engine 'WebClient'
Download of 'https://go.microsoft.com/fwlink/?linkid=833501' succeeded using engine 'WebClient'
Download of 'https://download.microsoft.com/download/B/5/5/B55373E5-8948-41DF-B1D5-F60896104294/WinSdkInstall.ps1' succeeded using engine 'WebClient'
Download of 'https://go.microsoft.com/fwlink/?linkid=838828' succeeded using engine 'WebClient'
2,631 Files, 1,005 Folders total 14,444,652,261 bytes
Well, it still doesn't work. Please let the MS team know that there's something about the offline download ("--layout" option) that's fragile and prone to hang. I don't believe it's an issue with overloaded servers because when I tried multiple times with RC2, it always hung on the exact same file whether it was morning/night/ weekday/weekend. I suspect the current problem is similar.
I took a screenshot of the hung process for RC2 in January and it seems to hang right after downloading WinSdkInstall.ps1 which is similar to RTM behavior:
RC2 hung in January: http://imgur.com/a/uwfoj
RTM hung in March (today): http://imgur.com/a/QxqC3
I want to the %TEMP% folder and looked at dd_setup_2017??.log and saw that it last executed:
Running: C:\Windows\SysWOW64\\WindowsPowerShell\v1.0\powershell.exe with parameters: -NoLogo -NoProfile -ExecutionPolicy Unrestricted -InputFormat None -Command ...
I remembered that sometimes those commands hang on network paths so I ran "vs_Enterprise.exe --layout" again to local "C:\VS2017_RTM" instead of mapped "Z:\VS2017_RTM".
It then completed without hanging. The completed target folder has:
1,901 Files, 765 Folders total 22,171,951,890 bytes
It seems also to be broken, or your servers are choked :-(
If there is licensing complexity in making an ISO file, just make a ZIP file of the whole thing.
lol.
https://www.hanselman.com/blog/HowToMakeAnOfflineInstallerFo...
*more than 5 developers using visual studio community
As a one man shop, I used to buy Visual Studio but now I don't, so I'm thankful for the Community Edition.
For anyone else that still wants to write straight C, there are other compilers and Microsoft has integrated clang's frontend with VC++ backend.
This has already been communicated in a few places.
Cloudfare's crash just proved once more why the world needs less C.
Of course it doesn't help if people write "C with C++ compiler" and better alternatives are desired, where copy-pasting C code is not possible.
Eventually one of the current candidates will won over the roles of C and C++, except for environments married with C, like UNIX derivatives.
Until then, when the choice boils down only to C vs C++, there is no question that in regards to language features for writing safer code, C++ is the only possible answer.
I'm not sure anybody targets C++ as an intermediate language when emitting code at this level. (I do have written some code that emits some C++, but at a wildly different and higher level). I'm not sure this would bring any value.
"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. "
Hoare, 1981 -- http://www.labouseur.com/projects/codeReckon/papers/The-Empe...
Also the C++ standard is 1500 pages long. I prefer to avoid knowing that as a backend language when I can...
Which C programmers keep failing to do, regularly, according to the CVE database.
> Also the C++ standard is 1500 pages long. I prefer to avoid knowing that as a backend language when I can...
Which includes the libraries that C lacks.
ANSI C + POSIX isn't much shorter than that.
Again, we were talking in the context of the language used as a backend, output by a compiler using an other higher level language as the source.
Then I added NodeJS tools and everything went into the C: drive.
If I select Cordova and other Android and mobile stuff it quickly complains that I do not have enough space - which suggests these tools and SDKs are hardcoded to C: as well. I have not investigated in more detail.
It's a minor nitpick, but I must say I was disappointed to see this issue unceremoniously closed: https://visualstudio.uservoice.com/forums/121579-visual-stud...
I am curious, did you vote for this item? If so, did you receive an email when we closed it?
Thanks! Eric, VC++ Team
Tomorrow we have a full day of training for both a Web and App development track. Hope folks tune in and all the details are up on http://launch.visualstudio.com
Plus, IMO, the language is a lot more readable and enjoyable to author in than overly verbose XAML.
Visual Studio 5.0 was very responsive. Visual Studio 2015 is not as responsive. Nowadays it seemes a bit bloated, even after disabling unused plugins and features.
Switched to CLion and Rider, which are not known for their speed, but feel more responsible than VS to me. That and a more affordable price and cross-platform support.
(VS "15" is Visual Studio 2017)
We also have Visual Studio Code for those who want a lighter code editor, see: http://code.visualstudio.com
[1] https://github.com/louthy/language-ext/
[2] https://github.com/louthy/language-ext/blob/master/LanguageE...
[3] https://github.com/louthy/language-ext/blob/master/LanguageE...
Is it much more self-contained now? perhaps via nuget?
Visual Studio IDE - A broad range of enhancements in Visual Studio 2017, including reduction in startup and solution load times, sign in and identity improvements, improved code navigation, open folder view, and connected services enable connections between your app and any service on-premises or in the cloud.
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-...
Could also have to do with the filesystem in newer versions of Windows (file operations seem slower in modern versions), the shell, background services and other characteristics of the OS.
I am very biased so don't listen to me lol, but I do think Windows 10 and the various developer tools release we've done over the last few years have really pushed things forward but of course we are very much listening to our community so please make your voice heard.
I haven't quantifiably measured the time that each operation takes, so I might be biased to some extent.
This looks very feature competitive with the "AWS Mobile Hub", even going beyond it with its CI app build integration with GitHub and device simulators!
Also, although they announced Amazon Pinpoint in December, there is still no support for it in their "beta" React Native Mobile SDK [0] (Which has had no commits in 5 months)
[0] https://docs.microsoft.com/en-us/mobile-center/sdk/getting-s...
https://channel9.msdn.com/Events/Visual-Studio/Visual-Studio...
(its by the product team)
That seems like a no-brainer if you are supporting React Native based apps.
Also, I didn't see any support for platform native Notification APIs for React Native. The current notification service is for pure-JS / Cordova[1]
CodePush will also be integrated into Mobile Center, so that you can also making CodePush a part of your CI process. We are also working on adding support for Authentication, storage, testing and Push notifications.
[I am the PM on CodePush and React Native Mobile Center stuff]
Do you have a general timeframe?
I'm going to be deciding between Azure Mobile Center and AWS Mobile Hub in the next couple months for a personal project.
I've had to resort to dropping MS domains at our exchange edge to stop receiving them.
Their Azure sales team are even worse - I've actually had to shout (repeatedly) at them to stop them from calling me, all because I wanted to try Azure AD as a test. They're on my permanent blacklist now, I won't even consider Azure because of the constant harassment over email and phone.
"We're a consultancy selling services for these tools/products."
or
"We're a competitor, and I registered for your free trial for competitive research."
In my case, these are true answers, but I never get more than one sales call from anyone.
I can't help you on the email front, but it's easy to set up filters for those.
I am getting an error with Dim p As (x As Integer, y As Integer) saying that I am missing a reference to 'System.Runtime.CompilerServices.TupleElementNamesAttribute' (but if tuples are part of the language why do I need an external reference? and this assembly doesn't seem to exist anyway). In fact right now a simple empty command line program containing nothing more than the below hangs the VS IDE completely...
Module Module1
Sub Main()
Dim p As (x As Integer, y As Integer)
End Sub
End ModuleFirst: The benefit of this approach is that people can now use this sort of feature down-level. i.e. you can interoperate with this code even if you're on a previous version of C# or VB. Also, it means that the libraries can be rev'ed independently of compiler and IDE releases. There's a lot of value in having this sort of thing. And in the past people would rightfully complain about the lockstep nature of wanting to adopt a language feature, but having to switch over an entire toolchain to do so.
Second: We actually do have a feature to help you out here. It's available in C# in RTM and will be in VB in the next update. If you enable: Tools | Options | Text Editor | (C#/VB) | Advanced | 'Suggest usings for types in NuGet packages'
then we'll offer to add the NuGet package for this for you when you use a tuple.
We'd like to eventually make this option on by default. However, there is a memory cost to it, and we'll need to win back that memory usage in some way so that we can abide by our commitment to VS using less memory and being more lightweight by default than previous versions.
My opinion is that simplicity matters a lot to the success of a platform. And by the way nothing in the error that you display when using tuples in VS2017 suggests a nuget package or an assembly name that can be searched.
Yes. This approach allows for far more interoperability in this space. Instead of having language features be locked into specific compilers/toolsets. You mentioned 'simplicity' and we've traded off one sort of simplicity for another. The approach you would like (which we used in the past) used to not be simple for the customer that wanted the scenarios to work that we're enabling now.
> Would you expect to have to go to a package manager to use tuples in python?
I could definitely expect that new language features might require library updates, yes.
> My opinion is that simplicity matters a lot to the success of a platform.
I think a lot of things matter to the success of a platform. For every developer who wants the type of simplicity you mention, there are developers who want other sorts of things to be simple.
> And by the way nothing in the error that you display when using tuples in VS2017 suggests a nuget package or an assembly name that can be searched.
Yes. We could certainly make this experience better, and that's on me. However, as i mentioned already, there were difficult constraints to balance. We're hoping that our work moving things Out-Of-Process will help make it so that we can just light up this scenario by default. Then, you'd get this error, and the lightbulb would be right there to fix it up.
However, like with all things in development, you can't always get everything you want complete for every release. In this case we did not feel like it was justified to hold back all the rest of great feature work and performance improvements in VS just because users would have to do one manual step with one language feature when working with C#. You are free to disagree with that assessment on our part. But we're always going to end up having to pick a set of things we don't think will make it into any given release, and it's quite likely that for any given release there will be some things that you'd want (and which would make things better) that won't make it.
A great benefit of the new VS is that it's now much simpler for us to ship updates very rapidly. Instead of needing to wait literally years for updates, we can patch things immediately and we can complete features and get them in the hands of users in a matter of weeks. In that regard, i'm ok if this one particular experience isn't perfect. We can improve things as we move forward and continue delivering better and better experiences.
Thanks!
The only thing we ever really adopted in C# that needed a new runtime version was Generics.
In order to compile on a build server do I need an updated toolchain?
All you really need is the new C# compiler. You can get that with VS2017, or standalone. But the programs produced by this compiler should be runnable on pretty much every runtime out there.
> It'll work with existing .net 4.5.x and 4.6.x projects?
Definitely.
> I tried tuples and VS complained
What was the complaint? in order to use Tuples, you need a reference to add the System.ValueTuple NuGet package as that's the type under-the-hood that packages up the tuple values so other people can consume them.
This is a nice approach because it means your APIs can use Tuples, while people using C# 6.0 and earlier can still use them. effectively.
> In order to compile on a build server do I need an updated toolchain?
If you use C# 7.0 features, then use. You always need the appropriate compiler to use the latest language features. But you shouldn't need to really 'upgrade' anything else if you don't want to. (You can, of course, if you do want to).
<Compile Include="**\*.cs" />
Details: https://blog.xamarin.com/better-apps-visual-studio-2017/
No isn't an answer to that question.
> Visual Studio for Mac will be our Mac IDE going forward and will grow in features, sure its past is Xamarin Studio but its future will have A LOT of investment so its worth checking out in Preview 4.
Is a good answer to that question.
OTOH, Microsoft is the one company I'd trust with refactoring a gordian knot if neccessary. Look what they're doing to the console subsystem, the windows system DLLs, the ~25 year old C compiler, and so on (granted, some are different teams, but still...).
Maybe they'll be able to salvage some cool parts (the extention API, Intellisense, ...) and make them modular or put them into VS code or Xamarin Studio. I don't know, they probably don't have a complete plan themselves :-).
part of the new project system that grew out of the ill-fated project.json is to make this a first-class experience, but again that's focusing on the .csproj, I have no idea if it applies to C++.
<ItemGroup>
<Content Include="**\*.h" />
<Content Include="**\*.cpp" />
</ItemGroup>
-eric PM, VC++ team
<ClCompile Include="**\*.cpp" />
I'm Cyrus, a developer on the C#/VB IDE team.
One of the areas we invested a lot in (and will continue working on) is moving a lot of our analysis and processing work out-of-process. It turns out this is a much effective way to get improved performance while taking advantage of the available RAM in the system.
There are several reasons why this is, and why it's a better solution for performance than just moving to 64bits. For one, moving to 64bits substantially increases the memory requirements to the system. For the C#/VB compiler/IDEs, it can easily double the amount of ram necessary, which can be a substantial burden on many systems. For another, when you are in a single process, you massively increase the pressure on the GC, which can lead to exacerbated GC-pauses (which are one of the single worst contributors to the IDE feeling slow or sluggish).
By moving out of proc, we can actually use less ram, have far less chance of hitting 32bit limits, and greatly improve perceived and actual latency of operations (as GCs can happen in one process without affecting the other).
We, and other teams have been using this approach with great success, and we expect to continue moving more in this direction with future updates and releases. For example, I'm doing work right now to get our indices for 'Navigate To', 'Find all References' and 'Add using' to be computed and queried outside of the main VS process. The results have been hugely successful, with the features actually running better than before, VS being even more responsive, and no excess memory usage (like we would get with 64bit).
There has been significant investigations of 64bit, and the actual empirical results of those investigations have driven our decisions. Thanks!
I'm a dev on the "IDE team" :)
We've actually done a huge amount of work investigating and addressing perf issues and working to create an architecture that can scale well. 64bits is not a panacea. And if we had simply moved to that, most people would find that their IDE was using much more ram AND behaving more sluggishly.
We decided to invest our energies in work that would actually benefit the vast majority of customers. This led to efforts that we were able to demonstrably measure as producing better experiences for people. If there's a point that 64bit will actually produce better results for people, we'll gladly move to it. Thanks!
But I also "know", and you also maybe secretly "know", that you will eventually move to 64-bits :P I completely don't know when, and I would completely understand that neither do you, and I would also understand that there is currently no immediate plan to move. But eventually you just will.
Now, ok, I'm not 100% sure about that. But my mind would be overly blown if this does not happen (given I don't have a clue of when, I guess I could have to wait for 20 years to see if my mind is blown or not :P ). I mean come on, even iPhone programs are 64-bits now.
(You know what this reminds me of a little bit?: Mozilla not working on a multiprocess architecture as a priority a while ago...)
It's not hypothetical :) We've measured, and moving to 64bits is a serious issue and would directly affect many customers who could not take the RAM hit.
> But I also "know", and you also maybe secretly "know", that you will eventually move to 64-bits
At some point we probably will. but it certainly isn't now. We have ample information on the types of machines that people use for development and we've measured extensively the different approaches that are possible. Right now 64bits would be a bad decision, and going the multi-process route turned out to be quite good.
> I mean come on, even iPhone programs are 64-bits now.
That's not a reason to move. We should move to 64bits if it delivers a quality improvement and does not dramatically degrade the experience for many customers. That's not what would be the case today.
> There seems to be some people in the IDE team who believe that a 32-bits only IDE is a feature and not a bug, including for reasons as fun as because it crashes sooner in case of memory leaks...
To be clear. There are zero people on the IDE that think this. The IDE team has to deal with the reality of the situation that there are humongous solutions, and very resource constrained machines. And we've been hearing from huge numbers of developers that they absolutely do not want memory requirements to go up. Just moving to 64bits is extremely problematic. As i've already mentioned that can easily double the memory requirements for many components in VS. That's going to make VS2017 a complete non-starter for many customers.
We do not haphazardly make changes "just because". We measure measure measure, and we're loathe to do anything that we've got enormous real data on on how negative the impact could be.
The approach we've taken has actually extremely improved throughput, scaling and latency, all while actually decreasing memory usage. We're going to continue making the changes that support those goals. If/when we can have a 64 bit architecture that supports those same needs, and gives an acceptable impact on the vast majority of user machines, then we can move there.