search

phmonte / Buildalyzer

A utility to perform design-time builds of .NET projects without having to think too hard about it.
MIT License
605 stars 95 forks source link

Use of Assembly.Location makes this incompatible with single file EXEs #214

Closed someguy20336 closed 1 year ago

someguy20336 commented 2 years ago

For a project I am working on, I was interested in trying out the single file EXE. Unfortunately, due to the use of Assembly.Location in at least one spot (which is incompatible with single file EXEs) causes the application to hang indefinitely while attempting to build the project out of process.

The output of the ProcessRunner shows the logger switch causes the build to fail, and apparently never return:

image

Of course, the workaround is to not do a single file EXE, but the single file feature is quite nice.

slang25 commented 2 years ago

One of the things Buildalyzer needs to do is to shell out to msbuild, passing the custom Buildalyzer.Logger assembly. So perhaps if the assembly location is null, there should be some logic to copy the assembly to a temporary location.

someguy20336 commented 2 years ago

I haven't worked with the single file EXE too much yet, but I wonder if there is a way to access the bundled (?) assembly via some "path". Or alternatively, extract a single bundled assembly. So far, no luck with just some simple Google searches. I haven't tested anything out yet, though.

daveaglick commented 2 years ago

Unfortunately, assembly loading can be tricky and the location of the logging assembly could be in a few places depending on platform, delivery, etc. That's why Assembly.Location works well here - it lets the code completely ignore how the logging assembly is linked and from where and relies on the runtime to do that and supply the information. It's probably possible to embed the logging assembly directly in the Buildalyzer NuGet kind of like an unmanaged library instead of relying on a transitive dependency to bring it in, and then we might be able to find it using NuGet APIs or some other mechanism.

All of that sounds like a non-trival amount of work and testing for a feature that's non-critical though. It's not that I'm opposed to the idea, it's just that priority-wise it falls pretty low on a list that I'm already struggling (and mostly failing) to keep up with.

TL;DR: I'd probably accept a PR as long as I had confidence it wouldn't create more problems down the road or on other platforms, but I'm unlikely to work on this myself.

someguy20336 commented 2 years ago

I wouldn't be offended if you just want to close this issue. I spent a little time trying to find a good way to do this and it just seems overly complicated for the simple workaround of "don't deploy as single file". Maybe some future advancements in single file deployments would make it worth revisiting later.

daveaglick commented 1 year ago

I'll close the issue for now given I'm unlikely to have the bandwidth for much further exploration, but if you (or anyone else) ends up with new information or a workaround, I'd be happy to reopen it.