How to absolutely prevent SA from touching a certain class

timothyptimothyp Posts: 13 Bronze 1
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.

Tagged:

Comments

  • timothyptimothyp Posts: 13 Bronze 1
    edited May 4, 2017 4:37AM
    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)
    
  • Russell DRussell D Posts: 1,324 Diamond 5
    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?
    Have you visited our Help Centre?
  • timothyptimothyp Posts: 13 Bronze 1
    Can this conversation be turned private?
  • timothyptimothyp Posts: 13 Bronze 1
    Or can I send it to you by other means?
    I can tell you that before and after are quite different.
  • Russell DRussell D Posts: 1,324 Diamond 5
    Hi timothy,

    I've sent you an email from our file server.
    Have you visited our Help Centre?
  • timothyptimothyp Posts: 13 Bronze 1
    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.

  • Russell DRussell D Posts: 1,324 Diamond 5
    No problem @timothyp, thanks for updating us.
    Have you visited our Help Centre?
Sign In or Register to comment.