| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
* Delete old ObjectWriter NuGet packaging scripts
* New ObjectWriter NuGet packaging scripts
|
|
Make the Server GC an optional component by building two flavors of the runtime and selecting a specific one in the build via the `ServerGarbageCollection` MSBuild property. Don't build the Server GC flavor for Web Assembly.
Fixes #5182, Fixes #5306.
|
|
|
|
|
|
|
|
|
|
As it stands we only produce a Windows ILCompiler package. This work implements building and publishing of OS-specific runtime packages and spins off ILCompiler as a meta-package, which can be referenced when adding to a project.
Working on this, a quirk in MSBuild behavior under .NET Core popped up - build artifacts (i.e. .targets and .props files) are imported for direct project package references, but not for runtime-specific packages, defined as dependencies in the meta-package. This doesn't seem to be the case in vanilla MSBuild.
The below is a serious hack to work around this - during runtime, we find the resolved runtime package reference and define the path to it on disk, from which all OS-specific components are loaded and run. The motivation behind the workaround was to keep the package as small as possible, particularly because of the large intersection of components between OS implementations.
All workarounds are marked as such and should be removed once Microsoft/msbuild#2807 is resolved.
There is some slowdown because of sequential resolution of targets, but not immediately noticeable and is unfortunately unavoidable - almost entirely avoided if CoreRT build targets are referenced directly (excluding MSBuild overhead).
|
|
|
|
|
|
The latest project templates do not have it, and it is only good for generating warnings like the following in the detailed build log:
Project file contains ToolsVersion="4.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="14.0". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
[tfs-changeset: 1662024]
|
|
|
|
The references to CoreRT and ProjectN .csproj were conditionalized in some places, but not others. Apply the condition consistently everywhere to avoid unexpected interactions.
[tfs-changeset: 1654415]
|
|
|
