No longer necessary to restore/build. Removing them allows NuGet to
restore only the packages necessary for the current platform, vastly
reducing cache sizes and restore time.
My `~/.nuget/packages` directory was almost 1GB smaller with this
change.
The primary reason to do this is that the VS Code debugger is not
compatible with rc2.
Secondarily, we want to continue tracking CoreCLR/FX master branch,
which means to continue with the latest release candidates. Since we are
releasing in August, we will be able to pick up the converged RTM
version before release.
The only advantage of rc2 is that it is frozen; but we have this anyway
because we snap to particular builds.
Note that we leave the ps1xml file parsing code alone in monad, as
third-party code may use the InitialSessionState interfaces directly and
thus ask for these files to be parsed. The removal of these files is a
pure performance work-around, where instead of parsing the XML, a
pre-parsed C# version of the file is loaded.
This package contains the Windows runtime assemblies of packages that
are not actually supported on Linux. The assemblies exist in the Linux
runtime folder. While the code cannot be executed, this allows
PowerShell to use the Windows specific types in its function calls
without crashing (and allows compiling with these types in the first
place). This is *not* an ideal work-around, but we are waiting on a
better package from .NET that contains Linux runtime assemblies that
throw `PlatformNotSupported` exceptions on use.
All libraries now use the framework `netstandard1.5`, and import the
`dnxcore50` and `portable` frameworks. The app that is published,
Microsoft.PowerShell.Linux.Host, that is, the top-level dependency that
emits an executable, instead targets `netstandardapp1.5` and has a new
`runtimes` key so that .NET CLI's `restore` and `publish` commands know
which runtime implementations to resolve.
When switching to the new CLI, we needed to fix how we specified our
dependencies. In particular, the .NET CLI team helped me figure out how
to download packages that are reference assembly only on Linux, with
implementations on Windows. The result of this is the new `frameworks`
setup.
Additionally, we were incorrectly specifying our build dependencies;
that is, projects we also build (not packages). The solution was much
cleaner. We removed the `type: build` section and replaced it with the
version `1.0.0-*` that all our projects currently use.
The `project.json` files also had their names, descriptions,
indentation, and versions fixed.
The build scripts were simplified.
This was a temporary work-around that now needs to be removed (mostly
because the xUnit tests are out-of-date because we didn't have a runner,
and it's not worth it to fix them). Rather than let more cruft
accumulate, we need to remove it.
Resolves#551
Same as ps1xml files: already deployed in the wild, i.e. not source
code. Allows to remove recursive copies from build scripts and rely just
on CLI's behavior.
This allows us to remove the duplicated copying steps from our Windows
and Linux build scripts. These files are already distributed to users of
Windows, and so are not "source code."
The packages are now dependencies of the `dnxcore50` framework itself,
rather than globally. The `compilationOptions` were pruned, with
`CORECLR` moved to frameworks, `_CORECLR` removed for all but
`Management.Infrastructure`, and `LINUX` moved to a new `Linux`
configuration, used only in `build.sh`. This configuration is
purposefully absent from libraries that do not use `LINUX`, so that it
is not relied upon without strong consideration. The dependencies
were pruned to reduce duplication.
Commands.Utility now needs Microsoft.CodeAnalysis.CSharp, which doesn't
explicitly target `dnxcore50`, so now Commands.Utility and the packages
which depend on it now much `import` the Portable Windows framework.
This also required adding the aspnetvnext feed.
System.Management.Automation now requires System.Diagnostics.StackTrace.
Instead of Microsoft.PowerShell.Linux.Host
Since this changes the name of the library,
System.Management.Automation's assembly info needed to be updated.
Deploying module is a bit funky until dotnet-cli gives us more control
over which libraries to build and where. Theoretically we'll be able to
package System.Management.Automation and depend on the package instead,
so Commands.Omi can be its own project entirely.
Cleaned up the Commands.Omi project.json as it had some unnecessary
cruft from where it was copied. Also removed the AssemblyInfo as it does
not matter for a new module.
Moved the Get-OmiInstance Pester test to the project's test folder so it
doesn't run with our suite of tests (as it takes a dependency on OMI).
Need the up-to-date version so that exiting the console doesn't totally
mess up the hosting shell (Bash).
Should not depend on this package longterm, as it's
platform-specific. Tracking in https://github.com/dotnet/cli/issues/405
