remove publish todo
small fixes
small fixes
fix packaging test bug
Fix script bug
script changes
fix packaging test
NuGet task cancelled workaround
script fixes further
more script fixes, + workaround tweak
use build rather than compile in package command test
_nuget needs some RepoRoots
get the cats in line (d)
spaces
Fix Linux build breaks
add execution permissions
Pick up #999 Finish refactoring test scripts
remove auth
Reorder publishing to work!
fix rebase errors
fix more rebase errors
small fixes
- Calling `AssemblyLoadContext.LoadFromAssemblyName(new AssemblyName("foo"))` would not work prior to this because the assembly path lookup was a dictionary where the key was `AssemblyName` without a proper `AssemblyName` comparer.
#1084#955
- Project dependencies are always built into their specific folders and the main project is the only one that uses the output path and intermediate output path variable.
- Publish respects the output path for publish only, not compile as part of publish. This means that publishing multiple runtimes will stomp on each other. So don't do that. We can throw if you specify and output location and you haven't specified a specific combination of RID and framework. Alternatively it should probably just pick the first TFM/RID pair from the lock file. This is similar to how `dotnet run` works.
- Cleaned up the incremental build output formatting
- Use a single stream (output stream) since interleaving them was causing formatting issues (like losing random characters in the middle of outputting things).
- Didn't change how pack works, it still preserves the output structure when passing `--output`, this one is worth discussing. We could leave the build output inplace and only move the package to the output location. That's more consistent with how everything else works and can be a follow up PR.
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.
