I’ve mentioned the following bugs in a recent discussion related to Continua (just for reference).
As this bug has been explained before, I’ll keep it short.
The Finalbuilders Action ‘dotnet Test’ sets the value for
Configuration to the value of
Logger whenever present. Manually overriding the value (both in the XML file itself or via the Finalbuilder dialog) does not work. As long as
Logger is set, the value for
Configuration is the same.
My workaround is to call the dotnet command manually.
When I use the
dotnet Publish Action provided by Finalbuilder, my configuration results in the following command:
publish %NETCORE_PUBLISH_PROJECT_FILEPATH% --configuration %NETCORE_CONFIGURATION_NAME% --output %BUILD_OUTPUT_PATH% --self-contained false
Unfortunately this results in the following error:
NETSDK1102: Optimizing assemblies for size is not supported for the selected publish configuration
When executing manually without explicitly naming
publish %NETCORE_PUBLISH_PROJECT_FILEPATH% --configuration %NETCORE_CONFIGURATION_NAME% --verbosity minimal --output %BUILD_OUTPUT_PATH%
The publish works flawlessly. So yet again, my workaround is to call the dotnet command manually.
I don’t really understand why the dotnet command would behave in the way it does. To me leaving the option out is the same as explicitly stating
--self-contained false. Anyway the issue seems to come from this overy option.
The dotnet test issue was a ui field binding issue, just committed a fix for that.
With the publish action, we need to investigate this more. We actually explicitly added the
--self-contained false to deal with an issue with this before, so we need to trace back and find the original issue and see why that was done. It’s possible this is something that has changed behavior with different dotnet core releases.
I just looked at the documentation
Publishes the .NET runtime with your application so the runtime doesn’t need to be installed on the target machine. Default is true if a runtime identifier is specified and the project is an executable project (not a library project). For more information, see .NET application publishing and Publish .NET apps with the .NET CLI.
If this option is used without specifying true or false, the default is true. In that case, don’t put the solution or project argument immediately after --self-contained, because true or false is expected in that position."
So it almost seems like this is a tri-state option - more investigation needed.
Do you have PublishTrimmed somewhere in your csproj?
The project I am having trouble publishing is of type Blazor WebAssembly.
As far as I understand, the publishing involves some compression and shipping the required dontet runtime by default (I can only post two links cuz I’m a new member: MSDocs → Aspnet → Core → Blazor → Overview → WebAssembly).
If I understand this article correctly trimming is enabled “by default”. Shipping the runtime is needed hence it will be executed in the browser.
Normally I understand a CLI option as follows:
- Specify the option i.e.
--self-contained to set it to true
- Option is not specified i.e. the option not specified is set to false
- Specify the value for the option i.e. c will set it as such
I would think setting
--self-contained false is the same as not using
--self-contained. However not using this option causes the publish to fail.
I could set the
false in my
csproj file. But this is not how Blazor is intended to be published…
We have changed this action for the next update so you can specify
default (don’t supply the option)
This build has the changes
We will have an official update out soon, just working on a few other changes around unit test action/continua integration.