Dotnet Build and dotnet Publish: error MSB4803

FinalBuilder Discussion
1

I have a .NET solution that targets .NET 7 and I can compile the solution without any errors, but when I use the dotnet Build action, I get the following error:

C:\Program Files\dotnet\sdk\7.0.403\Microsoft.Common.CurrentVersion.targets(3441,5):
error MSB4803: No se admite la tarea “LC” en la versi├│n de MSBuild de .NET Core. Use la versi├│n de MSBuild de .NET Framework.
Vea ResolveComReference Task - MSBuild | Microsoft Learn para obtener más información.
[C:.NET\Clientes\Dispreu\DanoneEdiOrder\DanoneEdiOrder\DanoneEdiOrder.csproj]

Apart from problems FB has with accented letters, I get a MSB4803 error. I can’t see what is causing the trouble and hoped you might be able to throw some light on the problem.

I have the following properties defined in the action:
Project = Qualified path to my solution file
Working directory = Qualified path the output folder
Configuration = Release

2

Hi Martin

If you run the dotnet publish from the command line do you see the same error?

3

Hello Vincent:
No, the command run from the command line (Developer prompt) work fine:

  • dotnet build --configuration Release --framework net7.0-windows
  • dotnet publish --configuration Release --framework net7.0-windows --runtime win-x64 --no-self-contained

Results:

C:\.NET\Clientes\Dispreu\DanoneEdiOrder>dotnet build --configuration Release --framework net7.0-windows
Versión de MSBuild 17.7.3+4fca21998 para .NET
  Determinando los proyectos que se van a restaurar...
  Todos los proyectos están actualizados para la restauración.
  EdiClassLibrary -> C:\.NET\Clientes\Dispreu\DanoneEdiOrder\EdiClassLibrary\bin\Release\net7.0-windows\EdiClassLibrary
  .dll
  EdiClassLibrary -> C:\.NET\Clientes\Dispreu\DanoneEdiOrder\EdiClassLibrary\bin\Release\net7.0-windows\EdiClassLibrary
  .dll
  DanoneEdiOrder -> C:\.NET\Clientes\Dispreu\DanoneEdiOrder\DanoneEdiOrder\bin\Release\net7.0-windows\DanoneEdiOrder.dl
Compilación correcta.
    0 Advertencia(s)
    0 Errores
Tiempo transcurrido 00:00:00.77
------------------------------------
C:\.NET\Clientes\Dispreu\DanoneEdiOrder>dotnet publish --configuration Release --framework net7.0-windows --runtime win-x64 --no-self-contained
Versión de MSBuild 17.7.3+4fca21998 para .NET
  Determinando los proyectos que se van a restaurar...
  Se ha restaurado C:\.NET\Clientes\Dispreu\DanoneEdiOrder\EdiClassLibrary\EdiClassLibrary.csproj (en 221 ms).
  Se ha restaurado C:\.NET\Clientes\Dispreu\DanoneEdiOrder\DanoneEdiOrder\DanoneEdiOrder.csproj (en 348 ms).
  EdiClassLibrary -> C:\.NET\Clientes\Dispreu\DanoneEdiOrder\EdiClassLibrary\bin\Release\net7.0-windows\win-x64\EdiClas
  sLibrary.dll
  EdiClassLibrary -> C:\.NET\Clientes\Dispreu\DanoneEdiOrder\EdiClassLibrary\bin\Release\net7.0-windows\win-x64\publish
  \
  EdiClassLibrary -> C:\.NET\Clientes\Dispreu\DanoneEdiOrder\EdiClassLibrary\bin\Release\net7.0-windows\EdiClassLibrary
  .dll
  DanoneEdiOrder -> C:\.NET\Clientes\Dispreu\DanoneEdiOrder\DanoneEdiOrder\bin\Release\net7.0-windows\win-x64\DanoneEdi
  Order.dll
  DanoneEdiOrder -> C:\.NET\Clientes\Dispreu\DanoneEdiOrder\DanoneEdiOrder\bin\Release\net7.0-windows\win-x64\publish\

Here is the Final Builder Log:
FinalBuilderLog.zip (3.0 KB)

4

Please also note that the accented words in the Log are not treated correctly by FB.
I’m using FB version 8.0.0.3310

5

The log is working as expected, what is not working is the stdout encoding when capturing the process output. I am able to reproduce this here. I’m using windows 11, I know this worked perfectly before so not sure if it’s windows 11 that broke it or not (will need to test on earlier OS versions).

As for the dotnet build/publish error, I really have no idea. The error makes no sense and I have not been able to reproduce it here.

6

Hi Martin

After further research, it has nothing to do with the windows version. The issue is that the dotnet tool outputs utf-8 to the console. In windows, when capturing stdout/stderr, there is really no way to determine which encoding was used - you just get a byte stream. The byte stream does not contain a preamble (it’s not a file) - so inspecting the bytes doesn’t really help either.

In FinalBuilder, we default to using the OEM codepage - as a best guess - and this has worked well for many years.

I have changed the encoding used for the dotnet actions to UTF-8, however I am unable to test it as I haven’t figured out how to get dotnet to output anything that is not also ansi. I have however tested with other processes that output utf-8 and this change worked for them.

I have stopped short of making the default encoding for all actions UTF-8 - that is something that we’ll need to investigate further.

This build includes the changes to the dotnet actions.

https://downloads.finalbuilder.com/downloads/finalbuilder/800/FB800_3315.exe

7

Thanks Vincent.
Good news, the log encoding works perfectly.
I also upgraded my Visual Studio 2022 to version 17.8 (with .NET 8) and the problem with the compilation under dotnet actions works just fine! I have no idea why, but it just works!
Thanks for your help.
Martin.