Since we write to the console and create new processes and read from their stdout and stderr, we need to ensure we have all the code pages in our process. This way we can encode/decode strings correctly when writing to our Console, and when reading from spawned process's output.
Fix#2486
* Use a WorkspaceContext in dotnet-build to cache project data across
multiple compilations in a single build action
* Dramatically reduce string and object duplication by introducing a
"Symbol Table" that shares instances of NuGetVersion, NuGetFramework,
VersionRange and string across multiple lock-file parses
Test Results:
* Testing was done by compiling Microsoft.AspNetCore.Mvc (and it's
dependencies) and taking memory snapshots after each compilation in
dotMemory
* We used to allocate ~3MB and deallocate ~2.5MB on EACH compilation in
a single build action. This has been reduced to ~120KB
allocated/deallocated
* After introducing WorkspaceContext, total memory usage spiked from 6MB
across the whole build action to about 13MB, introducing the symbol
table dropped it back to about 5-6MB.
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
- Stamp each project with the CLI version it was last compiled with
- Rebuild those projects with a local version file that does not match the one of the current CLI that is building it
`dotnet --version` returns just the version number. This helps tools get this information without having to parse the full info.
Introduce a new argument `--info` that returns the current "long form". With this, we also change the long form to say "RID" instead of "Runtime ID" simply because that would avoid any future localization issues and thus make the parsing easier.
Fix#1607#1882
Update .exe's project.json Target Framework from dnxcore50 to netstandardapp1.5.
Update .dll's project.json Target Framework from dnxcore50 to netstandard1.3.
Adding workaround for DataContractSerialization to src\dotnet\project.json to fix crossgen issue.
Build 23901 has a dependency issue that doesn't allow the runtime.any.System.Private.DataContractSerialization
package to be restored. When we move to a new build of CoreFX we should take this workaround out.
- Added --version-suffix to build and publish
- Support reading DOTNET_* version variables everywhere versions can be read
- Show the commit sha in dotnet --version
- Added tests that check the assembly output version
- Set DOTNET_BUILD_VERSION when producing the CLI app itself so that it has the version information stamped in for help.
Only apply the ANSI passthrough for child commands. Otherwise the
escape codes are printed to the console on Windows
Make Report.Write process escape codes so that forwarded output will have
its escape codes processed.
Also make verbose be inherited by all child processes.