How can we help you today? How can we help you today?

How to absolutely prevent SA from touching a certain class

There is one class in our project which really shouldn't be touched by SmartAssembly at all,
because as soon as it does, for some reason, it completely breaks that class.

We have configured the SA project to exclude this class from anything SA might do to it,
we have added all the attributes we could find:
[DoNotObfuscateControlFlow]
    [DoNotObfuscateType]
    [DoNotPruneType]
    [DoNotSealType]
    [StayPublic]
    [DoNotEncodeStrings]
    [DoNotMove]
    [DoNotObfuscate]
    [DoNotObfuscateControlFlow]
    [DoNotPrune]

We have moved that single file to a separate assembly (which we still have to merge because
of the other assemblies that are merged) and told SA to leave it alone, yet every time after building
the project we find the class has been modified anyway.

timothyp
0

Comments

7 comments

  • timothyp
    So basically we have a class called `ExportedArchive` which has a few methods.
    After obfuscation all but one method works without issues.

    The one that fails is called `ImportAsync` and no matter what attributes we
    add or what we configure in SA, the code is always obfuscated to this:

    public static async Task ImportAsync(string inputFilename, string targetDirectory, DeviceClient deviceClient, //more ...)
    {
        ExportedArchive.<ImportAsync>d__10 variable = new ExportedArchive.<ImportAsync>d__10();
        AsyncTaskMethodBuilder asyncTaskMethodBuilder = new AsyncTaskMethodBuilder();
        Task task;
        try
        {
            variable.inputFilename = inputFilename;
            variable.targetDirectory = targetDirectory;
            variable.deviceClient = deviceClient;
            variable.container = container;
            variable.FileImportedCallback = FileImportedCallback;
            variable.progress = progress;
            variable.cancellationToken = cancellationToken;
            variable.<>t__builder = AsyncTaskMethodBuilder.Create();
            variable.<>1__state = -1;
            asyncTaskMethodBuilder = variable.<>t__builder;
            asyncTaskMethodBuilder.Start<ExportedArchive.<ImportAsync>d__10>(ref variable);
            task = variable.<>t__builder.Task;
        }
        catch (Exception exception)
        {
            .(exception, variable, asyncTaskMethodBuilder, inputFilename, targetDirectory, deviceClient, container, FileImportedCallback, progress, cancellationToken);
            throw;
        }
        return task;
    }
    

    And we really need it to remain untouched by SA.

    When running the obfuscated version the exception information is
    ExportedArchive.<ImportAsync>D__10.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndebuggerNotification(Task task)
    at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
    
    timothyp
    0
  • Russell D
    Hi @timothyp, from what you've shown here it's not immediately obvious that SA has touched it, can you show us the IL for the method before SA processing and after?
    Russell D
    0
  • timothyp
    Can this conversation be turned private?
    timothyp
    0
  • timothyp
    Or can I send it to you by other means?
    I can tell you that before and after are quite different.
    timothyp
    0
  • Russell D
    Hi timothy,

    I've sent you an email from our file server.
    Russell D
    0
  • timothyp
    Hi,
    Extracting the requested information and preparing that to upload made me think
    about the problem and after I sent it I realized what was really going on.

    Turns out the issue does indeed happen with SA enabled,
    but it's not caused by SA. In fact it was caused by a rookie mistake on our end.
    Assuming a call was being awaited while in fact it wasn't. Debug and normal release
    builds always worked by accident, timing differences with the SA enabled version caused
    the bug to pop up, but that's entirely our fault.

    My apologies for the inconvenience.

    timothyp
    0
  • Russell D
    No problem @timothyp, thanks for updating us.
    Russell D
    0

Add comment

Please sign in to leave a comment.