**ERROR** Error searching project for library "System.Drawing.Common"

[jwfx]

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?

{
   "name": "MindSphere",
   "build": "",
   "support": "http://www.siemens.com/automation/service&support",
   "version": 4,
   "description": "MindSphere PaaS",
   "authorization_endpoint": "https://login.cf.eu1.mindsphere.io",
   "token_endpoint": "https://uaa.cf.eu1.mindsphere.io",
   "min_cli_version": "6.30.0",
   "min_recommended_cli_version": "latest",
   "app_ssh_endpoint": "ssh.cf.eu1.mindsphere.io:8443",
   "app_ssh_oauth_client": "ssh-proxy",
   "doppler_logging_endpoint": "wss://doppler.cf.eu1.mindsphere.io:443",
   "api_version": "2.131.0",
   "osbapi_version": "2.14",
}

cf version 6.44.1+c3b20bfbe.2019-05-08

What version of the buildpack you are using? Dotnet-Core Buildpack version 2.2.5 I cannot change this, custom buildpacks are not allowed in this cf instance.

If you were attempting to accomplish a task, what was it you were attempting to do? cf push a dotnet core application

Is your dotnet app unpublished, platform-dependant, or self-contained? I published with dotnet publish -r ubuntu-x64 -c Release, also tried self-contained, but as I understand it is implied when using -r.

What did you expect to happen? cf push to work successfully like the blank aspnetcore app I pushed for testing.

What was the actual behavior? cf push aborts with the following error output:

