* update nuget to 4.0.0-rc3 and sdk to 1.0.0-alpha-20170105-5
* Modifying restore project.json to use the project.json stage0 CLI instead of restore-projectjson command.
* add a nuget dependency so migrated project has packageref and generates an assets file on restore
* Archive asp.net package references
* Archive asp.net package references
* Change the hash input so it's the same on all platforms
* Address PR comments
* add stub for dotnet list p2ps
* apply review feedback
* PR feedback: consistent method modifiers
* apply missed review feedback
* add test coverage and do not treat no p2ps as error
* move private methods to the bottom, rename weird res name
* Move dotnet-new templates to Sdk attribute
* Update to MSBuild 15.1.0-preview-000454-01
To pick up a fix for Microsoft/msbuild#1431.
* Fix template newlines
* Fix casing on Microsoft.Net.Sdk
* Move migration test csproj's to Sdk attribute
* Disable parallel sdk restore
Each SDK restore operation will try to manipulate the same assets.json file since the dependency name&version are injected into a common csproj file. This can cause runtime failures when two NuGets try to restore the project at once.
* Make casing of SDK 'NET' and not 'Net'
* Remove redundatn imports
* Fix test string
* Additional race
* Replacing the SDK with the Web.Sdk when it is a Web project.
* Fixing the test by writting the csproj before running the migration rule.
* Fix output race
TestCommand starts the test process before wiring up stderr & stdout. This change delays process start until after the wireup is finished so that the test process cannot shut down before we have wired up output redirection.
* Bypass stream forwarder when it fails to attach to a process
CLI has tests failing errenously when, due to timing issues, the StreamForwarders fail to attach to a process because it managed to exit before attachment occurs.
We tried attaching the forwarders prior to Process Start but this proved impossible because the OUT and ERR streams are not available to attach before the process starts.
This exposes a fundamental flaw in our output redirection mechanisms. We should probably move to using https://msdn.microsoft.com/en-us/library/system.diagnostics.process.outputdatareceived.aspx or a similar mechanism. However, I don't know that @brthor hadn't considered and discarded this approach.
For the time being I am attempting to make tests more deterministic by capturing the associated exceptions and moving to a different mechanism when StreamForwarders are not available.
Opened https://github.com/dotnet/cli/issues/4913 to track the broader issue.
* File.Copy is not atomic...
* Centralize Microsoft.Net.Sdk package version
Note: Templates were omitted as their version needs to be static.
* Unifying additional missmatched versions
* prefercliruntime
whitespace threw off ReplaceAll
* Additional missed globs
* Revert SDK version for performance tests
* PR Feedback
* Roll back VSTestXunitDesktopAndNetCore.csproj SDK version
* WIP migrate tests
* WIP fixing more tests
* WIP fix test build break
* Test results files are now trx
* Get CI to pass until we get an xunit xml logger
* Added DotNetTestPJ since that was needed for one test
* Fix build break
* Forgot to add DotNetTestPJ as a build task
* Need to restore project.json for the project used in ubuntu test
* Restore PJ for ubuntu test
* Switch the Ubuntu test to csproj based
* Updating the Microsoft.Net.Sdk & Microsoft.Net.Sdk.Web versions
* Fixed merge conflicts. Had to re-update the Sdk version in one place.
* re-migrate dotnet.dll
* Revert Performance Test Projects
* Fix test test
* Add missing WithRuntime
* Disable failing test test
* Migrate "runtimes" section as a RuntimeIdentifiers property in the resulting csproj file. Also do not call restore3 from publish3 anymore.
* Fix up the publish3 tests to call restore3 first and the csproj files to have RuntimeIdentifiers
Moving the CommandResolution classes that depend on msbuild back into Cli.Utils.
Updating the src projects to a netstandard compatible with Cli.Utils moving to netstandard1.5
* Implemented vstest verb which will run the test from given container.
* Fixed Nitpick.
* 1) Addressed PR comment
2) Added tests for vstest verb
* Using specific version of Microsoft.TestPlatform.
* Address PR comments.
Modified help text for the vstest command.
Removed unused function.
* Fixed package related issue.
--Taking reference of microsoft.testplatform.cli nuget package which has contentFolder in it so that sub folder of this nuget can also be added in cli package.
-- Removing vstest.console, vshost and datacollector from Bundletools as we dont want *.deps.json to be override
* Nitpick
* Making vstest.console arguments compatible for non windows platform
* Fix tests to run on linux machine
* Updated the microsoft.testplatform.cli nuget package version. This version has fix related to non windows machine.
* changed dapter path from bin/debug to bin/Debug
* updated nuget version of package Microsoft.TestPlatform.CLI.
* Revert "updated nuget version of package Microsoft.TestPlatform.CLI."
This reverts commit bcc26c21d11c2bd2e5259a74f9890b0fd75962c7.
* Updated version of nuget package Microsoft.TestPlatform.CLI
Added Test project in solution file
* Addressed PR comment.
* Removed unnecessary --platform argument from test
Update Microsoft.Extensions.DependencyModel to 1.0.1-beta-000933
Update Microsoft.DotNet.PlatformAbstraction to 1.0.1-beta-000933
Update NuGet to 3.6.0-beta.1.msbuild.4
Update dotnet-test-xunit to 1.0.0-rc2-350904-49
- Created a Configurer class that is responsible for deciding when to run the dotnet first time use
experience and invoke the NuGetCachePrimer.
- Added the NuGetCachePrimer which extract the archive and primes the cache.
-- This is just missing creating the sentinel once restore succeeds.
- Added a shell for the NugetPackagesArchiver, which will be responsible for expanding the archive (likely
replaced in the future by an abstraction from Eric's code or its implementation will simply call Eric's code).
- Added a TemporaryFolder abstration to Internal Abstractions that handles deleting the temporary folder once
we are done with it.
PR #2493 introduced the new project.json schema. The tree has 118 files
with the old schema, which added several hundred warnings.
This change can't go in until PR #2864 does - it relies on those bug
fixes.
The following packages are changing:
Microsoft.NetCore.App: 1.0.0-rc2-3002702 -> 1.0.0-rc3-002702
Microsoft.NETCore.DotNetHost: 1.0.1-rc2-002702-00 -> 1.0.1-rc3-002702-00
Microsoft.NETCore.DotNetHostPolicy: 1.0.1-rc2-002702-00 ->
1.0.1-rc3-002702-00
Microsoft.NETCore.DotNetHostResolver: 1.0.1-rc2-002702-00 ->
1.0.1-rc3-002702-00
Also publishing the *deb file to teh debian repo feed is disabled -
https://github.com/dotnet/cli/issues/2973
Simple tests which does static analysis of managed assemblies metadata to
make sure that they are crossgened. Currently it verifies that all the
assemblies in CLI SDK and SharedFx directroty are crossgened.
Creates a TestDirectory abstraction under TestInstance to manage creation of test-specific working directories
Enables TestAssetManager to create TestDirectory instances
Enables fluent addition of Environment Variables to TestCommand
Adds PathUtility support for ensuring a directory exists
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
we used to use different code when --framework was specified than when it was not specified, this synchronizes them to use the same code path which removes a hidden NullRef
also adds tests to cover both cases
* 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.
- Every project.json needs portable-net451+win8 and dotnet5.4 imports (required by dotnet-test-xunit).
- If a test references NuGet, it also needs "netstandardapp1.5", because that the TFM NuGet uses currently.
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
KestrelSample app compilation time on CI machines is 16-20s and the test timeouts even before the kestrel server is up, which I suspect is the reason why kestrel tests are flaky.
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
- ProjectModel uses AssemblyLoadContext which is only available in netstandard1.5. Moving ProjectModel and all its dependencies up to netstandard1.5.
- Work around our dependencies still being on old CoreFX builds by hoisting System.Runtime.Serialization.Primitives, System.Private.DataContractSerialization, System.Linq.Expressions, and System.Xml.XmlSerializer references to the current version.
dotnet-build will produce a deps file for portable builds, and will now
create "runnable" outputs for RID-less targets
the outputs won't actually be runnable today because we need corehost
changes and to generate a deps.json file for corehost to use.
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.
Add TargetFramework and FullTargetFramework to compile and publish script
variables.
Add ProjectLocal Command Resolution Strategy.
Fixup ArgumentEscaper to not always quote things.
Fixes#1216Fixes#1016Fixes#982
