Search code examples
visual-studioinstallationoffline

Validating an offline installation for Visual Studio (2019 or 2022) created with the --layout option

So my question is: how to validate/verify the layout for an offline situation while ensuring that no network connection will be necessary in the offline installation scenario (i.e. at least --noweb)?

NB: to be certain I also like to turn off network anyway while validating (from within a VM), but the idea behind --noweb appears to be that.

Background

I prefer to create an offline installation for Visual Studio, which combines the different editions in one .iso (UDF) file. It works generally nicely thanks to the duplication across editions which mkisofs can deduplicate via -duplicates-once; and packers will be able to achieve the same if they know how to handle hardlinks, after a treatment with hardlink or dfhl or similar tools. The resulting .iso for VS 2022 (17.3.6) for example is a mere 36 GiB in size, including the editions: Build Tools ("28 GiB"), Community ("35 GiB"), Professional ("35 GiB") and Enterprise ("35 GiB"). The hardlinking process saves a little over 100 GiB altogether.

Since I typically get at least a handful of of download errors during a single run, I tend to run the initial vs_<Edition>.exe --layout %CD%\vs2022\<Edition> --lang en-us command at least twice until I see the final success message. Twice is usually sufficient to get to see that.

However, now I would like to make sure that each individual layout is truly valid for offline installation. Alas, the help page isn't exactly helpful for the scenario and the command I came up with doesn't seem to do anything.

Executed from cmd.exe (no matter if elevated or not) and from within the directory specified in --layout during preparation:

.\vs_setup.exe --layout %CD% --verify --noweb --passive --lang en-us

NB: I also tried with --nocache, without --passive and without --lang en-us (the original layout was generated only for that language, so I assumed it has to be given).

In all cases I briefly see a dialog come up with a progress bar indicating that stuff gets loaded and unpacked into %LOCALAPPDATA%\Temp (makes sense given the read-only media), but then there is silence and the respective process appears to quit without doing anything. So I don't even get an indication of what I may have invoked incorrectly. I also checked the event log but returned empty-handed.

I am asking the question specifically for VS 2019 and 2022, but the bootstrappers seem to be largely unified anyway. So pick one of those versions to answer.

PS: Alternatively it would also help if you showed me how to turn up verbosity so that I can diagnose why the invoked program quietly quits.

Tried the following both while the network was connected and not; where X: was the mounted .iso file. All ended up failing silently without any indication of what's wrong as per the above description. No UAC elevation prompt appeared either.

  • X:\Professional\vs_setup.exe --layout X:\Professional --verify --noweb --lang en-us
  • X:\Enterprise\vs_setup.exe --layout X:\Enterprise --verify --noweb --lang en-us
  • X:\BuildTools\vs_setup.exe --layout X:\BuildTools --verify --noweb --lang en-us
  • X:\Community\vs_setup.exe --layout X:\Community --verify --noweb --lang en-us

I tried this on two different VMs, and also with an already elevated prompt as well as a normal prompt. The results were the same as described in the initial question for all combinations (i.e. editions, offline/online, elevated/not).

Solution

  • Found the underlying issue. As it so happens, mounting an .iso file means it gets mounted read-only. That seems to be the single defining factor here.

    Exhibit #1 (my scenario with read-only layout directory):

    Read-only layout directory, showing the silent "error"

    Yes, I could have left some more seconds or minutes of still image at the end, but take my word there is nothing happening there.

    Exhibit #2 (same contents but copied to a writable location)

    Read-write layout directory, showing what I would expect

    So to conclude: this appears to be a defect or - euphemistically - an undocumented design decision. It is beyond me why verification/validation of data would require more than read-only access, though.