.NET Standard support

[timotei]

Requires first and foremost adding the .NET Standard framework in the NAnt config (netstandard.txt in the root)

[halex2005]

Thanks for great work!

I've taken a look and reviewed some parts of PR.
I hope someone will review this PR too.

[halex2005]

Now when you use new csproj format, I suggest to use PackageReference instead of direct storing nuget packages folder in git.

[halex2005]

I think that project reference will be better than assembly reference with explicit version specified

[halex2005]

May be useful to mark this line with (default) . Also, here you use two tabs instead of spaces, it may looks ugly in console.

[halex2005]

You may remove ugly goto and get code more readable if you rewrite code with some LINQ.

[halex2005]

If I understood your code right, consider something like:

var peerAssemblies = targets
	.Where(peer => target.unresolvedNetStandardReferences.Contains(peer.assembly,  StringComparison.InvariantCultureIgnoreCase))
	.ToArray();
foreach (var reference in peerAssemblies)
{
	ArrayAppend(ref target.peerReferences, peer.assembly);
}

foreach (var reference in target.unresolvedNetStandardReferences.Where(reference => targets.All(peer => !peer.assembly.Equals(reference, StringComparison.InvariantCultureIgnoreCase))))
{
	int rc = resolver.ResolveReference(cache, ref target.references, reference, true);
	if (rc != 0)
	{
		return rc;
	}
}

[halex2005]

I don't like this return statement. Not all peer assemblies could be added to target.peerReferences sometime.

[halex2005]

Actually, I believe we can stop using nant and use something new build script automation tools like cakebuild or nuke. IMO, this will be more readable and supportable.

[halex2005]

Is this file supposed to be included in git history?

[halex2005]

I suggest to remove this file and packages folder due to new csproj format is used. We could use PackageReference in csproj instead.

[halex2005]

So many potential runtime errors. Could we workaround this sometime?

[halex2005]

May be targeting .net standard 2.1 brings module builder API https://docs.microsoft.com/ru-ru/dotnet/api/system.reflection.emit.modulebuilder

[zgramana]

Curious why this excellent work was based on such an old branch as opposed to, say, 8.1?

[timotei]

@zgramana Unfortunately we're using this version because trying to use it with Java 8 brings breaking changes (e.g., default implemented method) which we cannot afford right now. However, I might be able to give it a try to apply the changes on a newer branch, but can't promise anything as it's not primary focus.

[zgramana]

Interesting. I’ve used this PR as a guide to add support to master. I haven’t completed all of it yet, as I’m torn between replacing csc with exec + dotnet and just using the same approach you took.

I don’t think that I fully understood your comment about Java 8 breaking changes and “default implemented method”. Could you explain that in a little detail?

[VincentVk9373]

We have many dlls compiled from java6-7 on different projects and need them to be compatible together at runtime (dynamic loading). Switching only one of them to java8 means we need to have two different ikvm version at runtime, but also that we need a version of every dlls for both versions, but also that objects cannot be shared between both runtimes.

This was caused indirectly by the way default interfaces methods are handled, which makes interfaces runtime differ, so a class implementing an interface cannot be shared.