1. It was using the wrong version of System.Runtime.Serialization.Json
2. When invoking it during the build, we weren't ensuring it was successful, which allows the build to continue when it fails.
- 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 --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
The file permissions in our cross platform packages were all over the
place. Problems included:
- Executable text files
- Executable MSIL files
- Files not readable by world or group
In addition to just looking bad, it could cause problems in cases where
someone takes the tarballs and copies them to a global location (as
root) because now the deps file was not readable by non root users.
Add an additional step when setting everything up to put sensible
permissions on everything before building os specific packages and
tarballs.
Fixes#2004
unset the hardcoded channel
fix version badge version
fix a capitalization
fix the archives
Update filenames of zip files to have the correct versions
move version gen
fix dependencies between packages
re-disable upgrade test
another fi to add_dir_to_install
fix sdk package name
update the package name functino in monikers
* We need a newer version of Microsoft.CodeAnalysis.CSharp than the one
that NETCore.App depends on. When a newer version of NETCore.App is
published with a higher dependency, we can remove this explicit
reference.
This change triggers automated DockerHub builds for successful
official Ubuntu builds of rel.1.0.0. The DockerHub repo for this is
https://hub.docker.com/r/microsoft/dotnet-preview/.
The variables DOCKER_HUB_REPO and DOCKER_HUB_TRIGGER_TOKEN are set in
the "DotNet-CLI-CI (Ubuntu) [rel.1.0.0]" VSTS build definition.
This change also allows the Environment TargetConditionAttribute to be
used to require that an environment variable is set, in addition to the
existing functionality of being able to be used to require that an
environment variable is equal to one of a set of specified values.
dotnet host muxer does not support pre-release CLI SDK when no global.json
file is present. So fixing the CLI layout to be in production version
layout. THIS IS A TEMP HACK.
As a part of Package init create all the SharedFx, SharedHost and CLI SDK
layouts. This way all other package targets can take a dependency only on
InitPackage.
- Add Casablanca CPP Rest SDK to corehost
- Correct understanding of portable runtimeTargets section
- Fix minor issues and automation for RID
- CLI Build Integration
- Add API to consume deps files
- Unix doesn't like major as a variable name
- Define NOMINMAX for Windows.h
- Support APP_CONTEXT_DEPS_FILES
- mscorlib.ni can come from native
- Append Dotnet.dll to sdk path
- Muxer vs standalone distinction based on own name.dll
Use local-build corehost.exe
This is staying in the repo, so we can copy the local-built version.
Copy deps and deps.json, make sure corehost temp dir exists
Add additional runtimes to the sharedframework's project.json
Delete an unused file, modify crossgen target condition
* sharedhost\project.json is unused. It is copied from the local build.
* the crossgen target was conditioned on an environment variable, but the
variable could be set to anything. Instead, make sure it is either
"true" or "1".
Use stage2 instead of stage0 for shared framework restore
It now includes the shared framework 'name' (NuGet package name) in the installer. In this case, the installer is called '.NET Core Shared Framework (NETStandard.Library 1.0.0-*)'
This causes three pkg files to be produced:
* A component pkg for the shared framework.
* A component pkg for the shared host.
* A product archive which includes the above two components.
The product archive also needs a distribution.xml file which contains
metadata about the package (name, title, images, etc.).
The installer for the "SDK" itself is still using logic implemented in
package-osx.sh. We should move this logic into the build target as well,
but we may want to wait until the CLI is using the shared framework to do so.
- Use Crossgen's Ready To Run mode on all of the managed assemblies
that make up the shared framework.
- Upgrade the version of the shared framework to match what is used
in the rest of CLI (see the comment in SharedFrameworkTargets.cs to
understand why this is needed).
- Remove the IL mscorlib.dll image, since the Crossgen'd image is
already published.
Fixesdotnet/corefx#6753
Ideally in the project.json for the shared host we would just list the
actual package that holds the shared host, instead of all of
NetStandard.Library, but doing some leads to compliation errors, since
publish wants to include a compile step that has a generated
AssemblyAttributes file which references types like System.String.
- Add libssl-dev dependency to DockerFile, because the package upgrade test still depend on this. It can be removed once a newer package without libssl-dev dependency is uploaded.
- Check pre-reqs in the package script.
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.
- Changes to build scripts to produce Winx86 build artifacts like
zip/installer.
- Change to run Nuget-xplat in the same process as dotnet.exe instead of
spinning up a new 'corerun' process.
Set the calling convention to '__stdcall' explicitly else the default is
'_cdecl' on windows which mismatches with coreclr hosting APIs.
Use the newly built 'corehost' in stage1.
script changes to pipe configuration to test.ps1
debug commit, remove this commit
Change dotnet-test to invoke dotnet-test-xunit directly
build tests with configuration, framework, runtime in windows
Update testtargets in new build scripts
make configuration first arg to dotnet test
PR Feedback
update command factory
fix interface
test update
- 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.
- csc kept crashing on stage 2 and it turned out to be a version mismatch with System.Reflection.Metadata.
- Silenced crossgen
- Made omnisharp see all of the projects
