.NET 6 WinForms PublishSingleFile w/merging support?

.NET 6 greatly improves the single file support over what .NET Core 3 offered.

When using dotnet publish -p:PublishSingleFile=true
as described here: https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file/overview

I am able to get a single file exe.
Our main app dll is merged with our satellite dll's and protected properly, and used in the single file exe.
However, our satellite dll's are also packaged in the exe in unprotected forum.

Is there a way to fix this or plans to resolve this in the future?

Deploying a single .exe for us is greatly preferred over deploying an .exe, .dll, and two .json's
Tagged:

Answers

  • I don't believe Smart Assembly's support of single file executables has changed since .NET Core 3, however I think what you're describing was covered by that also.

    Does this guide differ from your present workflow please? 

    https://documentation.red-gate.com/sa/building-your-assembly/using-smartassembly-with-single-file-executables-net-core-3

    Kind regards
    Peter Laws | Redgate Software
    Have you visited our Help Center?
  • SamanthaJSamanthaJ Posts: 7 Bronze 1
    .NET 3 single file exe's are much different than .NET 6.

    In .NET 3, the exe is really a self extracting file that extracts the contents (dll's, etc..) to a temporary folder and runs it from there.

    In .NET 6, it is a truly bundled and self contained file.

    We have found a "temporary" solution to deploy SmartAssembly protected .NET 6, single file exe's.

    In your SA project, merge/embed the assemblies required.

    Set your target to replace the dll in the obj folder (this is key as the obj folder file is used for publishing)

    Add this to all of your ProjectReferences in your .csproj file:
    <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
    This is key to keep your unprotected assemblies from being packaged together in your single file .exe


    Publish with this:
    dotnet publish "My Project.csproj" -p:PublishSingleFile=true -c $(Configuration)


  • Thank you for explaining, is it a temporary solution due to how manual it is and a smoother workflow would be prefered? (perfectly reasonable) or is there some missing functionality please?

    Kind regards
    Peter Laws | Redgate Software
    Have you visited our Help Center?
  • SamanthaJSamanthaJ Posts: 7 Bronze 1
    Well, the smoothest workflow is if SmartAssembly could produce the .exe the same way dotnet publish does. I don't know of an elegant way the SA dev team would accomplish this though. Publishing modern dotnet is quite a complex process as so many diverse platforms are now supported.

    The problem right now is that if the consumer of your product isn't super careful and tries to publish a single file exe, the unprotected assemblies will be embedded into the final product along side the properly protected assembly.

    Fortunately your documentation has a proper warning about this in the .NET 3 Single File Executable ref: https://documentation.red-gate.com/sa8/building-your-assembly/using-smartassembly-with-single-file-executables-net-core-3

    But a new page for .NET 5 and .NET 6 should probably also be made.

    The documentation could be expanded though to indicate that if you use dotnet publish, the unprotected assemblies will be packged into the final exe.

    Another risk is that if a consumer of your product ever modifies their solution by adding more internal assemblies, and they forget to edit the .csproj file to add ExcludeFromSingleFile, those assemblies will then be packaged in the final result unprotected.

    Furthermore, if your users don't know how to use ilspy, and other various tools to validate their results, they could be publishing unprotected source unknowingly.

    Hence, the safest way is if SA can natively produce single file exe's in a similar way that dotnet publish does.



  • Peter_LawsPeter_Laws Posts: 273 Silver 2
    edited August 30, 2022 2:32PM
    Thanks for talking me through it, now I have a better understand I spoke to our developers about it, it's not something we're looking to incorporate soon due to the degree of reworking this would require of the build task.

    We'll retain the feature request however for future use, I'm sorry we don't have a better answer for you.
    Kind regards
    Peter Laws | Redgate Software
    Have you visited our Help Center?
Sign In or Register to comment.