search

microsoft / vswhere

Locate Visual Studio 2017 and newer installations
MIT License
921 stars 97 forks source link

No output running in Docker #316

Closed Linux13524 closed 1 month ago

Linux13524 commented 1 month ago

Hi. I'm currently experiencing a strange behavior when running vswhere.exe in a Docker container.

My setup is the following:

Running ./vswhere.exe doesn't output anything, not even the copyright header. So my guess is that it crashes, but in that case, I'd expect an error output.

Now the bizarre part is that in the exact same Docker image on a different Windows host (server 2019) the ./vswhere.exe works as expected. So it is likely related to the host setup and not the image itself.

The question would be what can cause this? Maybe some missing dependencies on the host? What are the dependencies of vswhere? Can this really affect the vswhere inside the Docker container?

I'd be really happy to get some help investigating this :)

heaths commented 1 month ago

The image starts? My understanding from the Windows team is that Windows docker images have to be the same or previous (N or N-1) version of the kernel to be supported.

What vswhere command are you running? Formats other than text will never print a header.

Linux13524 commented 1 month ago

The image starts? My understanding from the Windows team is that Windows docker images have to be the same or previous (N or N-1) version of the kernel to be supported.

Yes, the image starts and runs fine to the point where vswhere is called. So the kernel of Windows Server 2019 and Windows 10 1809 seems to be the same or at least compatible..

What vswhere command are you running? Formats other than text will never print a header.

I am not running any command (for the sake of testing it), just ./vswhere.exe which prints this copyright stuff when running on the server 2019 host:

PS C:> cd '.\Program Files (x86)\Microsoft Visual Studio\Installer\' PS C:\Program Files (x86)\Microsoft Visual Studio\Installer> ./vswhere.exe Visual Studio Locator version 3.1.7+f39851e70f [query version 3.9.2148.60653] Copyright (C) Microsoft Corporation. All rights reserved.

On the Windows 10 1809 host, I get just nothing:

PS C:> cd '.\Program Files (x86)\Microsoft Visual Studio\Installer\' PS C:\Program Files (x86)\Microsoft Visual Studio\Installer> .\vswhere.exe PS C:\Program Files (x86)\Microsoft Visual Studio\Installer>

I can also add a command like -products * and get the same behavior on the Windows 10 1809.

Also, I need to add that in the past I had a Windows 10 1809 running where vswhere worked just fine in the Docker container, but I can't find out what the difference in setup might be..

heaths commented 1 month ago

What do you see if you run the vswhere command on the Windows 10 host itself?

Linux13524 commented 1 month ago

I installed visualstudio2022buildtools with Chocolatey on the host and vswhere seems to work fine:

PS C:\Program Files (x86)\Microsoft Visual Studio\Installer> .\vswhere.exe Visual Studio Locator version 3.1.7+f39851e70f [query version 3.9.2148.60653] Copyright (C) Microsoft Corporation. All rights reserved.

heaths commented 1 month ago

You'll probably need to run Process Monitor (procmon) in the container and export its log. I've never seen this reported or happen.

Linux13524 commented 1 month ago

While trying to install procmon with Chocolatey in the container I got a step closer: different steps in the installation processes throw errors, one of them being 7z.exe. It turns out it has the same behavior as vswhere, outputting nothing. Chocolatey gives also the return code for that: 3221225785 (C0000139 in hex).

So next I checked running vswhere from Python and got the same error code:

>>> import subprocess  
>>> result = subprocess.run("vswhere.exe", stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)  
>>> result.returncode  
3221225785

It seems the error code indicates some dependencies are missing. However, it cannot be dependencies inside the image as the exact same image runs on a different host.

I continue trying to install procmon and maybe something like dependency walker to find out what dependency might be missing.

heaths commented 1 month ago

The host kernel is used, so there could actually be missing dependencies. There was a time when Server Core didn't have a font server installed, so some apps wouldn't function correctly. Though that was fixed back then, it could've been regressed (the font server takes up a lot of space), or another system component could missing. Thinking about this more, I remembered righting a bunch of notes and warnings in https://learn.microsoft.com/visualstudio/install/build-tools-container about Server Core not being fully supported by the installer. Too much didn't work. You should use a more expansive edition like Standard. In fact, our system requirements specify Standard or Datacenter already: https://learn.microsoft.com/visualstudio/releases/2022/system-requirements#supported-operating-systems. Core isn't supported, but we don't block on it either because some workloads may work but, again, are not supported. Customers do so at their own risk. This is a case where too much is missing.

Based on https://learn.microsoft.com/dotnet/architecture/microservices/net-core-net-framework-containers/official-net-docker-images#during-development-and-build, to build .NET Framework applications you should use the larger SDK images. The runtime images on Server Core are better only to run applications since they have minimal dependencies. To make this easy, the .NET team added multi-stage builds to Docker years ago, as documented here: https://docs.docker.com/build/building/multi-stage/

Hope that helps.

Linux13524 commented 1 month ago

Thanks a lot for the explanation!

I have to say for me all those image combinations are a bit confusing. I think I used dotnet/framework/runtime:4.8-windowsservercore-ltsc2019 as it was the minimum needed to run Chocolatey and everything else then worked just fine, including Visual Studio.

to build .NET Framework applications you should use the larger SDK images.

Actually, we are only using the Visual C++ build tools workload, no .NET development.

I did now run the Process Monitor on the host which also shows the processes inside the container and actually it shows the vswhere is crashing. However, unfortunately, I cannot see why.

Here is the logfile: logfile.zip

Maybe you can help me find what dependency is missing? If not it is also fine, we already found out it is not directly related to vswhere.