Skip to content
This repository has been archived by the owner on Apr 20, 2023. It is now read-only.

[WIP] Installation scenarios for the CLI - spec #1482

Merged
merged 1 commit into from
Mar 3, 2016

Conversation

blackdwarf
Copy link

Add stuff and rename the file.

/cc @piotrpMSFT @krwq @brthor @Sridhar-MS

- All installers are signed properly
- Upgrades using the native installers Just Work(tm)
- All user facing materials point to the getting started page
- The user needs extra effort to install the "bleeding edge" bits

This comment was marked as spam.

This comment was marked as spam.

@krwq
Copy link
Member

krwq commented Feb 18, 2016

this is WIP, please do not merge yet

Channels also impact the NuGet packages. Based on the version of the package specified, the user may end up getting different channels. This is described in more details in [Nuget Packages section](#nuget-packages).

# Dependencies
.NET Core CLI is built on top of CoreFX and CoreCLR and as such its' dependencies set is defined by the platform that those two combine. Some of the install options provide an automatic way to install these dependencies, while other do not. However, it is important to note that the CLI bundle will **not carry those dependencies with it** in any case. This means that for those install options that do not support automatic

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

@TheRealPiotrP
Copy link

@mmitche Azure0211103841 is out of space.

@mmitche
Copy link
Member

mmitche commented Feb 19, 2016

@piotrpMSFT When you see this for machines starting with Azure, just log and delete the machine

@TheRealPiotrP
Copy link

@dotnet-bot test Ubuntu Debug Build please.

@TheRealPiotrP
Copy link

@dotnet-bot test Ubuntu Release Build please.

@TheRealPiotrP
Copy link

@mmitche fantastic!

@mmitche
Copy link
Member

mmitche commented Feb 19, 2016

@piotrpMSFT What's odd is that we did manage to run out of space. I wonder if there was a test run that really killed some disk space.

@TheRealPiotrP
Copy link

If we see it often, let's take a look at an instance machine.

@blackdwarf
Copy link
Author

@krwq can you please take a stab at the NuGet section? You can actually, I think, push to this branch as well. :)


# General principles

- All installers are signed properly

This comment was marked as spam.

This comment was marked as spam.

* Support for specifying the version
* Support for specfying the installation location
* Support specifying whether the debug package needs to be downloaded

This comment was marked as spam.

@blackdwarf
Copy link
Author

@piotrpMSFT new version is up.

|------------------------------- |----------------------------- |-------------- |----------------------------------------------------------------------------------------------------------------------------- |
| --channel | -Channel | "Production" | Which channel (i.e. "nightly", "preview", "production") to install from. |
| --version | -Version | Latest | Which version of CLI to install; you need to specify the version as 3-part version (i.e. 1.0.0-13232). Also it is possible to use "latest" and "lkg" to point to latest and latest known good build |
| --prefix | -InstallDir | ./dotnet | Path to where to install the CLI bundle. The directory is not created if it doesn't exist. |

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

@TheRealPiotrP
Copy link

Some additional feedback:

  • Latest should be global.json, then Latest
  • dotnet-install.ps1/sh for consistency
  • default install path: per-User

@blackdwarf
Copy link
Author

@piotrpMSFT the default install path is .dotnet in the place where the thing was invoked. Are you saying this should be .dotnet in $HOME?

@TheRealPiotrP
Copy link

@blackdwarf that's the idea. Any concerns?


| Channel | Branch | Debian feed | Debian package name | NuGet version | NuGet feed |
|------------ |----------- |------------- |--------------------- |--------------- |--------------------------------------- |
| Nightly | master | Development | dotnet-nightly | 1.0.0-dev-* | https://dotnet.myget.org/f/dotnet-cli |

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

@blackdwarf
Copy link
Author

@piotrpMSFT yep and no. Nothing against the overall idea, but would like the install.ps1 to use the proper Windows location for the folder rather than $env:HOME. This is %LocalAppData%.

@blackdwarf
Copy link
Author

@piotrpMSFT @krwq new version is up.

@blackdwarf
Copy link
Author

@piotrpMSFT actually, I really don't like the name dotnet-install. Would be better to reverse it and call it install-dotnet.

@blackdwarf
Copy link
Author

@dotnet-bot test Windows_NT Release Build please

@blackdwarf blackdwarf force-pushed the blackdwarf-patch-1 branch from 371445b to f329ae2 Compare March 2, 2016 06:06
Obtaining .NET CLI
==================

# Contents

This comment was marked as spam.

@blackdwarf blackdwarf force-pushed the blackdwarf-patch-1 branch from f329ae2 to 9057c03 Compare March 2, 2016 15:33
@blackdwarf blackdwarf force-pushed the blackdwarf-patch-1 branch from 9057c03 to fb10268 Compare March 3, 2016 01:27
blackdwarf pushed a commit that referenced this pull request Mar 3, 2016
[WIP] Installation scenarios for the CLI - spec
@blackdwarf blackdwarf merged commit 771f4ed into rel/1.0.0 Mar 3, 2016
@blackdwarf blackdwarf deleted the blackdwarf-patch-1 branch March 3, 2016 01:28
@leecow leecow removed the in progress label Mar 3, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants