dotnet tools cannot run on a vanilla Windows machine. It fails to load
Need to install C++ Redistributables(VS 2015) - https://www.microsoft.com/en-us/download/details.aspx?id=48145
@Sridhar-MS, can you sync with @gkhanna79 ? It seems we want to statically link these dependencies but the same issue likely exists in other places including the shared host.
@Sridhar-MS can you take a look at this and answer @piotrpMSFT question above? We will use dotnet/cli#506 to track what is the intended experience for installing for Beta timeframe.
Which specific tools need these, aside from the shared host?
CC @schellap
@schellap Are you still planning to static link corehost?
@Sridhar-MS Native compilation cannot be supported on a vanilla machine as it requires VS 2015 with C++ support to be installed. And once that is done, all required dependencies will be in place.
Are you suggesting that we intend to support a scenario (vanilla windows mchine) where native compilation is not going to be supported?
With the above said, static linking puts the servicing burden onto us incase there are security issues in the CRT. Do we really want to go that route? We do not static link CRT on Ubuntu or Mac.
I would like to +1 this as this became a huge headache trying to start using dotnet.exe on our build servers, which are running Windows Server 2012 RC2 without the 140 version of CRT on the box.
In case it is useful we needed up needing to deploy the following assemblies locally to run this on a machine without a global 140 CRT.
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
concrt140.dll
msvcp140.dll
ucrtbase.dll
vcruntime140.dll
I just built CLI repo master and corehost.exe that is produced on Windows does not have any MSVCRT import (which does not seem right). @weshaggard Did you get the list above from dumpbin?
I looked at https://github.com/dotnet/cli/blob/master/src/corehost/cli/CMakeLists.txt - it is already statically linking the CRT into the host as "/MT" is specified (for both Release and Debug builds).
@weshaggard and @Sridhar-MS Please share more details of what is not working. Clearly, corehost is linking CRT statically so that cannot be it.
@Sridhar-MS Sent this back your way since there is nothing actionable from the host side as it already links CRT statically (see the master branch). If you think the host has issues pertaining to CRT, please share more details.
Corehost statically links the CRT libs. But coreclr does not do that. Here is the dumpbin output of coreclr.dll
C:Program Files (x86)Microsoft Visual Studio 14.0>dumpbin /DEPENDENTS C:UserssridhperDownloadsdotnet-win-x64.latestbincoreclr.dll
Microsoft (R) COFF/PE Dumper Version 14.00.23026.0
Copyright (C) Microsoft Corporation. All rights reserved.Dump of file C:UserssridhperDownloadsdotnet-win-x64.latestbincoreclr.dll
File Type: DLL
Image has the following dependencies:
msvcrt.dll
api-ms-win-core-winrt-l1-1-0.dll
api-ms-win-core-winrt-string-l1-1-0.dll
api-ms-win-ro-typeresolution-l1-1-0.dll
api-ms-win-core-winrt-roparameterizediid-l1-1-0.dll
bcrypt.dll
CRYPTSP.dll
OLEAUT32.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-eventing-provider-l1-1-0.dll
api-ms-win-security-base-l1-1-0.dll
api-ms-win-core-heap-obsolete-l1-1-0.dll
api-ms-win-core-registry-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-com-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-com-private-l1-1-0.dll
api-ms-win-core-kernel32-legacy-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-1.dll
api-ms-win-core-memory-l1-1-1.dll
api-ms-win-core-threadpool-l1-2-0.dll
api-ms-win-core-io-l1-1-0.dll
api-ms-win-core-string-obsolete-l1-1-0.dll
api-ms-win-core-version-l1-1-0.dll
api-ms-win-core-console-l2-1-0.dll
api-ms-win-eventlog-legacy-l1-1-0.dll
api-ms-win-core-localization-obsolete-l1-2-0.dll
api-ms-win-core-localization-l2-1-0.dll
api-ms-win-core-localization-l1-2-1.dll
api-ms-win-core-sysinfo-l1-2-0.dll
api-ms-win-core-kernel32-legacy-l1-1-1.dll
api-ms-win-core-stringloader-l1-1-1.dll
CRYPT32.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-shlwapi-legacy-l1-1-0.dllSummary
1000 .CLR_UEF
14000 .data
29000 .pdata
133000 .rdata
8000 .reloc
1000 .rsrc
437000 .text
1000 .tls
I am able to run the dotnet CLI tools on a vanilla Windows 10 machine. The coreclr is dynamically linked against Windows CRT library msvcrt.dll which can be found in c:windowssystem32.
@weshaggard It seems like @schellap had recently(6 days ago) made the change to statically link the CRT libs. Can you give it a try with the latest dotnet CLI bits?
@gkhanna79 and @Sridhar-MS, thanks for confirming corehost works, I spun off a VM to verify but couldn't get to it last night. The api* is the tell, the host doesn't need these files.
Note I made the change to include the CRT in the corehost but not coreclr.
I was running this and seeing the missing dependencies and also ran depends.exe to see them. However that was an older version (https://github.com/dotnet/cli/commit/91acc03a137c4dd6d44ca17aa7ce2078824cc672). I just checked a more recent one and I also can confirm that this looks like it is correctly statically linked now. Thanks.
The clihost doesn't have its own version of the CRT so that needs to be fixed.
@schellap Please fix it before EOW.
Fixed in dotnet/cli#835
I have just hit this error (screenshot below) on a clean Windows 2012 Server (no dotnet cli tools installed etc) so I guess its not fixed?
Any ideas on how to get my self contained app to run?

/cc @schellap @gkhanna79
You need to have VC++ 2015 redist installed on the machine. See https://docs.microsoft.com/en-us/dotnet/articles/core/windows-prerequisites.
Sent a PR to the docs as it doesn't mention stand alone .netcore apps however seeing as this issue was closed saying its been fixed but the title of this issue is Visual C++ Redistributable(VS 2015) is required to run dotnet tools on Windows I would say this is misleading seeing as you now say Visual C++ is still required!
Also those Visual C++ links on the prerequisites page are for Win 10 or Win 7+, what about Windows Server operating systems?
Also that page is titled Prerequisites for Windows development I'm not trying to develop, I'm trying to run a self contained app on Windows Server 2012, are the pre-requisites still valid and if so maybe the title of the page should be tweaked?
VC++ redist is the same, independent of the OS. It will be great if your PR to the docs make the phrasing fixes :)
Thank you for doing so!
Happy to update the docs but I need to clarify things as I'm still confused.
Every OS needs this https://www.microsoft.com/en-us/download/details.aspx?id=48145 ?
But Windows 7 & 8 (what about server 2008/2012/2016) needs the hotfix and the universal CRT?
Universal CRT will be part of the VC++ 2015 redist installation and thus, will get installed on all platforms.
The Hotfix is only required for Win7 and WinServer 2008 as called out on the Hotfix's page (https://support.microsoft.com/en-us/kb/2533623).
OK so deffo need to address those docs then as I think they are a bit misleading
@jchannon the topic on deployment when talking about self-contained deployment contains the following:
Self-contained deployments (SCD)
For a self-contained deployment, you deploy not only your app and any third-party dependencies, but the version of .NET Core that you build your app with. Creating an SCD does not, however, include the native dependencies of .NET Core itself on various platforms (for example, OpenSSL on macOS) so these need to be installed before running the application.
Taken from https://docs.microsoft.com/en-us/dotnet/articles/core/deploying/#self-contained-deployments-scd.
It is pretty clear that you need native dependencies, of which CRT is one. Do you think that the wording needs to be better?
This issue is misleading, because when you follow the links it makes it seem like the CRT is statically compiled, which is not true.
@blackdwarf I think this needs changing https://github.com/dotnet/core/blob/master/Documentation/prereqs.md
It says the only requirement you need on Windows is Visual C++ then mentions Win10 and Pre-Win10 which from what I can tell via @gkhanna79 Pre-Win10 is actually only relevant to Win7 and 2008 only. Then says about a manual install only if you are running the installer script. For self contained apps point of view this makes no sense at all. Things need to be made more clear IMO 😄
@jchannon ah, that, ok. :) Feel free to PR a change. :)
Ignore, just saw you already did. :)
I think my PR changes a different file but they have very similar content??
On Wed, 4 Jan 2017 at 18:37, Zlatko Knezevic notifications@github.com
wrote:
@jchannon https://github.com/jchannon ah, that, ok. :) Feel free to PR
a change. :)—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/195#issuecomment-270449131, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGaph-RS2OZvF46_AA9PzSN9-1eXl_Rks5rO-bQgaJpZM4GiRUA
.
@blackdwarf sent a PR for the pre reqs you linked https://github.com/dotnet/core/pull/416
@jchannon saw it, thanks! :)
Most helpful comment
I would like to +1 this as this became a huge headache trying to start using dotnet.exe on our build servers, which are running Windows Server 2012 RC2 without the 140 version of CRT on the box.
In case it is useful we needed up needing to deploy the following assemblies locally to run this on a machine without a global 140 CRT.