When using a ruleset with a relative path in buildOptions, csc can't
find the file because it is not working in the same directory as the
project.
Fix#2710
- Added PackOptions, RuntimeOptions, PublishOptions and updated CompilationOptions
- Added IncludeFilesResolver to parse include, exclude patterns
- Added compile, embed and copyToOutput to compilationOptions
- Renamed compilationOptions to buildOptions
- Moved compilerName into buildOptions
- This change is backwards compatible
- Added warnings to be shown when the old schema is used
- Handled diagnostic messages in ProjectReader
- Added unit and end to end tests
* 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.
* Fix duplicate dependency issue
If a package has the same name as a framework assembly in the dependency
graph, we usually replace it with the framework assembly if the package
provides no assets. If the framework assembly wasn't resolved, it would
skip this logic and end up adding dupes to the list, which blows up later on.
This is a tactical fix to solve the issue, we need to do some more thinking
to determine how we want to resolve conflicts between framework assemblies,
packages and dlls with the same name.
Also removed the dependency on Microsoft.Extensions.CommandLineUtils.Sources NuGet package and instead just checking the source files into our repo as internal classes.
Fix#2526
* Add satellite assemblies to deps file with locale data
* Publish satellite assemblies to output during publish
* Copy satellite assemblies from project-to-project dependencies on
build and publish
WIP
WIP
WIP
Test out not publishing runtimeAssets
WIP
WiP x-publish
update cross-publish-test
Update Cross Publish tests
remove --config from restore
fix build
update cross publish tests
fix test compilation error
test failure fix
fix test failure
update tests
tracing
fix desktop publishing
do publish with no build, call build manually
fix
Make host publish optional, fix faux libraries?
update
Cross Publish test working
try changing test to netcore.app
fallback to host from current platform
revert change to project.json to target Microsoft.NETCore.App
fallback to compilation build output
update kestrel standalone app project.json
Make project tools command resolver test more self-contained.
make Kestrel Standalone restore against N-1
When checking if the provided assembly is the Entry Point Assembly, we
previously just checked if the AssemblyNames were equal, but it turns
out AssemblyName doesn't implement Equals, so it was using Reference
Equality, which fails. This change uses Assembly.Equals, which has an
Equals implementation that works.
Also adds some tests to ensure it's working.
This unblocks scenarios where the EntityFramework `dotnet-ef` command
was trying to read DependencyContext.Default but receiving a null
reference.
The ProjectWithTests needed to be moved outside of TestAssets\TestProjects because it can't be restored --infer-runtimes and it has to be built with netcoreapp1.0.
Created a new command resolver called OutputPathCommandResolver which
reolves a command from the project build output directory.
Made changes ProjectDependenciesCommandFactory to use
OutputPathCommandResolver if the target framework is Desktop.
Fixes - #2126
Still need to add tests.
Added unit tests covering parsing of Json for all the pieces of the project.json
Added a RawRuntimeOptions to Project and made Executable deserialize that into the runtimeOptions of runtimeconfig.json
Added tests to cover copying runtimeoptions during dotnet build.
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
Any dependencies which **exactly** match the version requested in the
graph originating at the `type: platform` dependency (if any) are
trimmed from the publish output
