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
Add basic Tests for dotnet-compile-fsc
Package Targets execute before TestTargets. Use Generated Nuget Packages in TestTargets. Generate Nuget packages on all platforms, and in C#
Fix bug in dotnet-restore, change fsharp new template, add support for native assets in DependencyContextCsvReader
copy fsc.exe to temp directory instead of package cache
fix rebase error
fix issue
fixes
fixes
fix
temporarily disable debian package e2e testing
fixes
bump fsc version
update fsc version
fix rebase errors
WIP update fsc tool
WIP, rebased and working again, need to solve issues with System.CommandLine
Working state for packaged, command, fsc.exe bugging out with dlopen(, 1): no suitable image found.
execute fsc like a unpublished standalone app
fixup after rebase
working? internet is out
working
cleanup
More cleanup, and run the debian package tests during the Test phase of the build.
update FSharp Test Projects NetStandard Library Version
Update Version Suffix when packing TestPackages. This will enable packing with the right dependency versions on Windows.
update dotnet-test version
Undo the reordering of the build
fix test package project pathsj
ignore net451 build failures for test packages which we need to build on non-windows
update dependency of desktop test app
add dotnetcli feed to nuget config for fsharp dotnet new
update deps after rebase
update dependency of dotnet-compile-fsc
pass args before commandPath when using muxer for tools
adjust testpackage cleaning not to clean packages which are also generated as part of the product from the nuget cache.
undo
Pass projectJson to pack instead of using WorkingDirectory
fix path separators using depsjsoncommandresolver on windows, fix building only specific frameworks for testpackages on non-windows.
PR Feedback
rebase
overwrite fsc runtimeconfig
- Make the .Net CLI SDK install SxS.
- Make the .Net Host upgrade till RTM(v.1.0.0).
- Make the .Net Core Sharedfx pkg to use the SharedFx Nuget version instead CLI version.
- 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.
fix dependencies between packages
re-disable upgrade test
another fi to add_dir_to_install
fix sdk package name
update the package name functino in monikers
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.
