I have just installed VS 2017. Resharper for VS 2017 is not available ready yet, so I decided to at least install the Productivity Power Tools. It required 3 (three) restarts of Visual Studio to complete! In VS 2015 it took one restart.
I went to the “Tools->Extensions and Updates” menu and asked to install the Productivity Power Tools. The extension manager announced that the installation will run only after I close all Visual Studio windows. Well, so I did. Then a window with a progress bar appeared, named “VSIX installer”, that then asked me again whether I want to modify Visual Studio (did’t I just request it?). I said “modify”. Then it ran some very slow installer, that enumerated each individual power tool being installed, and paused on each tool for 10-15 seconds. The installer completed and quietly disappeared (or maybe it said it was done, I don’t remember). I invoked Visual Studio again, it showed me more progress bars on startup, and then announced that the installation is completed and it wants to restart again. Is it a cool thing or what?
Permalink
1) Visual Studio 2017 changed internal compiler (to Roslyn), so ReSharper probably would not work well with VS 2017.
2) At the first glance, Visual Studio 2017 has enough refactoring features that it seems to be good enough without ReSharper anyway.
3) VS 2017 is still pretty raw. For example, “Create Unit Test” feature is missing again:
https://github.com/Microsoft/vstest/issues/592
4) VS 2017 seems to be faster overall.
5) Our PostJobFree.com project did not require any changes in order to switch from VS 2013 to VS 2017.
So we may start using VS 2017 pretty soon, in spite of some issues.
Permalink
Denis, thanks for the input. If it’s “pretty raw”, I don’t think it should have been released. Microsoft took a sad habit of removing features that they could not/had difficulty to port to the next platform: e.g. Visual Studio macros were killed in VS 2012, and support for setup projects was killed either in VS 2013 or VS 2015.
Why do you think the change in the compiler will influence Resharper? Resharper does not really compile things, does it?
Permalink
> support for setup projects was killed either in VS 2013 or VS 2015
Is it for setup projects for Windows forms and Windows services?
I think you would be doing with your own deployment scripts anyway.
These interactive setups are very hard to maintain.
I wish I never had them as an option, because it was mostly waste of time.
Permalink
Yes, setup for desktop apps of any kind: WinForms, WPF, Windows Serices. In modern Windows you cannot do installs using EXE files or BATs: you must use the MSI format, or you will be in the world of pain, mostly around security and permissions. However, MSI by itself is also a world of pain, so you need a higher-level installer package on your side. Visual Studio used to provide one, but not anymore. What’s most annoying is the lack of backward compatibility: you invested time and money into a project, and now you cannot compile it with the new version of VS, at least not out of the box.
Permalink
1) Permissions could be setup by a PowerShell script, right?
2) PowerShell script diffs are much more readable than Windows Installer source code, right?
3) (1)+(2) means Windows Installer was loosing popularity.
4) Maintaining software project is expensive. Maintaining barely useful project that is loosing popularity – has little sense.
I understand that lack of backward compatibility could be frustrating. The good thing is that popular projects usually give enough motivation to the manufacturer to maintain them.
Permalink
> 1) Permissions could be setup by a PowerShell script, right?
I am talking about permissions of the install script itself: gaining UAC access, replacing system files, etc. Some things can only be done via “Trusted Installer” account, and thus require an MSI.
> (1)+(2) means Windows Installer was loosing popularity.
I am not sure how you measure “popularity”, but as far as I know installing anything commercial is usually done via a (signed) installer. Powershell scripts are fine for open source libraries installed by developers, or for very custom software with just a few users. Even open source projects like TortoiseGit have MSI installers.
Permalink
The goal of changing how extensions are installed was to batch install/remove actions. You didn’t have to restart after one.
Permalink
Well, I did not make it up. There were 3 restarts: one to start the installer, one after the installer was done, and then it ran an after-installer (or whatever it is called).
Repeating the process to verify is somewhat difficult, since Productivity Tools now installs multiple individual extensions that must be removed separately. If at some point I retry it on a fresh machine, I will keep better notes.
Permalink
> If it’s “pretty raw”, I don’t think it should have been released.
The core (such as support for C# 6) could be done pretty well and have important advantages for some teams.
Software is never really done, and with accelerating speed of change that “never done” state is getting more noticeable.
We may actually start using VS 2017 as soon as “Create Unit Test” feature would become available.
> Resharper does not really compile things, does it?
Actually ReSharper does compile code (at least partially) and have very heavy integration with Visual Studio core. That’s why it is so powerful.
But since Visual Studio core changed, it is hard for ReSharper to keep up.
But ReSharper has it’s own issue: their team is getting our of shape. It looks like best developers gradually quit and money hungry management took over.
You probably know that ReSharper’s licensing is in yearly subscriptions now.
Some ugly ReSharper bugs are not fixed for years (in multiple versions). E.g.: https://youtrack.jetbrains.com/issue/RSRP-337706
Permalink
If Microsoft cannot afford to release everything at once in a proper shape, they should break up the product, so you could use old IDE with the new compiler. This is not unthinkably complicated, it has been done before. Of course, releasing multiple interdependent components on different schedules may in turn lead to a DLL hell situation.
Software may never be really done, but customers pay real money for each particular version, so each version must be as self-contained as possible. “We did not have time to tie all lose ends, but decided to release it anyway” is a rather dangerous attitude.
Re Resharper decline: I did not really know… Now I do 🙂 I use free academic licence at home, which, I think, was always yearly, and at work it is paid by the employer, so I did not realize it was on subscription now. They are actually preparing a version for VS 2017 now, but it is in EAP (whatever it means, I guess some kind of Beta).
Permalink
> “We did not have time to tie all lose ends, but decided to release it anyway” is a rather dangerous attitude.
Yes, it is dangerous, but it solves important problem for Miscrosoft: they are getting feedback on what missing features and unfixed bugs are the most important for the real users.
Until product is released – very few customers use it, which means little feedback.
It is very important not to include features that are not in high demand, because every feature complicates codebase a lot and therefore is very expensive to maintain.
Visual Studio customers know it pretty well for ages.
Back in 2002 my team lead told me that only 1 year after VS Studio .Net release it will be ready for migrating real products into it. I understood his point, but did not fully believe him back then. I totally believe in that “1 year post-release maturity gap” now.
Permalink
> I totally believe in that “1 year post-release maturity gap” now
If everyone waits a year for a stable release, it effectively it just prolongs the Beta period. The only difference is that Beta is usually free.
Permalink
> They are actually preparing a version for VS 2017 now
Usually ReSharper was able to release new version by the time new version of Visual Studio was released (ReSharper team was working with Beta and Release Candidate versions of new Visual Studio).
But this time they were not able to release on time. Which is a telling sign.
Permalink
Different teams have different reliability requirements. Some some teams can jump on Beta version, others or Release candidates. Small, but cautions startups may switch almost immediately after release. Bigger organizations may switch 1 or even few years later, especially if they are in the middle of a big project.