Add basic support for netcore

[yyjdelete]

Fix #58, fix #106

[yyjdelete]

Not sure what's the right way to create an PR with submodule? Or should I work on 2.0 branch which use dnlib from NuGet?
The new version of dnlib can be get from https://github.com/yyjdelete/dnlib/tree/master . Some unnessary changes in ConfuserEx branch of dnlib is revert, now the only difference with https://github.com/0xd4d/dnlib is:

1. RecursionCounter and GenericArguments is changed to public;
2. yyjdelete/dnlib@405742a;

LIMITED:

1. Path of Microsoft.NETCore.App(.Ref)/Microsoft.AspNetCore.App(.Ref) should be added to Probe Paths manually;
2. Packer: compressor only works on compat mode due to not LoadModule is not support in netcore. And all packed dlls(except the main executable one) should be removed from runtime nodes of xxx.deps.json

<packer id="compressor">
  <argument name="compat" value="true" />
</packer>

3. Not tested on old frameworks, not sure whether is broken or not.
4. Renamer may broken netcore>=3.0 due to For renamer, space(\u0020) is not an vaild name when used as first char in fullname of type or name of nested type #192

[AppVeyorBot]

❌ Build ConfuserEx 408 failed (commit 3534876d74 by @yyjdelete)

[yyjdelete]

Seems CI use VS2017, and not support C#8.0 used by new version of dnlib. Maybe move to official nupkg of dnlib like release/2.0 already does?

[AppVeyorBot]

✅ Build ConfuserEx 412 completed (commit 490e257f31 by @yyjdelete)

[mkaring]

Adding this line without any conditions will break resolving the assemblies when mixing .NET 2.0, .NET 3.5 and .NET 4 assemblies in the same project. Means if you have a .NET 3.5 assembly as the dependency of a .NET 4 assembly, the referenced assemblies will not resolve properly, because the mscorlib version changes. This works during runtime, because the .NET rumtime redirects mscorlib 3.5 to mscorlib 4.0. The line you added, disables this functionality for dnlib.

[yyjdelete]

Will test this and reference netfx dll in netcore later, still not sure what will happen in this case. Is there any actual issue for the case can be tested?
The option is needed for netcore, otherwise something like System.Runtime 4.2.2 will be changed to 4.0.0 by FrameworkRedirect.ApplyFrameworkRedirect(), and then it will perfer the one in GAC as extra match instead of netcore.
Since FindExactMatch is still false, it can match mscorlib 4.0 if 3.5 is not found.And what will happen if resolve 3.5 for 3.5 and 4.0 for 4.0 side by side, if reference assembly don't needed to be confused, since they should be api compatable to executed.

[mkaring]

I don't understand why this is added? Why is the oath completely stripped in case the path is rooted? If the path is still rooted at this point, it only means that the output path has no relative relation to the location of the project. That is perfectly valid.

[yyjdelete]

@mkaring
All usesite of context.OutputPaths[i] look like Path.Combine(context.OutputDirectory, context.OutputPaths[i]) or Path.Combine(tmpDir, context.OutputPaths[i]), if context.OutputPaths[i] is an fullpath, it will get the same path as input, and makes the input file will be overwrite by output data.

[mkaring]

Seems CI use VS2017, and not support C#8.0 used by new version of dnlib. Maybe move to official nupkg of dnlib like release/2.0 already does?

We can just switch the CI to VS2019. That is not an issue.

[AppVeyorBot]

✅ Build ConfuserEx 413 completed (commit 567605b9c4 by @yyjdelete)

[KvanTTT]

Maybe it makes sense to update dnlib via the separated pull request? Also, I've created an issue for that: #208

[NotoriousRebel]

Any updates?

[yyjdelete]

@NotoriousRebel
No longer have time to work with that recently. You can use code from this PR, I hope most function should works.

Fell free to close this PR.