Select to view content in your preferred language

Could not load file or assembly 'System.Drawing.Common, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

5301
11
Jump to solution
09-21-2023 12:42 PM
DavisMiller
Occasional Contributor

All, my team is having issues migrating a Pro SDK solution from Pro 2.8 to Pro 3.1. We have ran the conversion tool with the SDK but we are still seeing assembly build errors. Does anyone have any ideas on how to get our assemblies happy? The specific error above suggests it cannot find the System.Drawing.Common assembly but we have confirmed it does exist at the right version.

Thanks,

Davis Miller 

0 Kudos
1 Solution

Accepted Solutions
DavisMiller
Occasional Contributor

We got our solution working by creating a new project with ArcPro3.1 and the 3.1 SDK and then manually moving WPF forms over manually from our old 2.8 solution one at a time. Then editing the namespace to match the new solution on the old forms. That was the only way we could get the error to go away. Hope this helps you as well. 🙂 Basically the conversion tool was not helpful in our case.  

View solution in original post

0 Kudos
11 Replies
RichardDaniels
Frequent Contributor
At .Net 6.0 System.Drawing.Common is not as common as you may think. Ensure Miorosoft .Net Runtime and Microsoft .Net Desktop Runtime are installed on the build machine. Current version is 6.0.21.
0 Kudos
DavisMiller
Occasional Contributor

We have confirmed that both Microsoft .Net Runtime and Microsoft .Net Desktop Runtime are installed and we are still getting the same error 😞 

0 Kudos
DavisMiller
Occasional Contributor

Ok we will try that thank you 🙂 

Davis Miller

0 Kudos
RichardDaniels
Frequent Contributor

Also, with .Net 6 there is a breaking change. Breaking change: System.Drawing.Common only supported on Windows - .NET | Microsoft Learn. In short, .Net Core does not include System.Drawing.Common but .Net Framework does.

0 Kudos
DavisMiller
Occasional Contributor

Do not think this would apply to us and we are using Windows 🙂 

0 Kudos
PauJuan
Emerging Contributor

I am having the exact same problem with System.Text.Json. Same error message and PublicKeyToken. It also happened after updating an AddIn from 2.8 to 3.1. We confirmed the dependency is installed and in the AddIn AssemblyCache. No problems during build time, the error message only pops up after opening Pro.

PauJuan_0-1695377799469.png

We think it is caused by the assembly being a dependency of another one, rather than being called directly. This is preventing it from being packaged with the AddIn dll. Could this be the case? Is there a way to specify hidden dependencies in the .csproj file?

Thanks

0 Kudos
RichardDaniels
Frequent Contributor

If you are using Visual Studio 2022 to build your ArcGIS Pro 3.x package and include a reference to a NuGet packet as a resource you can have problems. If you install the NuGet package on your computer and then reference the DLLs on disk the NuGet references will work. However, if you reference (i.e., add) and NuGet package itself (in Visual Studio), you will receive an XAML error showing, "Error: Could not load file or assembly 'ArcGIS.Desktop.Framework, Culture=neutral' or one of its dependencies at compile time.
After upgrading a 2.x add-in to 3.x in Visual Studio check your .csproj file. Recommendation on another post is to removing the False attribute for each DLL in the csproj file. (see Solved: Re: Extensions NuGet package not loading in VS 202... - Esri Community<>).

 

Note - I first ran across this issue when trying to convert my ArcGIS Pro 2.9 (Visual Studio 2019) project to use new webview2 control in Visual Studio 2022. The solution was to search for webview2 in NuGet, and then install it. You install the Microsoft.Web.WebView2 SDK NuGet package for into the current project. 

0 Kudos
PauJuan
Emerging Contributor

Thanks Richard. Could you please show an example of how to reference the DLLs on disk directly?

0 Kudos
DavisMiller
Occasional Contributor

We got our solution working by creating a new project with ArcPro3.1 and the 3.1 SDK and then manually moving WPF forms over manually from our old 2.8 solution one at a time. Then editing the namespace to match the new solution on the old forms. That was the only way we could get the error to go away. Hope this helps you as well. 🙂 Basically the conversion tool was not helpful in our case.  

0 Kudos