Moves CLI version suffix from preview1 to preview2
Sets channel for preview2 to 1.0.0-preview2, abandoning the Beta channel to the 1.0.0-preview1 release. Once @sokket's publishing cleanup work is complete we can re-converge the channels if desired.
Refactor HostVersion into its own class and use it everywhere host
artifacts are created. This includes the
- host nuget packages
- host installers (msi, pkg, deb)
Earlier the host MSI dependency key changed for every version. Therefore
the following stesp uninstalled host aggresively.
- Install a older dotnet CLI bundle (say v1)
- Install a newer dotnet CLI bundle (say v2)
- Uninstall the newer CLI bundle. This removes the host completely and
leaves the older version v1 unusable.
With this fix all the versions of the CLI in the machine will reference
count the host correctly.
Fixes - #2713
Remove code to find the previous install folder, always install into
%ProgramW6432%. Also remove the option to allow DOTNETHOME to be
overridable.
Fixes - #2743
In the MSI we used to check for any previous installation and we prevent any
installation of 'Release' version on top of 'Nightly' version and vice
versa. This is no longer needed since CLI SxS now. This is reminiscent of
pre-sharedFx CLI.
Fixes - #2467
- Make CLI SDK MSI non-upgradable. It must alwasy be installed SxS.
- The CLI bundle and SharedFx bundle are non-upgradeable.They are also
installed SxS.
- Make host\muxer upgradeable. It will be upgradeable till v1.0.0 RTM.
Post RTM will be installed SxS with v.1.0.0.
- SharedFx MSI was using the CLI MSI version. Fixing it to use the
SharedFx version.
- Do not allow bundles to uninstall. User will be able to uninstall the
individual MSIs.
- Changes to build scripts to produce Winx86 build artifacts like
zip/installer.
- Change to run Nuget-xplat in the same process as dotnet.exe instead of
spinning up a new 'corerun' process.
DOTNET_HOME is no longer required, though it is a documented override, so this change removes all unnecessary references to DOTNET_HOME from the CLI Repo.
The dotnet/cli is a very self contained installation package primarily
composed of files. Thus system restore adds little value and costing
only files is sufficient to verify disk space. The result is a 20%
install time reduction, ~2 seconds, on my machine where system restore
is disabled. The win is *much* larger where system restore is still on
(the default).
Increasing the compression from "mszip" (which is notoriously out of
date) to "high" reduces the package size by 17% with no appreciable
change in build or install time. In other words, this is a free 8 MB
savings off the download size/time.
A typical LaunchCondition should not block the user from removing a
package. LaunchConditions should also not prevent repair from fixing
the machine state, especially if the machine state needs to be repaired
for the LaunchCondition to evaluate. To avoid both problems the
condition was updated such that once installed the package can always
be repaired and uninstalled.
Type 51 custom actions, SetProperty, are mostly benign but if possible
custom actions should be avoided at all costs. Here we centralize the
build type check in a single location and use preprocessor variable to
remove the need for the custom action.
All resources should be installed by one and only one Component, where
Component is defined by the Component/@Guid. The SetupRegistry_x64 and
SetupRegistry_x86 Components were sharing the env vars across the 32-bit
and 64-bit packages. That is a Component Rule violation.
The fix is simple. Since the 32-bit registration is always required, let
it handle the env var installation. The code is cleaner as well.
The dotnet installer writes content under %ProgramFiles% which is
machine-wide and requires elevation. The Package@InstallScope attribute
must be set to perMachine in this case and will ensure that the Burn
bootstrapper prompts for elevation during install.
Set a new registry 'BuildType' when installing. Check for this reg key
when upgrading to a newer version. Show error message and exit
if the previous installation does not have the same 'BuildType'.
Encode the CLI version into MSI supported ProductVersion documented here -
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370859(v=vs.85).aspx
Example: CLI Version - 1.0.0.000930 is encoded in MSI as 4.0.930
Prevent downgrading by failing installation with error message.
Also display the original CLI version in the ProductName.
Decompose into self-contained granular components
Provide reasonable defaults for cross cutting concerns, allowing for independent execution of steps
Start unifying Windows/Bash architecture
fix Bash CI scripts
dockerbuild.sh _common.sh path
Add missing restore-packages.sh
Copy/paste issues
Quote $SOURCE
fix .gitignore
PR Feedback
Merge in @SridarMS's work to avoid redownloading DNX
enabling build of dotnet-build
merge in @SridharMS's CentOS changes
Enable building FSC
enable restoring specific subdirectories
Fix dnx version check
Add missed dependency
Fix pathing to tests
Match Linux build version to Windows, fixing linux tests as a side effect.
workaround for coreclr#2215
fix pathing issue
disable building in docker
BUILD_IN_DOCKER was set, somehow...
fix headers
- Needs a clean machine without dotnet MSI installed for the tests to run.
- Needs admin privileges to run. Else test script exits silently.
- These xunit based tests run on Netfx46.
For now these tests are disabled until I figure out the right way to run
them in the CI machines.
Install path is now %ProgramFiles%\dotnet
Registry root is now "HKLM\SOFTWARE\dotnet\Setup"
Env variables setup is now associated with a versioned component - the
registry keys. Environment resource cannot serve as a keypath hence it is
coupled with a registry key which is the key path for the component.
- Use the heat tool to harvest the stage2 dir and create install-files.wxs
- dotnet.wxs contains the XML code which is constant across builds for an MSI.
- Use Candle and Light to generate the MSI from install-files.wxs and dotnet.wxs.
Default Install Location - %ProgramFiles%/dotnet.
Adds <InstallRoot>\bin %PATH%
Creates %DOTNET_HOME% pointing to <InstallRoot>
