Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installer unhelpful & homebrew missing #654

Closed
3 tasks
haf opened this issue May 14, 2017 · 15 comments
Closed
3 tasks

Installer unhelpful & homebrew missing #654

haf opened this issue May 14, 2017 · 15 comments

Comments

@haf
Copy link

haf commented May 14, 2017

See https://github.com/dotnet/cli/issues/533 and 52#issuecomment-281059359 – the installer of 1.0.4 doesn't tell me where it places binaries and dotnet --version doesn't change after upgrading with the 1.0.4 installer (from 1.0.1).

  • Fix homebrew
  • Make the installer tell the user where it puts/changes files
  • Provide upgrade instructions on OS X/macOS
@leecow
Copy link
Member

leecow commented May 15, 2017

@haf The macOS installer places .NET Core files in /usr/local/share/. We're working on polishing up the installer experience for 2.0.

Because .NET Core installs side-by-side so there's not a true 'upgrade'. Running the new version of an installer (the pkg, not the tar.gz) will place files into versioned directories under the component directories in /usr/local/share/dotnet.

What are you experiencing with homebrew? The only thing that should be used for is installing OpenSSL. Step-by-step instructions as well as a video can be seen at https://www.microsoft.com/net/core#macos.

@haf
Copy link
Author

haf commented May 16, 2017

@leecow I believe it places it not there, but in a subfolder there. Since I had /usr/local/share/dotnet/ the installer didn't work. It could pretty easily check where my dotnet binary is.

The problem is that you don't have a homebrew installer, marginalising dotnet's uptake in comparison to other languages and forcing the user to do an ungodly openssl symlink themselves without even briefly discussing why that symlink might not already be there and how it can affect programmers who compile native software themselves (making the install experience a bit YOLO.)

@karelz
Copy link
Member

karelz commented May 16, 2017

@haf note that we removed our dependency on OpenSSL on Mac in .NET Core 2.0 and replaced it with using Mac crypto. If you want, you can try out .NET Core 2.0 Preview1.

@haf
Copy link
Author

haf commented May 16, 2017

@karelz How's F# for 2.0?

@karelz
Copy link
Member

karelz commented May 16, 2017

@haf unrelated to this question ... but @cartermp can comment.

@haf
Copy link
Author

haf commented May 16, 2017

It's related if I'm going to try to release my F# packages with it, isn't it?

@cartermp
Copy link
Contributor

cartermp commented May 16, 2017

@haf F# support for 2.0 will be in Preview 2 of .NET Core 2.0.

...or whichever release aligns with 15.3 Preview 2 (this is jargon for @karelz). Karel, is .NET Core 2.0 Preview 2 going to align with 15.3 Preview 2?

@leecow
Copy link
Member

leecow commented May 16, 2017

@haf - got a bit caught up on the desire for a Homebrew formula. Still a possibility but nobody is looking at it right now. I understand that bringing in OpenSSL for 1.0/1.1 is not a great experience and, as @karelz points out, this has been remedied for 2.0.

I haven't seen our installer fail just because /usr/local/share/dotnet/ is present so I'm interested to understand more. As I mentioned earlier, .NET Core components install side-by-side so there could be any number of versioned directories under /usr/local/share/dotnet/sdk, for example. There is only a single dotnet.exe at the root of the dotnet director structure and this should updated with each install.

@karelz
Copy link
Member

karelz commented May 17, 2017

@cartermp no idea which VS update it will align with. @leecow will know more about VS updates aligning with .NET Core 2.0 Preview 2.

@leecow
Copy link
Member

leecow commented May 17, 2017

At these time, there is no alignment between a VS update and .NET Core Preview 2.

@haf
Copy link
Author

haf commented May 18, 2017

@leecow I didn't get my dotnet executable overwritten by the installer; I had to manually download the binaries and overwrite.

~~

I've found dotnet/fsharp#3069 but it only talks in terms of Visual Studio, so that's not relevant to me or anyone on linux or anyone on Mac – can't you use semver? What's v15????

It would be great if you had a homebrew installer for .Net Core v2 and F# – it would show the world you care about cross-platform development.

@cartermp
Copy link
Contributor

@haf 15 is the 15th version of Visual Studio, which is entitled Visual Studio 2017. Note that the issue is entitled "Visual F# Tools Announcement", and not "F# Announcement". The Visual F# Tools are on the VS update cycle. The .NET Core release cycle has no alignment with the VS update cycle, as @leecow stated.

What this means for you is that in Q3 this year, .NET Core 2.0 will be released. F# will be in it and working. It already works today on unreleased .NET Core 2.0 bits.

@haf
Copy link
Author

haf commented May 18, 2017

@cartermp Thank you for the clarification.

@leecow
Copy link
Member

leecow commented May 18, 2017

@haf - I would like to understand the installer issue (homebrew is a separate matter) so I can attempt to reproduce the behavior. Can you accurately, and in detail, describe how you had installed .NET Core previously and how you initially attempted to install the update before resorting to manually overwriting? What versions did you have installed at the time of the attempted update? /usr/local/share/dotnet/shared/Microsoft.NETCore.App/ will show the versioned directories (semver fwiw).

@Petermarcu
Copy link
Member

Looks like this thread has concluded. I'm going to close it now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants