Fix compression bug by removing unnecessary Flush() call

[KingKDot]

The Flush() call on DeflateStream doesn't guarantee complete compression and can cause embedded DLLs to fail until project rebuild. Removing it ensures proper compression on first build.

Description of Change

Fix compression bug by removing unnecessary Flush() call

Issues Resolved

• fixes Somehow changing Assembly Version to 1.6.3 breaks costura? #1050

API Changes

None

None

Behavioral Changes

None

Testing Procedure

I couldn't even figure out how to run the tests because I didn't have the MSBuild SDK but the issue was so small that I don't believe tests are needed (or you can run them as well).

PR Checklist

• I have included examples or tests
• I have updated the change log or created a GitHub ticket with the change
• I am listed in the CONTRIBUTORS file (if it exists)
• Changes adhere to coding standard
• I checked the licenses of Third Party software and discussed new dependencies with at least 1 other team member

[rc0n9027]

I have that problem too.

[umbrageodotus]

Same problem with me.

[GeertvanHorrik]

I think it's not the flush call, it might be the bool to leave the stream open. I will try to look into this with full context in mind (why is the stream being left open) as soon as I can.

edit I noticed that the non-compression write does not flush. Will try to check this as soon as I have time.

[KingKDot]

I think it's not the flush call, it might be the bool to leave the stream open. I will try to look into this with full context in mind (why is the stream being left open) as soon as I can.

edit I noticed that the non-compression write does not flush. Will try to check this as soon as I have time.

Thank you for offering to look into it. As of right now for a temp fix removing the flush call fixes it but you definitely know the project better than me.

[KingKDot]

@GeertvanHorrik any news?

[KingKDot]

@GeertvanHorrik now, on my newest build I'm getting the bad image exception but I still have the compression turned off so I'm not sure anymore. It only happens to 1 dll though which is another project that it's linking and NOT a nuget package.

[GeertvanHorrik]

@GeertvanHorrik now, on my newest build I'm getting the bad image exception but I still have the compression turned off so I'm not sure anymore. It only happens to 1 dll though which is another project that it's linking and NOT a nuget package.

Are you sure you are embedding the right platform (x86, x64, arm64) and running in the right runtime? It would be best if we have a repro so we can actually write unit tests around this and make sure it never happens again (if Costura is to "blame" at all).

[KingKDot]

@GeertvanHorrik now, on my newest build I'm getting the bad image exception but I still have the compression turned off so I'm not sure anymore. It only happens to 1 dll though which is another project that it's linking and NOT a nuget package.

Are you sure you are embedding the right platform (x86, x64, arm64) and running in the right runtime? It would be best if we have a repro so we can actually write unit tests around this and make sure it never happens again (if Costura is to "blame" at all).

They're all set to ANYCPU and to prefer 64bit. If you'd like, I can get the exact commit that shows where it's broken vs fixed in my own repo. Would that suffice?

[GeertvanHorrik]

Please provide the commit (link if repo is OSS), then I will check it out.

[KingKDot]

So far it seems to only be happening to me now (I promise it was happening to other people before as well.)

https://github.com/Quasar-Continuation/Poopsar

This is the repo.

I built the same exe twice and got 2 different sized outputs each time. I did

dotnet nuget locals all --clear

and then rebuilt the project and that's what happened. The compression/bundling is failing on Pulsar.Common which is another project included all in the same .sln.

I'm going to try disabling compression to see if it solves the issue.

[KingKDot]

@GeertvanHorrik I tried without compression as well and I still get the same issue with occasional different file sizes.

[KingKDot]

The github action however seems to build everything just fine and it's all useable. I tried clearing all nuget pacakges, all build stuff, reinstalled visual studio, reinstalled all my .net framework and core packages and the runtimes/sdk's themselves.

[KingKDot]

I should also say, out of the 3 environments I tested, both windows 10 environments worked just fine, and others I've asked said it works just fine on windows 11 so I have no idea what could possibly be wrong at this point.