- 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>
