-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
visualstudio2017: if VS Installer needs upgrade, --wait does not work #7
Comments
--noUpdateInstaller |
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
…determination logic Logic extrapolated from Microsoft.VisualStudio.Setup.dll/Microsoft.VisualStudio.Setup.ChannelManager.EnsureEngineCanReadManifests(). EngineVersion := FileVersion of <VS Installer>\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\Microsoft.VisualStudio.Setup.dll EngineVersion is in catalog manifest ($manifest.engineVersion) installer version := resources\app\main\Main.js: var EXE_VERSION = require("../package.json").version; function createSetupEngineAdapter: // exeVersionForEngine is used to detect updates. During development, // checking for updates is undesired. Typically, a true release version // looks like "x.y.build.qfe", otherwise the version is "x.y.z". // Passing null for version skips checking for updates. var exeVersionParts = EXE_VERSION.split("."); var exeVersionForEngine = exeVersionParts.length > 3 ? EXE_VERSION : null; (this gets passed to Microsoft.VisualStudio.Setup.Service.dll/Microsoft.VisualStudio.Setup.ProductsProviderService.Initialize() and from that through ((Service)base).Initialize() -> Service.InitializeSharedFields() to ChannelManagerFactory and ChannelManager) so: <VS Installer>\resources\app\package.json -> version NOT <VS Installer>\vs_installer.version.json -> version! installer version is in channel manifest ($bootstrapper.version) ChannelManager.EnsureEngineCanReadManifests() compares engine versions and installer versions; both comparisons must be satisfied (greater or equal) GitHub-Issue: GH-7 GH-8 GH-10 GH-26
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
jberezanski
added a commit
that referenced
this issue
May 15, 2018
This may be useful when instaling a fresh instance of a VS product using a bootstrapper which installs a specific version of the product (e.g. the 15.0 bootstrappers available from MSDN). Note that because the 15.0 bootstrapper does not support --noUpdateInstaller, the package must be instructed not to pass this parameter to the bootstrapper, by additionally specifying --no-noUpdateInstaller. GitHub-Issue: GH-7 GH-8 GH-10 GH-26
jberezanski
added a commit
that referenced
this issue
May 15, 2018
…e of the bootstrapper Due to the way the VS Installer update feature of the VS setup bootstrapper (--update) is implemented, --update must be the last argument, otherwise the bootstrapper will assume it is in "roundtrip update" mode and will start the VS Installer once it is updated. The problem is that recent versions of the parent ("box") application (vs_<product>.exe) started appending an additional argument (--env) to the VS setup bootstrapper invocation, effectively breaking the --update feature. To add insult to injury, the --env argument is not used during the VS installer update. Fortunately, the box application is just a flavor of a self-extracting zip archive and can be unzipped using standard zip tools. So, the workaround is to unzip the box application and invoke the extracted VS setup bootstrapper, taking care to pass arguments in correct order. GitHub-Issue: GH-7 GH-8 GH-26
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When installing a new VS 2017 product package, if the VS Installer already exists on the machine but needs to be upgraded, the VS setup bootstrapper will invoke the upgrade process but will exit before the upgraded installer finishes, even invoked with --wait.
Until the VS setup bootstrapper is fixed, the install logic should probably look for additional VS installer processes spawned during the installation and wait for all of them to finish.
The text was updated successfully, but these errors were encountered: