A while ago I've created a offline install layout for VS2017 Professional (Version 15.5) - this is the base for a couple of dev-hosts at work.
Now we want to upgrade to VS2017 - version 15.8 - so I've createad a 1:1 copy of the existing layout and ran
vs_Professional.exe --layout <path_to_layout>
which ran for a while and updated ?all? packages in the layout.
doing a clean install with this updated layout does work well, however - when using this layout to update one of the hosts that have version 15.5 installed the update procedure fails with exit code "1".
sidenote: VS actually states that it's now 15.8.4 - but it exits with an error code .. so ..?
the command I use for install/update is
(drop the "update" for the clean installation)
vs_Professional.exe update --passive --norestart --wait --productkey $productKey --nocache --noUpdateInstaller --noWeb
using collect.exe there is a state.errors.json file which states that a couple of packages are missing on the layout path...
NOTE: I need to have all required packages available in the offline layout - because some of the PCs do not have internet access (despite we've got the requirement that those vs-setups need to be identical...)
I've tried to reach out to Microsoft Support but didn't hear back from the till now. - anyone else having this issue / was able to solve it?
The update process of an MSFT Visual Studio offline layout seems to be rather buggy, yet there is at least 1 way which seems to work consistently:
always, always, always note the exact parameters you've used to create a offline layout! (all packages, included extras, language - the exact command line(s) you've used!
1: create a copy of the existing offline layout
You'll want to do that if you need to be able to keep using the old layout version for new installs, as Sara Liu pointed out in the comments of the original question. (installing a 'older version' of an updated layout is not supported.)
Also, in case something breaks during the update - you don't loose anything ;-)
2: update the duplicated offline layout
vs_Professional.exe --layout <path_to_layout>
after this finished you should be able to install the new VisualStudio version from this updated layout, yet upgrading a older version will probably fail.
To resolve this, MSFT gives you the
vs_Professional.exe --verify
vs_Professional.exe --fix
tools you can throw at your layout - but don't expect it to work - it never figured out what packages have been missing in my scenarios.
if you follow point 3, you'll also be able to upgrade existing installations.
3: create a new layout with the same parameters as the original one and copy the files over the updated layout
it's quite weird I know - but this has given me the missing packages for the upgrade scenario all the time. just don't forget to fix your ChannelManifest.json afterwards.
Related
When I save a golang file in visual studio code, it ends up being corrupted -- characters are removed, not in any pattern I have discerned. This has occurred at various times in the past, but has just now recurred. For details, see my bug report, "corrupting file when saving in visual studio code #49465"1.
In the meantime, what I can do until it's fixed? Perhaps I could return to an older version of gopls, but I don't know how to do that.
Any suggestions welcome. I'm stuck until I can successfully save and run my go programs.
Thanks!
Please try running the following command
GO111MODULE=on go get golang.org/x/tools/gopls#master golang.org/x/tools#master
or
GO111MODULE=on go get golang.org/x/tools/gopls#v0.3.2-pre1
In order to make progress on my project, I've downloaded the prior version of go. At least on Windows, the downgrade installs like any upgrade, including offering to remove the existing version.
And I backed up gopls to its previous version using the facilities of VS Code:
ctrl+shift+X to access extensions
right-click on Go
select Install Another Version
wait...wait...wait...
when the list of versions finally appears, select the one you want (I went back a month)
So, the underlying problem still exists, but I'm back in business. I hope these instructions can help someone else battling with the disappearing character bug.
I have an app that uses a VS 2015 installer project.
Our BONEHEAD vendor, ComponentOne, released a new version of several assemblies upon which my product depends.
Here's the rub:
Old DLL version: 4.1.20102...
New DLL Version: 4.0.20162...
The newer DLL at least have newer file dates than the older one.
Of course, the newer DLL fix real user problems brought about by the bugs in the C1 components since corrected.
While I can get to the correct DLL by having the end user fully uninstall the older version of my product and installing the newer version, this is unworkable because:
We have an auto-update function that phones home and checks for the latest patch and installs it to update prevoius version; and
Our customers are female, 60+ and cyberphobic.
The project already has the RemovePreviousVersions property set to true, and I was hoping that this did a complete uninstall silently. It does not; the six assemblies with the version error are not replaced. The DetectNewerInstalledVersion property is also set to true; I tried to install with False, and it has no effect.
I also tried to explicitly include all detected dependencies of the C1 assemblies and it has no effect.
Is there a way to force the install project to overwrite the assemblies as long as the file date is newer regardless of the wrongly-encoded version?
Edited to add the following:
I tried making a custom action to delete the offending assemblies before installing anything - it runs after the files are installed. :(
I tried InstallShield LE, only to find out that it could not discover the dependencies more than one level deep, and provided no convenient way to explicitly specify the dependencies. I also could find nothing that would let me say to overwrite the assemblies based on date or unconditionally.
Thanks for any help you can offer!
I found an effective workaround.
I already had RemovePreviousVersions set to true, so I changed the application's default folder by adding [ProductVersion] onto the end of the path.
What this accomplished was:
It deleted the old assemblies; and
It created the new assemblies in the new folder.
This solved the problem nicely. No setting REINSTALLMODE to amus; no brute force solutions.
I have a program which has several versions. In the last version I have a problem: when I'm trying to update previous version to new one, the installer of new version removes files from previous version, but don't installs new files.
Just installing works fine, but updating process has this problem.
What can be the reason of this problem ?
Upade: I'll try to describe more detail
I have VS project where I have a project of program and an installer of this project. Till present all were working fine, but after my last big update ,the installer start work incorrectly.
And another question:
How I can debug installation process ?
I dont know which program you have. Generally programs have problems because of multible versions, because programmers arrange this. For example ;
Lets consider Microsoft Framework. If you have 4.5 you cannot install 4.0, so that with similar idea you cannot update it.
Try to delete other versions and update them and install others. Or you can also stop services which you dont want to update.Then other one will be updated without any problem.
Everything worked fine before I branched my trunk, now this error list shows up in the branch and the trunk. Google search brought up a possible solution in the Nuget blog, which has different error messages than I do.
Asked Jeff Handley via twitter, he responded "nuget.exe update -self"
Works! Strange thing is that it was a complete refresh install of Windows 7 with a new copy of VS2010. And somehow I have Nuget 1.7. Ah well...
C:\Tfs\Products\Development\Project1\.nuget>nuget.exe update -self
Checking for updates from https://nuget.org/api/v2/.
Currently running NuGet.exe 1.7.30402.9028.
Updating NuGet.exe to 2.0.40000.
Update successful.
I am releasing a new version of my product (minor upgrade), which I'm planning to package as a patch. This is a Basic MSI project in InstallShield 2009.
The installer creates some shortcuts on the desktop and in the All Program menu, this shortcuts make a reference to the version number, e. gr. "My Product 7.3", "My Product 7.3.2".
The change in the name of the shortcut is causing that after the upgrade is finished, the system ends up with duplicated shortcuts, one for version 7.3 and a second for version 7.3.2.
I made some research on this and started using the RemoveFile table, this worked fine when I created my patch 7.3.1, but now in patch 7.3.2 it isn't working in some cases. Let me clarify this.
This scenario DOES work:
I install my product version 7.3 (full installer)
Run patch 7.3.1 (windows installer patch). Shortcut for 7.3 is deleted fine.
Run patch 7.3.2 (windows installer patch). Shortcut for 7.3.1 is deleted fine.
This scenario does NOT work:
I install my product version 7.3
(full installer)
Run patch 7.3.2
(windows installer patch). Shortcut
for 7.3 is NOT deleted.
Note: I have tested my 7.3.2 version by running the full installer instead of the patch, and it works fine. It performs the minor upgrade and removes the old shortcut.
In my 7.3.2 patch I've added both 7.3 and 7.3.1 as previous setups.
A verbose log doesn't seem to provide much information (or probably I'm not doing the right search).
The component associated to the records in the RemoveFile table is updated correctly which I can verify in the log:
MSI (s) (58:EC) [15:51:44:846]: Component: ProgramFiles; Installed: Local; Request: Local; Action: Local
I will appreciate any help that you may provide.
Thanks.
Juan Carlos
Check the patch installation works, if only 7.3 is inclided in previous setups.
Seems like the problem in this case was related to the fact that when I accidentally changed the source files when creating the patch. So the file table didn't match with the files that I was really shipping. This created some sort of conflict with the upgrade. I've repeated the scenario using always the correct files and it worked fine.