Open kekyo opened 2 years ago
NOTE: Add platform targets applying only IL2C bulding time, NOT IL2C runtimes.
Azure DevOps Pipelines will break.
ILSupport couldn't execute on posix environment, because it depends native tooling ilasm
and ildasm
on netfx distribution.
Another solution: InlineIL.Fody
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.
@am11 Thank you, your opinion is right. I agreed MVP requirement has to make smaller, but I think:
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.)
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).
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....
Memoized ILAsm native binary naming rules:
@am11 #103 was finished. Thanks suggested IL SDK directive to done soft-landed reusing ILSupport with public ILAsm package.
Memoized ILVerify package: https://www.nuget.org/packages/dotnet-ilverify/5.0.0
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).
@kekyo, thanks a lot! To work with devel
on unix, I had to apply this patch https://github.com/kekyo/IL2C/pull/106. :)
GitHub Actions partially enabled.
- Windows job porting isn't finished.
- Linux enviroment regression tests cause some (<30) errors, but it isn't porting issue.
9eb59655e278f76f195dda6740d1cbebd0dfe34c Windows CI with test is recovered.
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...
MEMO: Bit related #79, I merged #114 and made stable on linux CI for building. Next step is how to fix these problems.
I implemented (and WIP) ILCompose. IL2C unit test will be switched using from ILSupport to ILCompose.
TestCase
attribute.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:
ITestAction.AfterTest()
results in a test error.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.
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>
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.
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).