Core: Mac OS: Unhandled Exception: System.TypeInitializationException

[onecentlin]

I installed .NET Core 1.0 official installer released yesterday using this pkg (https://go.microsoft.com/fwlink/?LinkID=809124).
dotnet-dev-osx-x64.1.0.0-preview2-003121.pkg

Version: 1.0.0-preview2-003121

[svick]

According to https://github.com/dotnet/cli/issues/1161, this happens when you don't have openssl installed. Did you follow the guide, especially the "Install pre-requisites" step?

[onecentlin]

Yes, I did have openssl installed.

It was working in 1.0.0.preview1-002702.

[~] $ openssl version
OpenSSL 0.9.8zh 14 Jan 2016

[~] $ which openssl
/usr/bin/openssl

[gguimaraesbr]

+1

[bartonjs]

@onecentlin @gguimaraesbr assuming you used Homebrew to install OpenSSL, it seems like you have only run one of the two commands.

If you run brew link --force openssl that should fix your problem.

The preview1 build could accidentally function without the link step, but we changed the library linking method for RTM (which is in the preview2 build of the sdk tools) to support loading copies from the current directory, which brought back the requirement of having symlinked the library into a system path.

The openssl tool version after that step should be 1.0.2(and a letter); 0.9.8 is not supported.

[onecentlin]

@bartonjs Thank you. This works!!
I did link openssl before while developing with RC2.

After executing the command, now it works perfectly.

$ brew link --force openssl
Linking /usr/local/Cellar/openssl/1.0.2h_1... 1601 symlinks created

[ascarter]

@onecentlin can you run which openssl? I followed the instructions for brew link but it still is using 0.9.8 (system openssl) for me. Curious to see what path yours has since it works.

[onecentlin]

@ascarter This is my openssl version and path.

$ openssl version
OpenSSL 1.0.2h  3 May 2016

$ which openssl
/usr/local/bin/openssl

[bartonjs]

@ascarter It's possible to have the /usr/bin/openssl version as a higher precedent in your path. The important part is whether libcrypto.1.0.0.dylib is on the library loader path. If you use Homebrew and brew link, then it'll be in /usr/local/lib/. $HOME/lib/ and /usr/lib/ are also acceptable locations (by default), (https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-SW21 for more information)

[mikeho]

Is there a particular reason why brew's version of OpenSSL is recommended (or required)?

I am using MacPorts for all of my package management, and I can confirm that I am using the latest version of OpenSSL:

$ which openssl
/opt/local/bin/openssl
$ openssl version
OpenSSL 1.0.2h  3 May 2016

The opt-releated paths are set up correctly in my PATH settings and show up first (which is the default approach for MacPorts).

Yet I'm getting the same error that others are reporting:
Unhandled Exception: System.TypeInitializationException: The type initializer for 'Crypto' threw an exception. ---> System.TypeInitializationException: The type initializer for 'CryptoInitializer' threw an exception...

Is the dotnet command line not able to utilize the PATH setting to locate the openssl files to use?

EDIT: I have also symlinked the macports version of libcrypto and libssl into /usr/local/lib, but I'm still getting the same error/issue.

[gguimaraesbr]

Thanks @bartonjs Symlinking the library did the trick.

[bartonjs]

@mikeho $PATH is only for execution, and the openssl utility isn't actually used. What we need is libcrypto.1.0.0.dylib and libssl.1.0.0.dylib; and they need to be in a standard rpath probing location, which is any of $HOME/lib, /usr/local/lib/, /usr/lib/, or the current directory.

Or you can try altering the DYLD_LIBRARY_PATH environment variable to include /opt/local/lib (which is where I assume MacPorts put it); but the Internet seems full of people who complain that DYLD_LIBRARY_PATH overrides aren't as successful as advertised on El Capitan.

Personally, I'd just add symlinks in /usr/local/lib to those two libraries wherever MacPorts put them (unless MacPorts has a command similar to brew link, which puts them in that path for you... then I'd run that).

[ascarter]

@bartonjs Thanks - I think you are exactly right. I install homebrew in /opt/homebrew to keep it isolated and I think that's precisely why I don't see the paths the same. I can make it work out.

[mikeho]

@bartonjs looks like our messages got crossed over the wire.

I actually did go ahead and symlink the macports version of libcrypto.1.0.0.dylib and libssl.1.0.0.dylib into /usr/local/lib, but I'm still getting the same error/issue.

[bartonjs]

@mikeho Intriguing. I don't suppose you can give me a primer on making my machine look like yours? (Like, how to get/use MacPorts, what options you've used (if applicable) and manual symlink commands you've done to try to remediate).

[mikeho]

@bartonjs never mind. I had actually used a non-version named file (libssl.dylib and libcrypto.dylib instead of libssl.1.0.0.dylib and libcrypto.1.0.0.dylib).

Adding the version numbers in the names fixed it.

Thanks for your help!

[bartonjs]

@mikeho Oh, good, I was concerned that the rules had somehow changed out from under me :smile:.

Glad it's working for you now!

[bartonjs]

Okay, by my re-scan everyone who has chimed in has attained success; so I'm going to give a quick closing summary and close the issue:

Resolution Summary

The dotnet utility (or, rather, the cryptographic subsystems within the framework libraries) requires libcrypto.1.0.0.dylib (and libssl.1.0.0.dylib) to be present in a standard rpath location, e.g. /usr/local/lib/.

Homebrew users using default paths

$ brew link --force openssl

The primary effect of this command is to create a symlink from /usr/local/lib/libcrypto.1.0.0.dylib to /usr/local/Cellar/openssl//lib/libcrypto.1.0.0.dylib (and similalry for libssl.1.0.0.dylib). It also links the openssl utility into /usr/local/bin, and creates other symlinks useful for building new libraries/applications against openssl.

Other users (MacPorts, DIY, non-standard paths from Homebrew)

You need to create versioned dylib symlinks from a standard library directory to wherever your installed copies are. For example:

ln -s /opt/local/lib/libcrypto.1.0.0.dylib /usr/local/lib/libcrypto.1.0.0.dylib
ln -s /opt/local/lib/libssl.1.0.0.dylib /usr/local/lib/libssl.1.0.0.dylib

Where the source path (/opt/local/lib/) may be different depending on your particular system and source of installation.

[joshka]

The stackoverflow / earlier version of openssl approach will cease working once you update brew (see https://github.com/Homebrew/brew/pull/612).
The following workaround worked for me on a hello world project:

export DYLD_LIBRARY_PATH=/usr/local/opt/openssl/lib
dotnet new

See https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-SW21 for info on how the library search process works on OS X.

[KushalP]

I just had this issue, despite having openssl installed and having run brew link --force openssl. I use boxen to manage my environment and it places the homebrew directory in a different location.

My environment

ᐅ 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

What I did to fix this error

I ran the following:

ln -s /opt/boxen/homebrew/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/
ln -s /opt/boxen/homebrew/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/

Could this be related to the dotnet tool not using the $PATH to pick up these libraries?

[joshka]

@KushalP - the brew link approach is deprecated as you've no doubt noticed.

Yes, dotnet does not use $PATH, but this is expected as the dynamic loader never uses $PATH to find libraries (see man dyld). Your fix is correct for your environment :)