Currently failing to build unless the latest openssl binaries are used with brew link --force openssl with:

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)
/private/tmp/dotnet-20160807-11838-1cf1ilq/cli-1.0.0-preview2/build_projects/dotnet-cli-build/build.sh: line 117: 11982 Abort trap: 6           dotnet restore

Then failing with:

                        Error: Empty installation

Which I suppose is because it places stuff in a special folder. What's the incantation to tell it to fetch all things from stage2, into the cellar folder? (TODO in code)

Ref https://github.com/dotnet/cli/issues/3964#issuecomment-236832511

Added two TODOs I need help with.

@dunn Excellent, thanks for that hint. So then it's only this TODO left before this may even work in some manner: # TODO: how do I tell homebrew that the folders are under stage2?

how do I tell homebrew that the folders are under stage2?

Sorry, I'm not sure what you mean. Which folders, and what needs to be done to them?

@dunn Normally it would output stuff to prefix, but not this project. Instead it outputs to buildpath/"artifacts/osx.#{MacOS.version}-x64/stage2"; so I want that stuff into the folder (prefix plus something?) where the 'final product' ends up.

Compile steps should always leave the build product in the temporary directory buildpath. For projects with configure scripts we pass --prefix=#{prefix} so that make install knows where to move things to; our std_cmake_args does something similar for CMake projects.

TL;DR nothing is ever automatically installed into prefix, so you're doing the right thing by doing it manually.

@dunn is this what you're thinking of?

The current state, when moving dotnet to bin and then using it, will throw this exception:

dotnet
Failed to load , error: dlopen(, 1): no suitable image found.  Did find:
    /usr/local/lib/: not a file
    /usr/lib/: not a file
    /usr/local/lib/: not a file
    /usr/lib/: not a file
    /usr/local/lib/: not a file
    /usr/lib/: not a file

Because it's looking to a sibling folder, but not finding it.

Instead

prefix.install Dir["#{stage2}/*"]

And nothing else makes it work as intended. I'm not much into how native dylibs load, so perhaps someone could enlighten me as to how it would work with libexec etc, instead of sibling folders?

I'm going to fix the git checkout like @MikeMcQuaid wanted, but this PR is starting to get ready besides this particular change request.

In summary: how do I make the dylibs/loading work when the dotnet binary (perhaps) need to be in the root?

I'll look at this more closely when I can, but if installing the libraries directly into prefix is required for it to work, that's OK.

I'll look at this more closely when I can, but if installing the libraries directly into prefix is required for it to work, that's OK.

Agreed as long as audit is passing.

In summary: how do I make the dylibs/loading work when the dotnet binary (perhaps) need to be in the root?

You probably need to ask upstream that question as it's not really a Homebrew one.

@MikeMcQuaid I'm really just asking for a link to where I can understand how the loading works on OS X with binary vs dependent library; not particularly asking for netcore.

Please tell me what you want changed by pointing me in the direction of the documentation that documents the APIs you want to use. You say git reference; where are those docs?

Passing on this until we have a stable version that builds without patching and passes brew audit.

Wow. What a dude you are Mike.

@haf We're doing our best to run this project effectively.

@MikeMcQuaid I ask for help, you close the issue. And the lint has been passing many times over and its version is RTM, so you should not close it. You should focus on running the project productively instead, and that means taking into account lead times on change requests you make of me. If you think I've dropped this PR, then you're mistaken.

A list of what needs addressed before we can include this:

• The version may be RTM but it's mislabeled. Upstream should fix this before we include it.
• "I'm really just asking for a link to where I can understand how the loading works on OS X with binary vs dependent library; not particularly asking for netcore." this isn't something we can really help you with as I don't understand the question and doubt if I did I'd be able to provide you with the information you need to fix this.
• We usually don't accept new formulae that need patching to build
• This is how you use a git checkout: http://www.rubydoc.info/github/Homebrew/brew/master/Formula.url
• Our CI was still failing
• This should pass all the things you checked in the original checkbox

wrt dynamic linkage discovery, you're probably looking the bottom of man dyld, the top of man ld, and man install_name_tool. The punchline is that OS X's linker remembers the install_name of the dylibs to which it is linked and expects those to be absolute paths, possibly including special prefixes like @rpath.

1. Upstream has segregated the runtime called CoreCLR from the cli tools, and the cli tools compose your app in-place with the runtime. However, it does sound strange, I agree; that Microsoft has labelled preview2 of the cli tools as the RTM release of .Net Core, but there it is.
2. @tdsmith thanks, that was the info I was looking for before and the link to the example means I can update this PR to match it (if you'll please reopen it)
3. Well, we discussed that and agreed we could use git checkouts higher up in the thread, as the only reason for patching was that it builds the git checkout number into the version number.
5. CI has been green, but since you prefer rebased PRs it's been turned red again. However, now it's gone so I can't see what it failed with any longer.
6. And it did, and this PR is a living thing that changes as you come with feedback.

I'm looking forward to continuing this PR when it's open again.

@haf did you find a workaround for the openssl-formula-must-be-linked problem?

@ilovezfs Yes, that's now part of the PR and works really nicely!

/cc @blackdwarf for feedback/help about this pr

@BrewTestBot test this please

I reopened this 10 days ago and there's been no movement since then and CI is failing in a way that's trivially reproducible by running brew install dotnet or brew audit dotnet --new-formula on any of the 3 most recent OS X versions. Please resubmit this PR when both of those are passing, you are using a tag/release that doesn't have preview in the name and it does not require any patching to function and, ideally, no install_name_tool calls. This will very likely require working with upstream and may require another stable release from them.

To preempt some responses:

• you are not being held to a higher standard than any other pull-request. If anything we've provided considerably more help than we normally would
• it's disappointing to be personally criticised for closing this pull-request, reopen it and see no progress on e.g. using a git checkout which was a problem before this PR was closing and remains unaddressed.
• these PR and formula quality standards come from running this package manager for a fairly long time. They are not personal and not a criticism of anyone but they set a bar that we need to keep maintenance time at sustainable levels and quality at an acceptable level for our users.