| Age | Commit message (Collapse) | Author |
|---|
|
This change adds Path.GetRelativePath, which will calculate the relative
path from one directory to another file/directory.
This change also adds support for targetting netcoreapp
|
|
|
|
|
|
Enable netcoreapp1.1 tests to run as part of the CI build
|
|
* Initial prototyping of produces api for corefx repo
* Fix spacing
|
|
|
|
As part of automating stress test builds include the test-runtime
project.json file in the test archives; this requires a build tools update
to pick up the new functionality.
|
|
This change is to support filtering according to the TestTFM. e.g. can do
“build.cmd /p:FilterToTestTFM=net46”
The change here is splitting the Build phase from the Test phase in dir.traversal.targets
so we don’t have to rebuild the test assemblies when passing TestTFM property to run the test.
Now if FilterToTestTFM is not specified, we default running the tests as netcoreapp1.0
so when issuing “build.cmd/sh” Command without passing FilterToTestTFM, it will
filter the tests to netcoreapp1.0 and run those tests.
I have enabled one of the test projects System.AppContext.Tests to support net46
as example, next step will be Enabling the rest of all projects to run against all
platforms (net46, net461, net462, netcore50 and netcore50aot)
|
|
before building (#8088)
|
|
* Enable project refrence to package dependency conversion in test builds
Opts some tests out of the process with "KeepAllProjectReferences"
Opts some project references out of conversion with "KeepProjectReference"
pulls in maririos change to sync.cmd
Respond to PR feedback
Note: Generated project.json's fail to restore because of missing test-runtime
property in frameworks which now have dependencies but previously did not.
* Move global.json to root so that generated project.json's can find it for the test-runtime
* System.Reflection.Context does not run on dnxcore50, but the project.json has that specified as the framework.
Can't convert this to netcore50 because there is no current test-runtime for netcore50. Leave project reference
when doing a test build against packages so that it can use the netcore50 implementation directly.
|
|
|
|
Conflicts:
dir.targets
|
|
When building CoreFx from TFS we need to inject build
targets that merge optimization data into the binary.
Previously we did this as a post-build step that would
copy the binary to a different location. When we moved
packages to the open this changed the package to pick
up the binary from the open build location instead of
the internal copy with optimization data. To fix this,
inject the optimization step into the open build.
Eventually we need to port the optimization merge
task to buildtools so that we don't have to rely on
this internal-only build step.
[tfs-changeset: 1578918]
|
|
|
|
|
|
[tfs-changeset: 1562939]
|
|
ProjectK as changeset 1548846
[tfs-changeset: 1549309]
|
|
changesets integrated from Fxmain. This in order to unblock the build.
[tfs-changeset: 1548857]
|
|
|
|
Inputs/Outputs were locked. Switch to a semaphore file and allow it to warn in the rare case it fails to touch it successfully.
Merged from CS#1485206.
[tfs-changeset: 1493243]
|
|
Since dnu doesn't support config files we must use the --source argument instead; this way we can specify an internal cache when building from razzle.
This adds a new item group, DnuSourceList, which contains all of the nuget package sources dnu should query when restoring packages. For razzle builds we add our internal cache on \\cpvsbuild.
I removed all but the build tools feed from nuget.config as we no longer rely on it for package store (just for build tools).
Merged from CS#1493227.
[tfs-changeset: 1493233]
|
|
|
|
Support Proxy servers for our nuget download task
|
|
|
|
Reapply #38, but handle the case when DefaultWebProxy is null.
Fix #963
|
|
Add the Mono MSBuild package and update the build script to consume it and restore tools via xbuild.
|
|
Conflicts:
dir.props
src/.nuget/packages.config
|
|
hitting nuget.exe.
[tfs-changeset: 1465421]
|
|
Allows a successful compile with xplat MSBuild branch and Roslyn on Mono.
Adds the Roslyn package and UseRoslyn property to use Roslyn.
Disable PDB generation (NYI), skip packaging, disables ECMA delay signing.
Also temporarily disables two test projects.
Fixes casing for a few source file includes.
Add issue links and a check for missing Roslyn targets when attempting to build on Roslyn.
|
|
Use to determine current environment in $(OsEnvironment).
Fix spelling, explicitly add default OSGroup.
|
|
|
|
The partial facade target writes project.json files into the
intermediates folders and there is no nuget.config file in that
directory hierarchy so package restore may not complete successfully.
Until aspnet/dnx#1693 is fixed, work around this issue by copying our
NuGet.config to the root of the intermediates folder.
Fixes 1508
|
|
Currently DNU doesn't support -ConfigFile: https://github.com/aspnet/dnx/issues/1693
Our DnuRestoreCommand doesn't force a config file and we rely on the
directory probing for it to find nuget.config. This works for restore from source,
but not restore from PackagesDir as happens for test project restore since PackagesDir
will not be under src. To workaround, copy our nuget.config to packages
[tfs-changeset: 1458493]
|
|
Nuget v3 no longer has nuget.exe, so we need to use dnu to enable transitive package restore from project.json.
|
|
|
|
handles the first step of
package restoration and basic compilation.
Conflicts:
dir.props
src/.nuget/packages.config
|
|
This reverts commit d49f8f5f40458b850b2c49c2966db13777957ac0, reversing
changes made to c2c8efbd2a359d8e33ddef54b5b553c45404865f.
|
|
We should restrict the OS, Configuration, and Platform input properties based on allowable values to avoid user error (example, passing OS=Unix vs. OS=Linux).
|
|
|
|
|
|
Switch to running tests with new BuildAndTest target.
|
|
because in some cases it is null and I've not found a reason when it is actually ever needed.
Also update our internal targets so they now download Nuget.exe again instead of using a checked in version.
[tfs-changeset: 1416207]
|
|
This change adds a BuildAndTest and Test target to our default
dir.targets file and hooks RunTestsForProject off the Test target
so that by default if you build an individual project from the
command line or in an IDE like VS it will just do the build and not
run the tests. If people want to run the tests then they need to
execute the BuildAndTest target (or just the Test target). This
prevents the need for us to use special conditions like
BuildingInsideVisualStudio in our targets.
I've also changed the DefaultTargets for our build.proj and dirs.proj
files to be BuildAndTest so if you run the build for them it will stil
do the build and test run.
|
|
Incremental build tweaks
|
|
While performing an incremental build via build.cmd/proj you can
get into a state where the _RestoreBuildTools target executes for
every project. While this doesn't break anything it does cause
as slowdown. The way to enter this state is to keep the packages
directory around for a while and get or make an update to dir.props
or .nuget\packages.config which are the inputs to the target. Then
you will execute the target everytime because nuget.exe nor
the built tools package will actually be updated as part of executing.
To fix this I've added a call to Touch at end of the target to ensure
that the last modified time is always greater on the output files
then the input files.
|
|
The value passed to Exists() should be enclosed in single quotes according to https://msdn.microsoft.com/en-us/library/7szfhaft.aspx
|
|
With my recent changes I see race conditions with downloading nuget.exe
in some cases so I hardened the download target a little to try
and avoid locked file race conditions. While it still isn't full
proof the window of time is much narrower now.
|
|
This change switches from running package restore all at once
in a command line build to doing it for each project one at a time.
This allows individual projects to be built successfully from VS and the
command line without requring full build of the repo.
It also allows the nuget installs to happen in parellel while
running a full build as well as makes them respect incremental builds and
only restore packages if the packages.config file has changed or the
packages folder doesn't exist.
One limitation to this model is in some cases when building an individual
project from the command line you may hit an error if it is the first to
restore the build tools package. The error will tell you retry the build
and it will succeed on the second try. This only happens if you build
leaf node individual projects from the command line, it will work if you
build them in VS or the entire repo from build.cmd/proj first. This is
just a limitation of restoring packages in the same msbuild session that
is trying to import targets from that restored package.
|
