_From @suphero on July 31, 2016 20:25_
Steps to Reproduce:
_Copied from original issue: Microsoft/vscode#9998_
@suphero are you still seeing this problem? If so, what version of the .NET CLI do you have installed? (please paste the output from dotnet --info)
I'm not @suphero but I'm subscribed since I have the same issue.
> dotnet --info
.NET Command Line Tools (1.0.0-preview2-003121)
Product Information:
Version: 1.0.0-preview2-003121
Commit SHA-1 hash: 1e9d529bc5
Runtime Environment:
OS Name: Mac OS X
OS Version: 10.11
OS Platform: Darwin
RID: osx.10.11-x64
Version 1.5.0-insider (1.5.0-insider) as of today.
@Tinche VSCode version or C# extension version is unlikely to matter, as this is a problem with the .NET CLI.
If you just create a hello world project, do you see the problem there too?
mkdir clitest
cd clitest
dotnet new
dotnet restore
> mkdir clitest
ttvrtkovic@Tins-iMac ~/pg> cd clitest/
ttvrtkovic@Tins-iMac ~/p/clitest> dotnet new
Unhandled Exception: System.TypeInitializationException: The type initializer for 'Crypto' threw an exception. ---> System.TypeInitializationException: The type initializer for 'CryptoInitializer' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'System.Security.Cryptography.Native': The specified module could not be found.
(Exception from HRESULT: 0x8007007E)
at Interop.CryptoInitializer.EnsureOpenSslInitialized()
at Interop.CryptoInitializer..cctor()
--- End of inner exception stack trace ---
at Interop.Crypto..cctor()
--- End of inner exception stack trace ---
at Interop.Crypto.GetRandomBytes(Byte* buf, Int32 num)
at System.IO.Path.GetCryptoRandomBytes(Byte* bytes, Int32 byteCount)
at System.IO.Path.GetRandomFileName()
at Microsoft.DotNet.InternalAbstractions.TemporaryDirectory..ctor()
at Microsoft.Extensions.EnvironmentAbstractions.DirectoryWrapper.CreateTemporaryDirectory()
at Microsoft.DotNet.Configurer.NuGetPackagesArchiver..ctor()
at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(INuGetCacheSentinel nugetCacheSentinel)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
at Microsoft.DotNet.Cli.Program.Main(String[] args)
fish: 'dotnet new' terminated by signal SIGABRT (Abort)
Leaving work for home now (= no Mac), so I won't be able to respond more until tomorrow :)
@Tinche, can you make sure OpenSsl is properly installed on the system? I usually see this exception when I forget to install OpenSsl on the box.
@gregg-miskelly I'm still seeing this problem. Here is my dotnet --info result:
.NET Command Line Tools (1.0.0-preview2-003121)
Product Information:
Version: 1.0.0-preview2-003121
Commit SHA-1 hash: 1e9d529bc5
Runtime Environment:
OS Name: Mac OS X
OS Version: 10.11
OS Platform: Darwin
RID: osx.10.11-x64
@caslan I installed openssl but I could not brew link openssl. Exception may be caused by link problem. Here is my brew link --force openssl result:
Warning: Refusing to link: openssl
Linking keg-only OpenSSL means you may end up linking against the insecure,
deprecated system version while using the headers from the Homebrew version.
Instead, pass the full include/library paths to your compiler e.g.:
-I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib
@suphero are you seeing a similar TypeInitializationException when you run through my steps from above?
@Tinche here is the CLI issue tracking this problem: https://github.com/dotnet/cli/issues/3964. It looks like https://www.microsoft.com/net/core#macos has now been updated with new instructions for linking openSSL.
@gregg-miskelly I tried the new instructions on microsoft.com but it didn't solved my issue. Then I executed the following script at this url and it solved the issue. Thank you for your support.
sudo install_name_tool -add_rpath /usr/local/opt/openssl/lib /usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Security.Cryptography.Native.dylib
@suphero I think you are going to find that while that work around will be enough to restore the debugger, and use dotnet from the command line, but it will NOT work for making the debugger or language service work as they will have their own copy of System.Security.Cryptography.Native.dylib. But, assuming you are trying to do .NET Core development, you can tell me if this is true or not.
@suphero what behavior did you see exactly? Ex: Did the symlinks get created successfully but then dotnet new still crashed? Or was it something else?
@bartonjs any idea why the symlink approach from microsoft.com didn't work for suphero?
@gregg-miskelly The only case I know of where they won't work is if DYLD_FALLBACK_LIBRARY_PATH has been set to something which doesn't include /usr/local/lib.
@gregg-miskelly after using microsoft's instruction, symlinks are created but dotnet new crashed. Then I executed the script above and brew installed mono. Now I can debug my simple app.

@suphero Thanks! Unfortunately, your debugger still isn't working quite correctly. You can tell because the call stack says '
Does your DYLD_FALLBACK_LIBRARY_PATH have /usr/local/lib on it?
BTW: In case we don't find a better work around, I think you could fix this with:
sudo install_name_tool -add_rpath /usr/local/opt/openssl/lib ~/.vscode/extensions/ms-vscode.csharp-1.3.0/coreclr-debug/debugAdapters/System.Security.Cryptography.Native.dylib
sudo install_name_tool -add_rpath /usr/local/opt/openssl/lib ~/.vscode/extensions/ms-vscode.csharp-1.3.0/out/.omnisharp-coreclr/System.Security.Cryptography.Native.dylib
@gregg-miskelly DYLD_FALLBACK_LIBRARY_PATH did not have /usr/local/lib on it, I just updated the path and executed extra scripts you sent. How can I check if debugger works correctly?
@suphero when you stop on that breakpoint you should see that the call stack has the correct name of the frame and you should see that the 'Variables' window will list 'args'
@suphero The expected value of that environment variable is to not be set. If you're going the route of explicitly setting it, you should include all of the "the interpreted value if it wasn't set" values, which is $(HOME)/lib:/usr/local/lib:/lib:/usr/lib
@gregg-miskelly I debugged again and now I can see the args variable in Variables window.

@bartonjs I updated the environment variable as the text you send.
Thank you for your support.
@suphero great to hear!
I am going to leave this bug open to track if we want to add more diagnostics.
The two "ln -s" commands from Microsoft solved my crash. So far. :)
Having this exact same issue over here. From reading the comments it's unclear if this has been resolved or what exactly do I need to do to fix it.
On Mac OSX El Capitan, latest Insiders 1.5.0 (as of today).
EDIT
Ok, followed instructions detailed here, and that fixed the crashed. The only thing not working for me still is code formatting.