These are basic tests for now, which validate installation, upgrade,
uninstall, etc. of the debian package itself. When the shared framework is
fully functional, we will add more tests that cover real functionality.
It now includes the shared framework 'name' (NuGet package name) in the installer. In this case, the installer is called '.NET Core Shared Framework (NETStandard.Library 1.0.0-*)'
This causes three pkg files to be produced:
* A component pkg for the shared framework.
* A component pkg for the shared host.
* A product archive which includes the above two components.
The product archive also needs a distribution.xml file which contains
metadata about the package (name, title, images, etc.).
The installer for the "SDK" itself is still using logic implemented in
package-osx.sh. We should move this logic into the build target as well,
but we may want to wait until the CLI is using the shared framework to do so.
Ideally in the project.json for the shared host we would just list the
actual package that holds the shared host, instead of all of
NetStandard.Library, but doing some leads to compliation errors, since
publish wants to include a compile step that has a generated
AssemblyAttributes file which references types like System.String.
- 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.
There was a bug in naming the versioned PKG for OSX when it is being packaged. This resulted
in two different names for the latest and versioned, which is not what we want.
Fix#1537
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.
Renaming variables according to code review comments. Adding the folder logic to the builder tests. Creating a separate compilation folder during the build.
Changing the build scripts to copy files over from debug\dnxcore and to check for the folders existence before trying that.
Making the build command aware of the subfolders and making E2E tests aware of subfolders.
Fixing compiler tests to look for the xml in the right plae taking into consideration the configuration and tfm.
Modifying publish tests to not take into consideration the runtime. This is a temporary change. will bring it back once the commands all understand rid.
Making the packaging step work by placing binaries where dotnet pack expects.
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.
Since we are still waiting for the fix in CoreCLR to resolving
symlinks, moving the PKG postinstall to add dotnet bin dir
to systemwide path using /etc/paths.d/dotnet file.
Fix#786, #771, #841
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.
Adding symlinks for the following commands:
* dotnet-dnx
* csc
Also adding symlink for libclihost.dylib because it is needed
for the corehost.
Fix#823, #786
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
Build becomes the new compile. It decides which project to compile and how. It checks for incremental preconditions
Compile's resonsibility is trimmed down to only knowing how to invoke the compiler on a project
A temporary fix for the PKG permission issue by using chmod -R 755 in the postinstall
script. Change the install location to remove the "cli" part of the path. Also
change the corehost to reflect this change.
Fixes#492 and #390
The debian package build usually detects dependencies of executables packaged inside, and adds those as dependencies of the package accordingly. It doesn't detect this for managed executables though, so libcurl3 needs to be added to support `dotnet restore` on Ubuntu.
The long description format is somewhat fragile right now. Changes will need to be made to the package tool to handle this better because each line in the long description needs a leading space.
- 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.
These changes will use docker's new Dockerfile Arguments to
pass the Host User ID to the docker container at build time.
This allows the docker container to set it's internal user
to match that of the host. When using shared volumes between
the host and container, this prevents files created in the
container from being owned by root.
This will solve our problem of needing a cleanup step after
every ubuntu CI run.
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.
Add proper symlinks to the postinstall script. Also, the permissions of the
resulting directory post-install were wrong (set to root:wheel). This is fixed
by using the --ownership preserve switch to pkgbuild.
Fix#247
- 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>
