microsoft / AttackSurfaceAnalyzer

Attack Surface Analyzer can help you analyze your operating system's security configuration for changes during software installation.
MIT License
2.73k stars 277 forks source link

Single portable .exe #29

Open gfs opened 5 years ago

gfs commented 5 years ago

Is your feature request related to a problem? Please describe. The folder with the executable is cluttered.

Describe the solution you'd like Have the build output a single .exe or equivalent that can be run standalone.

Describe alternatives you've considered Have tried warp-packaging, and CoreRT. Neither suited our needs.

System Configuration (please complete the following information):

scovetta commented 5 years ago

Alternatively, a directory structure where all of the supporting files were stored in a separate directory, like:

attack_surface_analyzer.exe
readme.txt
resources\
   resources\foo.dll
   resources\bar.dll
   …

I think this would be fine too.

gfs commented 5 years ago

As a stopgap we could make a .bat/.sh file that just runs "resources\AttackSurfaceAnalyzer.exe", and put everything into the resources directory.

scovetta commented 5 years ago

That would certainly work for me.

gfs commented 5 years ago

I saw that this is going to be a native feature of .NET Core 3, at least on Windows platforms.

I did experimentally create the running scripts, checked in in the Cli directory, but haven't fully tested that everything works with them (for example, I suspect the Compare command may not because it needs to load Output.cshtml from the filesystem).

gfs commented 5 years ago

Unfortunately the .NET Core 3.0 approach is basically the warp packer approach, which is not desirable for our use case. Further minor experiments with other ILMerge type approaches haven't been successful either.

gfs commented 4 years ago

The best workaround for now is to first install .NET Core and then run

dotnet tool install Microsoft.CST.AttackSurfaceAnalyzer.CLI

See nuget.org

gfs commented 4 years ago

This should be possible in .NET 5.

https://devblogs.microsoft.com/dotnet/introducing-net-5/

gfs commented 4 years ago

Depends on https://github.com/dotnet/runtime/issues/36590 in .NET 5.

dotnet publish -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesInSingleFile=true

dotnet publish -r linux-x64 /p:PublishSingleFile=true

Fabi commented 4 years ago

Depends on dotnet/runtime#36590 in .NET 5.

dotnet publish -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesInSingleFile=true

dotnet publish -r linux-x64 /p:PublishSingleFile=true

Note that native binaries are still extracted to the Temp folder if bundled into a single binary. Otherwise they are placed in the same directory

gfs commented 4 years ago

@fabi that is the implementation in .net core 3.1 which is why we are not using it currently.

In the issue linked this is addressed in .NET 5

Can run managed components of the app directly from bundle, without need for extraction to disk.

Fabi commented 4 years ago

@Fabi that is the implementation in .net core 3.1 which is why we are not using it currently.

In the issue linked this is addressed in .NET 5

Can run managed components of the app directly from bundle, without need for extraction to disk.

Thats why I write native binaries :) Managed are directly executed, native are always extracted.

gfs commented 4 years ago

I understand now the distinction you are drawing. It sounds like it may still need to extract native binaries. Thanks for the extra info!