Will upgrade basis environments.

[kekyo]

• Target frameworks (include netcoreapp2.1, netcoreapp3.1, net5.0 (net6.0 will include when final released).
• Upgrade building related packages (RelaxVersioner, cecil?)

Motivate

I already switched main computing platform from Windows to Linux (Ubuntu). So need to build on Ubuntu and pure .NET 5.0 SDK (and use Rider).

[kekyo]

Other topic (only listed)

• Switch from Azure DevOps Pipelines to GitHub Actions.
• Automated building script on host == target environment.
  • ex: Build csproj on Windows, IL2C will use self-hosted gcc compiler.
  • ex: Build csproj on posix environment, IL2C will use default compiler on hosted environment.
  • Will build fully automatic host binary only referring IL2C NuGet package.

[kekyo]

NOTE: Add platform targets applying only IL2C bulding time, NOT IL2C runtimes.

[kekyo]

Azure DevOps Pipelines will break.

[kekyo]

ILSupport couldn't execute on posix environment, because it depends native tooling ilasm and ildasm on netfx distribution.

[kekyo]

Another solution: InlineIL.Fody

• How to automatic convert from ILSupport's pure IL assembler source code to InlineIL.Fody operators.
• Maybe have to write mini onetime utility for generate InlineIL.Fody operator annotated source code from current it.

[kekyo]

Migration code fragment is here.

[am11]

Hey @kekyo, since this project is very new (v0.4), is keeping netfx build and test support important for this project? Most new projects are targeting .NET 5.

In case it is not important for this project, it is possible to use <Project Sdk="Microsoft.NET.Sdk.IL"> in an .ilproj, and then ProjectReference that ilproj in the .csproj. That way we can write unit tests in xUnit etc. and call class/methods written in IL. That will work well on Unix-like platforms as well as Windows targeting .NET 5 onwards.

[kekyo]

@am11 Thank you, your opinion is right. I agreed MVP requirement has to make smaller, but I think:

• IL2C is AOT translation, that means verification and problem insight is maybe much difficult when cause uninterpretable problem result on the translated native binary.
• So I have to validate carefully results of IL to translated C code fragment. I thought it would probably be easy for development to collapse if the regression test was left unattended. (One of the reasons is that I was developing by lonely :)
• We (probably) only know how to do rigorous verification with regression testing.
  • Another way example, we can import CLR regression test from dotnet/coreclr project, but it contains a lot of non IL2C runtime related test. I feel it isn't realistic...

I didn't know SDK directive <Project Sdk="Microsoft.NET.Sdk.IL">, it's interesting. Can it combined single assembly both C# code and IL code? That's why I used ILSupport.

I expected the IL2C regression test to have to write a lot. Therefore, I had to think of a way to put the C# and IL code as close as possible and maintain it easily. The current method wasn't the best, but I think it was a good first idea.

(It seems that it is not well known... NUnit is already multi-platform compatible without any problems. Conversely, when I evaluated xUnit (on another my own project) about a year ago, I didn't make the transition because the parallel testing (on multi core system) wasn't very fast.)

[am11]

I didn't know SDK directive <Project Sdk="Microsoft.NET.Sdk.IL">, it's interesting. Can it combined single assembly both C# code and IL code? That's why I used ILSupport.

The IL SDK imports the .NET SDK, so it is possible to compile C#, VB, F# and IL sources with a single project file, but it has some caveats which would require us to make a custom msbuild target to override stuff. e.g. if C# file has the executable entrypoint and IL has just library methods; ilproj will have <OutputType>Exe which will result in underlying target passing -Exe to ilasm and fail due to the missing entrypoint in IL. This can be fixed with MSBuidl targets tweakings and workarounds.

The cleanest way (to avoid any workarounds) is to use .ilproj for IL files and .csproj for C# files, and then one could be library project (default OutputType), and other could be Exe referencing each other via the regular <ProjectReference Include=...; works both ways. To avoid redundancies, we can use Directory.Build.props and similar msbuild facilities. but since it is just for unit testing, I wouldn't be too worried about config files. :)

While preparing this answer, I just found a small issue on Alpine Linux (which has a workaround), which is now being fixed by https://github.com/dotnet/runtime/pull/60400. IL SDK comes right from the runtime where il{d}asm source code lives, so I recommend using that because of its primitivity. :sweat_smile:

You may also find structure of ilverify tests, interesting: https://github.com/dotnet/runtime/tree/cf49643711ad8aa4685a8054286c1348cef6e1d8/src/tests/ilverify/ILTests (probably not the exact thing we need here, but something to make inference from).

[kekyo]

Topic on IL SDK:

I checked IL SDK NuGet package and got another solution.

It contains referrer of ILAsm/ILDasm .NET 5.0 based binaries splitted several public distributed NuGet sub packages. That means can continue using the ILSupport with these sub packages. I'm thinking about which method to use.

I feel that maintaining IL Support is not very good, but I feel that this method has the advantage of minimizing changes....

[kekyo]

Memoized ILAsm native binary naming rules:

• For windows x64: runtime.win-x64.Microsoft.NETCore.ILAsm
• For linux x64: runtime.linux-x64.Microsoft.NETCore.ILAsm

[kekyo]

@am11 #103 was finished. Thanks suggested IL SDK directive to done soft-landed reusing ILSupport with public ILAsm package.

[kekyo]

Memoized ILVerify package: https://www.nuget.org/packages/dotnet-ilverify/5.0.0

[kekyo]

Problem: Rider (on ubuntu 20.04) couldn't find dynamic generated testcases on unit test explorer.

(Building is succeeded on ubuntu 20.04 except IL2C.Runtime (VC++) project).

[am11]

@kekyo, thanks a lot! To work with devel on unix, I had to apply this patch https://github.com/kekyo/IL2C/pull/106. :)

[kekyo]

GitHub Actions partially enabled.

• Windows job porting isn't finished.
• Linux enviroment regression tests cause some (<30) errors, but it isn't porting issue.

[kekyo]

9eb59655e278f76f195dda6740d1cbebd0dfe34c Windows CI with test is recovered.

[kekyo]

MEMO: I found it. NUnit 3 custom attributes are dynamic test case generator interface, cool.

Currently Rider on linux doesn't show up any test case in the test explorer. I feel it problem reason comes from using internal knowledge of NUnit. It is found on NUnit version 2 and it didn't have these interfaces...

[kekyo]

MEMO: Bit related #79, I merged #114 and made stable on linux CI for building. Next step is how to fix these problems.

[kekyo]

I implemented (and WIP) ILCompose. IL2C unit test will be switched using from ILSupport to ILCompose.

• [ ] All test case switching attribute target from class to each method and changing standard NUnit TestCase attribute.
• [x] Remove ILSupport and apply ILCompose.
• [ ] Rewrite native code test driver (maybe using new build infrastructure).

[kekyo]

I found a slightly older (but public), extended interface for NUnit. It may be possible to run native code after a managed test run without affecting NUnit's TestCaseAttribute (i.e., Rider works correctly). Need to check:

• Whether throwing from ITestAction.AfterTest() results in a test error.
• If the ITestAction works when executed in a class that inherits the TestCaseAttribute attribute, and if Rider works correctly in that state.

If the second method works, it may ease the transition of the test code by mimicking IL2C's own TestCaseAttribute constructor signature.

[kekyo]

The following codes were tried with good results.

using NUnit.Framework;
using NUnit.Framework.Interfaces;

namespace ClassLibrary1
{
    public sealed class CustomTestCaseAttribute : TestCaseAttribute, ITestAction
    {
        public CustomTestCaseAttribute(object? expected, params object?[] args) :
            base(args) =>
            this.ExpectedResult = expected;

        public ActionTargets Targets => ActionTargets.Default;

        public void BeforeTest(ITest test)
        {
        }

        public void AfterTest(ITest test)
        {
            //throw new Exception("AAA");
        }
    }

    public class Class1
    {
        [CustomTestCase(3, 1, 2)]
        public int Test1(int a, int b)
        {
            return a + b;
        }
    }
}

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
    
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.11.0" />
    <PackageReference Include="NUnit" Version="3.13.2" />
    <packagereference Include="NUnit3TestAdapter" Version="3.17.0" PrivateAssets="All" />
  </ItemGroup>

</Project>

[kekyo]

#119 merged, but there are still a few remaining cases.

• [ ] Generating native binaries in test cases to run tests
• [ ] GitHub Actions execution issues (automatic package push fails due to infrastructure issues)

We found that we needed to address the native binary generation and referencing issues in the library references (PackageReference and ProjectReference) before running them in the test cases.

This issue is related to #121 #122 #123.