Using local image as base image does not work

I have a simple build process in place where a base image is built and tagged as "name:tag" where name is of the form "proj.name" and tag is a semver version.

When I run the publish to container with this base image specified I always receive an error microsoft.net.build.containers\0.1.8\build\Microsoft.NET.Build.Containers.targets(45,9): error : Could not parse FullyQualifiedBaseImageName: 0. The base image is being set through command line property like so: /property:ContainerBaseImage=name:tag

I'm at a loss at this point to understand what I'm doing wrong. Any help you can offer would be appreciated.

[baronfel]

There's a bunch of build logic happening, but what would help the most is a bin log of the publish operation. You can learn about them and how to have the publish command make them for you at aka.ms/binlog.

If that's not possible, then knowing the exact value specified for the ContainerBaseImage property would let us run the logic in the parse target to see what went wrong.

To start with, here's an example base image name I've just tested that runs into this issue: /property:ContainerBaseImage=proj.name.base:2022.1007.1. Note I also tried removing the dot separators, eg /property:ContainerBaseImage=projnamebase:202210071 and still had this problem.

Let me review the binlog to make sure I'm good to share that publicly.

[baronfel]

Ah, I have an idea. prepend docker:// to that ContainerBaseImage and see if that works.

What I think is happening here is that we use the ContainerBaseImage as the FullyQualifiedBaseImageName later on, and that fully-qualified name we expect to include the registry (as if you had written the base image in a dockerfile). However we do not cover the case where the registry portion is missing (where we should infer a local-daemon is storing the image).

Thanks for the suggestion, but that doesn't seem to work either. That said the error is different:

-p:ContainerBaseImage=docker://projnamebase:202210071:

 error MSB4018: System.UriFormatException: Invalid URI: Invalid port specified.
 error MSB4018:    at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind, UriCreationOptions& creationOptions) 
 error MSB4018:    at System.Uri..ctor(String uriString, UriKind uriKind) 
 error MSB4018:    at Microsoft.NET.Build.Containers.ContainerHelpers.ContainerImageToUri(String containerBase)
 error MSB4018:    at Microsoft.NET.Build.Containers.ContainerHelpers.TryParseFullyQualifiedContainerName(String fullyQualifiedContainerName, String& containerRegistry, String& containerName, String& containerTag) 
 error MSB4018:    at Microsoft.NET.Build.Containers.Tasks.ParseContainerProperties.Execute() 
 error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
 error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)

Now it seems to be trying to parse the version tag as a port number.

If it's helpful I can share the bin log, but would need to send it directly to you instead of posting it on this issue.

[baronfel]

I think we've got a good enough idea of what's going on here now. I think this scenario is fairly broken at the moment unless you do the following:

• prepend docker:// to your image name, and
• ensure that your tag is an int under the port limit

in other words, the workaround is horrible and bad and we should feel bad. We'll likely have to move away from piggy-backing on Uri-based validation for image names, which is a good thing to do, in order to unblock the scenario.

I actually don't know if that workaround works. I just tried with -p:ContainerBaseImage=docker://projnamebase:1 and I'm back to the original error I posted in the OP.

In any case, thanks for acknowledging. I know this is prerelease at the moment so no harm done. I'll look forward to a fix for this scenario.

[baronfel]

This is a pretty big scenario so we should try to unblock it before the next release (anticipated next week-ish?). Using a local image (possibly built from a local Dockerfile) is our escape hatch for when users have needs that this tech can't solve - for example needing to create a specific user via useradd or install packages via the system package manager. Right now we can't solve that need, which we should treat as a blocker.

[SeppPenner]

This is something I could also need. We have Docker containers that need to install some dependencies in order to be able to show PDF reports correctly (e.g. RUN apt-get install -y libc6-dev libicu-dev libharfbuzz0b libfontconfig1 libfreetype6 on Debian). Is there a new ETA when this might be testable?

[baronfel]

Hey, sorry about the delay here. We haven't solved this yet, and it's been on the back-burner a bit in favor of expanding our authenticated registry support and working on support for RIDs other than linux-64.

I think the main problem here is that local-Docker images have a different manifest and config format, and we'd need to teach the library how to translate between the formats.

[kimcuhoang]

Possible workaround:

1. Run a local registry

docker run -d -p 5000:5000 --restart=always --name registry registry:2

2. Build your own base image then push to this local registry

docker build -t localhost:5000/image-base:latest -f Dockerfile .

docker image push localhost:5000/image-base:latest

3. Configure your csproj file by

<PropertyGroup>
<ContainerBaseImage>localhost:5000/image-base:latest</ContainerBaseImage>
</PropertyGroup>