msbuild suceeded for net48 and net462 solutions but no dll files generated

[shikhar456]

Describe the Bug

Hi,

I have this issue inside docker image mcr.microsoft.com/dotnet/framework/sdk:4.8 where when I do msbuild with a completely boiler plate F# console application net462 and net48 I get a result saying "Build Succeeded" but I get no dll files inside the bin folder.

msbuild creates dll without any issues if I use the msbuild present on my computer.

Steps to Reproduce

Build the docker image inside the following repo: https://github.com/shikhar456/ConsoleApplication1

Other Information

Issue raised with F# and they directed me here: https://github.com/dotnet/fsharp/issues/15878

Output of docker version

Client: Cloud integration: v1.0.35-desktop+001 Version: 24.0.5 API version: 1.43 Go version: go1.20.6 Git commit: ced0996 Built: Fri Jul 21 20:36:24 2023 OS/Arch: windows/amd64 Context: default

Server: Docker Desktop 4.22.0 (117440) Engine: Version: 24.0.5 API version: 1.43 (minimum version 1.24) Go version: go1.20.6 Git commit: a61e2b4 Built: Fri Jul 21 20:35:10 2023 OS/Arch: windows/amd64 Experimental: false

Output of docker info

Client: Version: 24.0.5 Context: default Debug Mode: false Plugins: buildx: Docker Buildx (Docker Inc.) Version: v0.11.2-desktop.1 Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe compose: Docker Compose (Docker Inc.) Version: v2.20.2-desktop.1 Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe dev: Docker Dev Environments (Docker Inc.) Version: v0.1.0 Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe extension: Manages Docker extensions (Docker Inc.) Version: v0.2.20 Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe init: Creates Docker-related starter files for your project (Docker Inc.) Version: v0.1.0-beta.6 Path: C:\Program Files\Docker\cli-plugins\docker-init.exe sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.) Version: 0.6.0 Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe scan: Docker Scan (Docker Inc.) Version: v0.26.0 Path: C:\Program Files\Docker\cli-plugins\docker-scan.exe scout: Command line tool for Docker Scout (Docker Inc.) Version: 0.20.0 Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server: Containers: 1 Running: 0 Paused: 0 Stopped: 1 Images: 19 Server Version: 24.0.5 Storage Driver: windowsfilter Windows: Logging Driver: json-file Plugins: Volume: local Network: ics internal l2bridge l2tunnel nat null overlay private transparent Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog Swarm: inactive Default Isolation: hyperv Kernel Version: 10.0 19045 (19041.1.amd64fre.vb_release.191206-1406) Operating System: Microsoft Windows Version 22H2 (OS Build 19045.3324) OSType: windows Architecture: x86_64 CPUs: 12 Total Memory: 15.69GiB Name: AUPERWL01107 ID: 0de6a27e-cb6c-4471-b871-5715f091e494 Docker Root Dir: C:\ProgramData\Docker Debug Mode: false Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false Product License: Community Engine

[mthalman]

[Triage]

This is the key bit of info: https://github.com/dotnet/fsharp/issues/15878#issuecomment-1706335506. The F# workload is not installed in the SDK. The workload name is Microsoft.VisualStudio.Component.FSharp.MSBuild

The workload's size is unknown. That should be determined first before adding it.

[MichaelSimons]

@lbussell, Can you please investigate the size and include it here?

[MichaelSimons]

To provide some additional background on what goes into the decision making process on what is included in the SDK images and what isn't. Our philosophy is to include the common set of workloads that generally satisfies a broad set of use cases. For use cases outside of this, it is expected customers will add the additional workloads/components they need on top of the .NET images. Without this approach, the .NET images could grow rather uncontrollably and therefore would become more undesirable for a lot of customers.

Regarding the F# workload specifically, there have only been one other request for it (https://github.com/microsoft/dotnet-framework-docker/issues/762)

[lbussell]

@shikhar456, I was able to reproduce the issue using your repo.

Adding the Microsoft.VisualStudio.Component.FSharp.MSBuild VS Workload to the mcr.microsoft.com/dotnet/framework/sdk:4.8 image does not make the build work with the existing Dockerfile, however the error message is more helpful. It still needs a NuGet restore.

Try replacing your RUN msbuild ConsoleApplication1.sln instruction with:

RUN dotnet restore && dotnet publish ConsoleApplication1.sln -c Release -o out --no-restore

Which then outputs ConsoleApplication1.exe to the out folder. This should work even without installing the F# workload. You can look at our dotnetapp sample Dockerfile for an example of how to apply this pattern if you're trying to containerize your Fsharp app.

@MichaelSimons: Can you please investigate the size and include it here?

It's a ~216 MB or roughly 5% increase on top of the .NET Framework SDK's image layers. @KevinRansom, is the F# Workload the most optimal way to add F# to a .NET Framework build image? Would there be any issue just relying on NuGet restore for this? How can we improve the UX that @shikhar456 is running into above? (no msbuild output).

[lbussell]

[Triage] Closing this as not planned since adding the FSharp Workload does not address the issue. Our guidance is to use the dotnet CLI which is included in the .NET Framework SDK images. It would be up to the FSharp team to improve the UX of the error message in this situation.