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>