Downloaded app package (43.2M)
   -----> Dotnet-Core Buildpack version 2.2.5
   -----> Supplying Dotnet Core
   -----> Installing libunwind 1.3.1
          Download [https://buildpacks.cloudfoundry.org/dependencies/libunwind/libunwind-1.3.1-cflinuxfs3-5e3a50f6.tar.gz]
          **ERROR** Error searching project for library "System.Drawing.Common": multiple or no *.deps.json files present
   Failed to compile droplet: Failed to run all supply scripts: exit status 15
   Exit status 223

My application is not using System.Drawing itself, through System.Drawing.dll and System.Drawing.Primitives.dll are in my published output, most likely because other dependencies pull it in. I tried referencing System.Drawing.Common in all projects of the solution but it still returns the same error message. Also I tried to switch target frameworks between netcoreapp2.0, netcoreapp2.1 and netcoreapp2.2 without any luck.

manifest.yml:

applications:
- name: xxxxxxxxxx
  memory: 512M
  buildpacks: 
    - dotnet_core_buildpack
  env:
    DOTNET_CLI_TELEMETRY_OPTOUT: 1
    DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
    CACHE_NUGET_PACKAGES: false

Please confirm where necessary:

• [x] I have included a log output
• [x] My log includes an error message
• [ ] I have included steps for reproduction

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/166179402

The labels on this github issue will be updated when the story is started.

[jwfx]

Does anyone have an idea what else I could try? This issue must not necessarily be a bug, it could be a configuration/compilation problem on my end.

[zmackie]

@jwfx Not sure at the moment, but we'll take a look.

[jwfx]

So the available buildpack was updated to 2.2.7 but unfortunately the issue remains.

I could really use some help here.

[ndon55555]

Hey @jwfx, there is logic in the buildpack to fail out if your published app contains multiple or no <something>.deps.json files in the project root.

https://github.com/cloudfoundry/dotnet-core-buildpack/blob/39e671841aee6ca489cc625cbeb453b1b8b0d0e1/src/dotnetcore/supply/supply.go#L75 --> https://github.com/cloudfoundry/dotnet-core-buildpack/blob/2caef2dc06b0aab06c419f05d9bf9299c447ee02/src/dotnetcore/project/project.go#L143 --> https://github.com/cloudfoundry/dotnet-core-buildpack/blob/2caef2dc06b0aab06c419f05d9bf9299c447ee02/src/dotnetcore/project/project.go#L133

Could you check to see if this is true for your project? If there are multiple <something>.deps.json files, can you check to see if you need all of them?

[jwfx]

I have multiple deps.json, actually one for the application and one for each project in my solution. All those files are generated by default and I did not change anything about this behavior so I am not really sure if I actually need them.

Why is having multiple deps.json a problem and having one is ok?

[ndon55555]

@jwfx Not sure if having multiple deps.json is actually supposed to be a problem; it's just what I'm noticing the buildpack handles. Instead of pushing your whole solution, would it be possible for you to push each project separately?

[jwfx]

@ndon55555 That is not really doable for me since the application is depending on the library projects which produce the additional .deps.json files

I believe the logic in the build pack might be a bit flawed here.

The goal of this line here is to figure out if the application is relying on System.Drawing.Common, because the buildpack needs to determine if libgdiplus must be pulled in or not. usesLibgdiplus, err := s.Project.UsesLibrary("System.Drawing.Common")

So stopping the search for the usage of System.Drawing.Common at the first assembly kinda makes no sense, because any of the referenced assemblies could pull in System.Drawing.Common and thus making libgdiplus a requirement.

In case of System.Drawing.Common the GetVersionFromDepsJSON() function should probably behave differently and iterate over all .deps.json rather than erroring out.

@djoyahoy from what I see you are the original author of the libgdiplus code in this buildpack. I would appreciate if you could shed some light on this issue.

[djoyahoy]

Hi @jwfx, I no longer help to maintain this buildpack but I'll see if I can provide some insight. In my recollection at the time of implementation, the s.Project.UsesLibrary("System.Drawing.Common") leveraged an existing function GetVersionFromDepsJSON() simply because it was already there.

So the real question is, why does GetVersionFromDepsJSON() enforce that you only have one *.deps.json in your project root. As to why, I am not sure. That might be a worthwhile area of investigation for the buildpack maintainers.

Additionally, some insight into the structure of your project might be useful. It sounds like you have multiple libraries in your project root that are then used by the application you deploy?

[jwfx]

@djoyahoy Thanks for your input.

As for your question, my project structure looks like this: MyProject.sln src\MyApplication\ <-- dotnet core app src\MyLib1\ <-- netstandard lib referenced in MyApplication src\MyLib2\ <-- netstandard lib referenced in MyLib1 and MyApplication

I run dotnet publish -o d:\publish -r linux-x64 --self-contained true -c Release on the MyApplication project and that leads to creation of one .deps.json file per project (both application and library projects).

My knowledge about the maintainer team structure is pretty much non-existent and I kinda don't want to ping all 366 members of the CF organization.

How can we get the responsible maintainer into this discussion?

[shanks3012]

@jwfx Thanks for providing additional information and thanks @djoyahoy for jumping in. I've got this in our backlog and will get this prioritized as quickly as possible. At that time, we will have maintainers available to resolve this for you.

[cunnie]

FYI, I hit the same issue with cf push dora when I was in the wrong directory (assets/ instead of assets/dora). This won't fix your problem, @jwfx , but it may help a subset of people who land on this page.

[ndon55555]

Hi @jwfx, I've begun the work for this but am having a bit of trouble creating a fixture that has the problem. My current solution structure is roughly:

TheSolution.sln (simple_solution_2.2_source.sln)
src/main_project (simple_2.2_source) --> depends on 2nd_project
src/2nd_project (another_project) --> depends on 3rd_project
src/3rd_project (third_project)

When I run dotnet publish -o /tmp/published -r linux-x64 --self-contained true -c in the root of the main project, /tmp/published only contains one file with a suffix of deps.json. Could you see if my setup is correct?

Here's my source code.

Or if you could provide your own fixture that would work, that would be quicker and easier.

[jwfx]

@ndon55555

I have created a sample here: https://github.com/jwfx/TestApp

When I publish this with dotnet publish -o d:\publish -c Release -r linux-x64 --self-contained true in the folder of the .sln file, I will get a ClassLibrary1.deps.json and a TestApp.deps.json file in the publish folder.

For sake of reproduction I pinned the SDK version to 2.2.301.

I have created this sample with VS 2019. First I created the TestApp console project, then I added a class library project to the solution and then I referenced the classlib in the console app.

[ndon55555]

@jwfx Thank you!

[ndon55555]

@jwfx This issue has hopefully been resolved in https://github.com/cloudfoundry/dotnet-core-buildpack/commit/f4502352ba14dc402cee8549cd5bba46f3577db8. Feel free to re-open if you are still having issues with this

[jwfx]

@ndon55555 Thank you for the fix and your time!

[abhishek-misra]

@cf-gitbot , @ndon55555 I am also getting the same error. ERROR Error searching project for library "System.Drawing.Common": multiple *.runtimeconfig.json files present.

Please find my details as below. I am using Dot Net Core Buildpack 2.2.13 also tried the version 2.3.0, I am getting error on below steps

-----> Installing libunwind 1.3.1 Download [https://buildpacks.cloudfoundry.org/dependencies/libunwind/libunwind-1.3.1-cflinuxfs3-5e3a50f6.tar.gz] ERROR Error searching project for library "System.Drawing.Common": multiple or no *.deps.json files present

Kindly let me know how to solve this. Thanks

[ndon55555]

@AbMishra0039 The fix for this was included in https://github.com/cloudfoundry/dotnet-core-buildpack/releases/tag/v2.2.14

[zmackie]

@ndon55555 DON!!!!!!!!!!!!!!!!!!

[ndon55555]

@Zanadar Zander!

[vrcsekhar]

@ndon55555 I'm getting this error in cloudfoundry while staging my app [31;1mERROR Error searching project for library "System.Drawing.Common": multiple *.runtimeconfig.json files present

i'm using dotnet_core_buildpack_234_cflinuxfs3 buildpack, is publishing only .csproj is the solution. i'm currently trying to publish the .sln which has one app csproj and one tests proj the tests proj doesn't have drawing.common reference. And both on .net core 3.1 could adding this reference to tests project helps?

Please if anyone has update on the above error let me know., thanks!!!

[ndon55555]

Hi @vrcsekhar. I no longer help maintain this repo, so I wouldn't be aware of the current state of the buildpack. Your problem looks slightly different from the original issue, so I recommend opening up a separate issue for more visibility

[deba187]

Hello,

I am also getting the same error. ERROR Error searching project for library "System.Drawing.Common": multiple *.runtimeconfig.json files present.

Please find my details as below. I am using Dot Net Core Buildpack, .Net 6 , I am getting error on below steps

-----> Installing libunwind 1.3.1 Download [https://buildpacks.cloudfoundry.org/dependencies/libunwind/libunwind-1.3.1-cflinuxfs3-5e3a50f6.tar.gz] ERROR Error searching project for library "System.Drawing.Common": multiple or no *.deps.json files present

Kindly let me know how to solve this. Thanks

[kotzer3]

I had same issue and the error message multiple *.runtimeconfig.json files present.

was correct: I had two runtimeconfig.json files in the publish folder, after removing one of them (the one which was from a different deployment) the deployment was working.