error NETSDK1064: Package DnsClient, version 1.2.0 was not found about containerregistry

[toddysm]

@bbehling Looking at the output, this doesn't seem to be a problem with the image but it looks to me more of an issue with the dependencies you have in the *.csproj file. The way I understand the error is that the package is not anymore in the local folder (i.e. it is not installed) and this may be the result of the restore operation.

Posting the project file may be helpful.

cc: @MichaelSimons who can provide more insights

[MichaelSimons]

@bbehling - I see the package does exist on NuGet. Is this something that worked in the past and now just started failing or is this a new Dockerfile you are trying to build?

This does not appear to be related to MCR so I would recommend closing this particular issue. This looks like a question well-suited for StackOverflow. The StackOverflow audience is much larger and you will have better luck getting a good answer there.

[bbehling]

Hi.

I did post this on github and another user commented he was having the same problem.

Yes, the restore command was working February 1st when I published this API to AWS EB.

I narrowed the problem down to running
RUN dotnet restore

If I do not restore, the docker image will build. Note, that outside of docker, I can run the restore command which works.

Here is the content of my .csproj file. There isn't a dependency to the DnsClient library. However, maybe the MongoDB driver requires it because the DnsClient.dll exists in the release directory after building.

netcoreapp3.1

Thank you

[toddysm]

@bbehling I don't think the .cproj file went through. Also, can you link to the other issue you mentioned above?

[toddysm]

@bbehling As @MichaelSimons suggested, this may be a question for StackOverflow. Because this is not related to problems with Microsoft Container Registry, I will close the issue by the end of the week. Please let me know if you have any concerns with that.

[bbehling]

Here is the csproj file.

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="MongoDB.Driver" Version="2.10.1" />
    <PackageReference Include="Newtonsoft.Json" Version="12.0.3" />
  </ItemGroup>


</Project>

[bbehling]

This is the issue I opened on stackoverflow.
https://stackoverflow.com/questions/61167032/error-netsdk1064-package-dnsclient-1-2-0-was-not-found

A few other people are having issues with the Microsoft Container Register. Since others are having similar issues, seems it's possible this could be an issue with MCR.

[toddysm]

@bbehling MCR only serves container images. The problem you are facing is that the dotnet build command which is run while you are building your image fails because the the DnsClient is not available. The DnsClient is fetched from NuGet and not MCR.

The StackOverflow post has a suggestion to use the --no-cache option, which you may want to try.

However, looking deeper into your error above, I would also suggest digging more into following:
Failed to build Docker image aws_beanstalk/staging-app: ximum path length restrictions.
As the error suggests, the issue may be because the path is too long and that is why the build fails. You may need to do ls for all the folders recursively to troubleshoot the path lengths.

Also, make sure the project builds properly outside an image before building the image.

Once again, because this doesn't seem to be an issue with pulling images from MCR, we will proceed with closing it by the end of the week.

[bbehling]

@toddysm One of the troubleshooting steps I did take was to build the application outside of Docker which built successfully.

Also, as I posted, this error maximum path restrictions does not just occur in AWS Beanstalk. This is the error thrown when building the Docker image locally as well.

So if this is not a Docker or MCR related issue, what is the explanation and cause of this issue? The Docker file was copied from Microsoft’s own tutorial, and failed to build between the Dates of this post, and apparently according to the another stackoverflow post, up to April 29th.

[bariscaglar]

This is not an issue related to MCR. MCR is the distribution mechanism for the container images.