Open nwoolls opened 7 months ago
FWIW, digging down into the folder structure, it seems like the .NET runtime is being included with your package. This doesn't seem to be the case for other .NET tools I have installed (e.g. MS LibMan CLI).
Edit: I mis-spoke. That's actually the V8 runtime. I'm assuming if the image already has Node.js installed, it may be preferable to use the original WebCompiler project?
Edit 2: The original project and other forks don't seem to be maintained and / or do not have a .NET tool. It seems like your tool install includes runtimes for 8 platforms - can this install just the active platform instead? Either automatically or with dotnet tool install —arch
? It also seems to install versions for .NET 6, 7, and 8, even when specifying --framework net8.0
.
Hi @nwoolls,
That's certainly not a perfect solution, as it pollutes the docker image with quite some unnecessary stuff. However, it's also quite inconvenient to split the package into multiple platform-dependent ones.
I don't see a great, convenient and lean solution. If you find one, please let me know.
In the meantime, I suggest trying to just delete unnecessary DLLs and folders after the install command, which should help with the docker image size issue.
I can't recommend using the entirely unsupported original webcompiler project. If I were you, I'd instead consider using a non-dotnet and non-VS build chain for all web assets (using the JavaScript stack).
Best, Stefan
Sorry if this has been addressed - I didn't see any note of this.
We are working on the size of our Docker build images and noticed this tool adds 1.2GB to the image.
This can be seen by checking the size of
~/.dotnet/tools/.store/excubo.webcompiler
. The NuGet package alone is 243MB.What is causing this? Is this on the radar of the author(s)?