github.com/mono/linker.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2022-11-10	Unpin compiler version and use net6.0 for ilasmdarc-release/7.0-498ece01-94fe-4605-8e70-f2f687a221b1	Sven Boemer

2020-09-17	Update to target .NET5 framework (#1471)	Marek Safar
	Co-authored-by: vitek-karas <vitek.karas@microsoft.com> Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
2020-03-26	Feed cleanup and add darc dependency for Microsoft.NET.Sdk.IL (#1021)	Matt Mitchell
	* Feed cleanup Switch away from blob feeds * Add dotnet5 feed * Add darc dependency for Microsoft.NET.Sdk.IL and upgrade to latest version Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
2020-02-06	Run illink tests on CI (#937)	Marek Safar
	* Set ILLink.Tasks.Tests to be test project * Unconditionally use arcade * Fix ILLink.Tasks test project - Renamed to ILLink.Tasks.IntegrationTests because it depends on the .nupkg and arcade schedules Test projects before Pack - Fixed path to nupgk in nuget config - Move override of Test target for NUnit project from root Directory.Build.targets. For some reason Condition doesn't work there so the target would always be overriden. - Disabled MusicStore tests They were already disabled in https://github.com/mono/linker/commit/04eb53822f98749bdf6ab47009ba7c269f504eae because of https://github.com/mono/linker/commit/04eb53822f98749bdf6ab47009ba7c269f504eae but looks like that got reverted somehow * Make arcade enabled builds the default and remove special illink_ configs Mono builds can be done with /p:MonoBuild=true * Remove .net framework targets from netcore build * Update ILLink.Tasks to netcore3.0 * Fix netcore condition * More netcore3.0 updates * Try to mimic weird arcade behaviour * Enable test results publishing in arcade * Remove DisableArcadeImport property and use temp folder for ILLink.Tasks test projects instead * Fix net471 build on Unix * Use a temp folder in the repo and write empty Directory.Build.props/targets instead This works better with arcade temp folder overrides. * Revert "Try to mimic weird arcade behaviour" This reverts commit 3923c5410bf2d17073373924dc53020c91fea346. * Force always downloading a local dotnet We need this for the ILLink.Tasks tests. Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
2019-03-26	Enable unit tests on .NET Core (#489)	Sven Boemer
	This enables the unit tests to run on .NET Core. CodeDom compilation doesn't exist on core, so I've added the ability to compile in-process with Roslyn APIs. This still uses NUnit, using a recent version of NUnit package references with "dotnet test". This doesn't change how tests run on mono. Finding the right reference assemblies for compilation is a bit different on .NET Core. As described in https://github.com/dotnet/roslyn/wiki/Runtime-code-generation-using-Roslyn-compilations-in-.NET-Core-App, they can either be found using packages (what the SDK does), or we can just compile against the implementation assemblies. In this change, I'm compiling against implementation assemblies, since that's fairly similar to what the tests do on mono, where they find them in the GAC. For mono, the common references only included mscorlib. For .NET Core, I'm getting the common references from the "Trusted Platform Assemblies" (TPA) of the test process. As a result, package references of the test project become references during testcase compilation. Explicit references specified via `ReferenceAttribute` in a testcase are looked for alongside the host process's implementations as well (since we have no way to resolve a reference from just the filename since there is no GAC). Other changes: - Roslyn outputs the `DebuggableAttribute` by default but mcs does not, so when running on .NET Core, we don't check for the `DebuggableAttribute`. - Check for core types in `System.Private.CoreLib` instead of `mscorlib`. - There are some more edge cases that I'm in the process of cleaning up and will update soon. At the moment, I'm trying to get the tests up and running, and I'm using plenty of compile-time conditions to modify the behavior on core. It would be nice not to have to do this - I haven't given it much thought, but maybe we could provide an abstraction that contains knowledge of the platform libraries, so that we don't have to have a hard dependency on `"mscorlib.dll"` and `"System.Private.CoreLib.dll"` everywhere? @mrvoorhe please let me know if you have any thoughts. Does the approach I'm taking so far seem sane to you? @marek-safar