.NET 8 Migration | System.Drawing.Common Error

.NET 8 Migration | System.Drawing.Common Error

BlackBox_
Advisor Advisor
1,968 Views
5 Replies
Message 1 of 6

.NET 8 Migration | System.Drawing.Common Error

BlackBox_
Advisor
Advisor

I've migrated a small ContextMenu app I've been using since 2010 to .NET 8 which now uses a System.Drawing.Common package in lieu of previous .NET Framework's assembly reference to same.

 

I skipped 2025, so am still new to .NET 8, NuGet, etc.

 

The app works great... for me, on multiple workstations, that each have VS installed... but I've had two folks I've shared the app with for a long time report that it's crashing on their end, and the rawdata-t2.pb crash reports both reference the exact same exception & PublicKeyToken code (at completely different companies), so I must have done something wrong:

 

System.IO.FileNotFoundException: Could not load file or assembly 'System.Drawing.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
File name: 'System.Drawing.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

 

System.Drawing.Common 9.0.4 NuGet was used to build the app when they provided the crash reports. I've since upgraded that to 9.0.9 as VS said there was an update... but both crash reports list 9.0.0.0 (despite 9.0.4 being used to build?), so am I using the wrong NuGet, or is it that they just need an update?

 

The app is built for 2026 & 2026.1, so should work with OOTB dependencies. 


The app uses System.Drawing for Icon & Bitmap types to populate a ContextMenu's MenuItems.

 

More specifically, since Autodesk deprecated Autodesk.AutoCAD.Internal.Utils.GetAcadResourceIcon() +3 years ago, I'd rolled my own extension method. Autodesk's implementation was limited to just Main cui, so when I wrote it, I enhanced it to also cull Enterprise CUI (if anyone wants it, I'll share). 

 

Again, I've not had any issue with the extension method code itself, only with the app not loading properly and/or crashing due to System.Drawing.Common which is coming from NuGet package. 

 

Please advise. 


"How we think determines what we do, and what we do determines what we get."

Sincpac C3D ~ Autodesk Exchange Apps

0 Likes
Accepted solutions (1)
1,969 Views
5 Replies
Replies (5)
Message 2 of 6

BlackBox_
Advisor
Advisor
Accepted solution

This solved it - Apparently AutoCAD 2026 products are relegated to System.Drawing.Common v8 - unless you've installed newer!? - which doesn't seem to be documented on system requirements page. 

 

A new build using 8.0.20 package works fine now on new machine with clean install; thanks, @Victor.Tuguinay 🍺

 


@Victor.Tuguinay wrote:

I think i solved my own problem. I totally removed the System.Drawing.Common (9.0.0) then installed version 8.0.13 and the form loaded as expected. There seem to be a problem when using version 9. Could also be a compatibility issue between Inventor 2025 and the latest versions of the package.
Inventor 2025 (and its runtime environment) might have been built and tested with an earlier version of System.Drawing.Common, so version 9.x may introduce changes that aren’t compatible or expected.

 


 


"How we think determines what we do, and what we do determines what we get."

Sincpac C3D ~ Autodesk Exchange Apps

Message 3 of 6

Izhar_Azati
Advocate
Advocate

My conclusion is not to rush and install a new version of Nuget just because VS shows that there is an update.
Stay with the minimum version that works for you.
It was uphill battle to find the right Nuget, for example, the latest version of System.Diagnostics.EventLog
This caused that at the stage of NETLOAD it flew and I didn't know why.

 

0 Likes
Message 4 of 6

BlackBox_
Advisor
Advisor

FWIW, I didn't rush to install anything - I simply upgraded my .NET Framework app to .NET 8 and the NuGet was already associated with the new project, or it prompted me to include it on first load (and I simply didn't notice the NuGet version). Don't recall. 

 

While that was unfortunate, the real issue to my mind is that compiling with a newer NuGet build actually works just fine (in my case), so long as you've got that version installed on a given machine. 

 

I incorrectly expected Autodesk to disallow an assembly that has incompatible dependencies from even loading to begin with. 


"How we think determines what we do, and what we do determines what we get."

Sincpac C3D ~ Autodesk Exchange Apps

Message 5 of 6

Izhar_Azati
Advocate
Advocate
Message 6 of 6

soonhui
Advisor
Advisor

I do think that the real solution can only happen on AutoCAD side, I've opened up a ticket, so please consider giving it an upvote

 

https://forums.autodesk.com/t5/civil-3d-ideas/support-different-assemblyloadcontext-internally-withi...

 

It's in Civil 3D ideas beacuse AutoCAD doesn't have a similar ideas forum. 

##########

Ngu Soon Hui

##########

I'm the Benevolent Dictator for Life for MiTS Software. Read more here


I also setup Civil WHIZ in order to share what I learnt about Civil 3D
0 Likes