| A few quick thoughts on the topic of ISOs, to give you all a little extra context. 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?