JetBrains/Refasmer

Produced reference assemblies do not contain some elements that affect compilation behaviour.

Closed this issue ยท 6 comments

Hi,

I would like to use Refasmer to generate reference assemblies when they are missing, and also in some cases to trim down standard reference assemblies.

However, based on https://github.com/dotnet/docs/blob/main/docs/standard/assembly/reference-assemblies.md , it looks that standard reference assemblies can contain elements that Refasmer assemblies do not (without specifying a custom filter).
Could you comment on how strictly Refasmer follows the standard ref assembly behaviour, and which version of it?
Is it known to have limitations?

As an example, please see this issue: dotnet/runtime#16402
It discusses why private struct fields must be included.

I tested this and confirmed that private struct fields are included in the standard reference assemblies, but not in assemblies generated by Refasmer.

The below two code versions produce different standard reference assemblies, but the same Refasmer assembly:

Version 1

namespace private_struct_field;
public struct PublicStruct
{
    private int PrivateInt;
    public int PublicInt;
}

Version 2:

namespace private_struct_field;
public struct PublicStruct
{
    private int PrivateInt;
    private int PrivateInt2;
    public int PublicInt;
}

Refasmer command used:

refasmer -v -O refasmer_publicandinternal -c .\private_struct.v1.dll .\private_struct.v2.dll --internals

@mfilippov you can use this PR to fix the problem. All fields are imported for System.ValueType inheritors.
#21

Closed by #21.

Thanks for taking the time!

Could you comment on how strictly Refasmer follows the standard ref assembly behaviour, and which version of it?
Is it known to have limitations?

Is the answer to the above:
"There is no guarantee it follows the standard behaviour, but the current behaviour seems to work most of the time, please report if you find out otherwise."?

I'm trying to figure out how comfortable I should feel to make use of it in production.

I've confirmed with the team that we strive to follow the rules of the standard ref assembly generation.

There's no strict guarantee, but any derivation from the standard will be considered as a bug, so please report those.

Thanks. Would it be possible to publish a NuGet release with this fix?

Done!