Can't update C# dependencies and can't start omnisharp server after manually download dependencies

[birdinforest]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-1-003177)
Product Information:
 Version:            1.0.0-preview2-1-003177
 Commit SHA-1 hash:  a2df9c2576
Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

VS Code version:1.8.1
C# Extension version:1.6.2

Steps to reproduce

Install C# extension. Open VS Code. Open .Net core project.

Expected behavior

Update dependencies and start omnisharp server.

Actual behavior

C# output says:
Updating dependencies ...
Finish.

What I have try:

1.My computer is not under proxy. I turned off firewall and windows defender. Doesn't work.

2.Following issue #1028, I downloaded two packages, put them in correct subdirectory, and create file install.Lock. Open VS code, Omnisharp output:

  Starting omnisharp server. 
  Target <project name>

3. Run wmic os get osarchitecture. No data return. Maybe that is the reason.

[DustinCampbell]

It sounds like the problem is with wmic. What version of Windows are you running?

[birdinforest]

It is window 10, Version 1607(OS Build 14393.693).

Yes I think the problem is with wmic, however I can't figure any solution to fix it. Is there any way I can pass OS information to C# extension to make it work?

Thanks.

[DustinCampbell]

Is the problem that wmic is simply not on the path? Are you running a non-English version of Windows? For me, 'wmic' executes from %SystemRoot%\System32\Wbem

[birdinforest]

No it is a problem on the path. After I execute 'wmic.exe', the terminal does not enter WMI console mode but just get frozen.

[filipw]

@DustinCampbell as a fallback from checking wmic, how about checking if %PROGRAMFILES(x86)% env variable exists (it will only exist on 64 bit OS)

[birdinforest]

According to log of WMI Diagnosis Utility, there are two errors on WMI:

Although I don't know if it is caused by problems on WMI, I tried several way to reset WMI repository. No luck.

41011 22:12:33 (0) ** 1 error(s) 0x8004100E - (WBEM_E_INVALID_NAMESPACE) Namespace specified cannot be found
41012 22:12:33 (0) ** 
41013 22:12:33 (0) ** 2 error(s) 0x80041002 - (WBEM_E_NOT_FOUND) Object cannot be found
41014 22:12:33 (0) ** => This error is typically a WMI error. This WMI error is due to:
41015 22:12:33 (0) **    - a missing WMI class definition or object.
41016 22:12:33 (0) **      (See any GET, ENUMERATION, EXECQUERY and GET VALUE operation failures).
41017 22:12:33 (0) **      You can correct the missing class definitions by:
41018 22:12:33 (0) **      - Manually recompiling the MOF file(s) with the 'MOFCOMP <FileName.MOF>' command.
41019 22:12:33 (0) **      Note: You can build a list of classes in relation with their WMI provider and MOF file with WMIDiag.
41020 22:12:33 (0) **            (This list can be built on a similar and working WMI Windows installation)
41021 22:12:33 (0) **            The following command line must be used:
41022 22:12:33 (0) **            i.e. 'WMIDiag CorrelateClassAndProvider'
41023 22:12:33 (0) **    - a WMI repository corruption.
41024 22:12:33 (0) **      In such a case, you must rerun WMIDiag with 'WriteInRepository' parameter
41025 22:12:33 (0) **      to validate the WMI repository operations.
41026 22:12:33 (0) **    Note: ENSURE you are an administrator with FULL access to WMI EVERY namespaces of the computer before
41027 22:12:33 (0) **          executing the WriteInRepository command. To write temporary data from the Root namespace, use:
41028 22:12:33 (0) **          i.e. 'WMIDiag WriteInRepository=Root'
41029 22:12:33 (0) **    - If the WriteInRepository command fails, while being an Administrator with ALL accesses to ALL namespaces
41030 22:12:33 (0) **      the WMI repository must be reconstructed.
41031 22:12:33 (0) **    Note: The WMI repository reconstruction requires to locate all MOF files needed to rebuild the repository,
41032 22:12:33 (0) **          otherwise some applications may fail after the reconstruction.
41033 22:12:33 (0) **          This can be achieved with the following command:
41034 22:12:33 (0) **          i.e. 'WMIDiag ShowMOFErrors'
41035 22:12:33 (0) **    Note: The repository reconstruction must be a LAST RESORT solution and ONLY after executing
41036 22:12:33 (0) **          ALL fixes previously mentioned.
41037 22:12:33 (2) !! WARNING: Static information stored by external applications in the repository will be LOST! (i.e. SMS Inventory)

I will do some research on how to fix them and update here.

As filipw's suggestion, that will be great if it can use an additional way to check system information.

Thanks.

[gregg-miskelly]

I wonder if we could also just check the 'PROCESSOR_ARCHITECTURE' environment variable...

[DustinCampbell]

Actually, should we just use Node.js's os.arch()?

[DustinCampbell]

@gregg-miskelly: Wouldn't PROCESSOR_ARCHITECTURE and os.arch() both be problematic as VS Code is always 32-bit?

[gregg-miskelly]

@DustinCampbell We can use PROCESSOR_ARCHITEW6432 if PROCESSOR_ARCHITECTURE==x86. I would assuming you are correct about 'os.arch()'.

[DustinCampbell]

Yeah, I was just coding that up before I left for lunch. Now that I'm back, I'll finish. 😄