I've resolved this by just linking that specific .dylib into the target directory as a post step---so feel free to mark as resolved if this is working as designed.   Just curious, though, about the distinction between running the exact command under the IDE vs. a shell.  Specifically, what rules the mono runtime follows for resolving the dynamic libraries that come with its own distribution (I'd think they would be implicit?)---and what you think the explanation might be for inconsistent behavior (IDE launch vs. not) in this case.

Much appreciated!

Additional note:  I just stumbled across logging from an assembly made nearly a year ago and is running under a cron job every minute.  It, too, suffers from the same issue---a console app unable to implicitly load/bind libgdiplus.dylib, same signature:

Exception: System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.KnownColors ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: libgdiplus.dylib
  at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)
  at System.Drawing.GDIPlus..cctor () [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Drawing.KnownColors..cctor () [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Drawing.Color.get_OrangeRed () [0x00000] in <filename unknown>:0 
  at <redacted>.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 

So this does appear to be due to a recent change in the mono runtime itself.
(This assembly just went from working -> not across one of the alpha channel
runtime updates....not touched/rebuilt/anything.)

Hope this helps!

Minimal steps to reproduce this issue:

Xamarin Studio
Version 5.3 (build 435)
...
Runtime:
	Mono 3.8.0 ((no/62a857e)
	GTK+ 2.24.23 (Raleigh theme)


(1) Launch XS.
(2) Create a new console application, default location is okay, name e.g. GDIPlusBug.
(3) Add to the project a reference to the System.Drawing assembly.
(4) Alter Program.cs to minimally invoke features of the System.Drawing, e.g.:

using System;
using System.Drawing; // ADDED

namespace GDIPlusBug
{
    class MainClass
    {
        public static void Main(string[] args)
        {
            var color = Color.Black; // ADDED

            Console.WriteLine("Hello World!");
         }
    }
}

(5) Start the debugging session.

You should observe a TypeInitializationException for KnownColors.
Then, the minimal hack fix for this issue is to:

(6) Open a terminal session, cd to the console app project location.
(7) cd to the binary location, e.g. GDIPlusBug/GDIPlusBug/bin/Debug
(8) symlink libgdiplus.dylib from its installed location to the current directory, e.g.:

ln -s /Library/Frameworks/Mono.framework/Versions/Current/lib/libgdiplus.dylib .

(9) Start another debug session within XS for the same test app.

Result: proper operation.

Hi,

I can confirm that I see the same issue -- also with Mono 3.8.0 (the package that comes with Xamarin Studio).

$ mono --version
Mono JIT compiler version 3.8.0 ((no/45d0ba1 Tue Aug 26 20:33:43 EDT 2014)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  x86
	Disabled:      none
	Misc:          softdebug 
	LLVM:          yes(3.4svn-mono-(no/e656cac)
	GC:            sgen

Also, the same workaround works for me, too. I.e.:

ln -s /Library/Frameworks/Mono.framework/Versions/Current/lib/libgdiplus.dylib .

I would have expected the following to have the same effect:

DYLD_LIBRARY_PATH=/Library/Frameworks/Mono.framework/Versions/Current/lib /usr/bin/mono Program.exe

But for some reason, it did not help when I tried it. (At other times, with locally compiled Mono, it has been necessary to specify DYLD_LIBRARY_PATH=/usr/local/bin, but I hardly know anything about dylib path resolution, so there might be some obvious reason for why it would not have any effect in this case.)

Good morning, everybody.

As of the Mono 3.10 push to the alpha channel late this week, this has regressed even FURTHER.

Prior to this bug report, libgdiplus would be found implicitly by the runtime, associated types could be used out of the box without extra steps.

At the time of this bug report, the type initializer exceptions noted above began to occur, could only be remedied by manually symlinking libgdiplus.dylib from the Mono installed location into, say, the folder where the binary that intends to use it resides.

Today, with Mono 3.10, *** this symlink hack no longer bypasses the issue ***.

The result is that the pipeline tools I have in play, e.g. ones that manipulate Bitmap objects, no longer function.

Unless I find another hack fix, this is currently a progress blocker.

An expedited fix is appreciated.
Please do not allow this defect to propagate further toward beta -> stable!
Thanks.

Folks, please review your 3.8.0 vs. 3.10.0 build.  Specifically:


3.8.0:

-rwxr-xr-x  1 root  admin  556252 Aug 26 17:43 libgdiplus.0.dylib*
lrwxr-xr-x  1 root  admin      18 Sep 20 16:51 libgdiplus.dylib@ -> libgdiplus.0.dylib
-rwxr-xr-x  1 root  admin    1865 Aug 26 17:43 libgdiplus.la*


3.10.0:

-rwxr-xr-x  1 root  admin  4132 Sep 17 15:47 libgdiplus.0.dylib*
lrwxr-xr-x  1 root  admin    18 Sep 20 16:40 libgdiplus.dylib@ -> libgdiplus.0.dylib
-rwxr-xr-x  1 root  admin  1879 Sep 17 15:47 libgdiplus.la*

Note the size change on libgdiplus.0.dylib.
An nm on the former reports 1709 symbols, the latter just a single one.

It seems you have allowed a dud library out in the wild---this speaks to a process issue,
unless there was a bulk move of code to another library and this is now a stub.

If it is truly undersized, suggestions:
   * Improve your build/CI process to include checks to ensure you have a fully viable build.
   * Unit tests for just about any libgdiplus feature should have caught this.

(I'll be looking at the mono repository to see if there is any more insight there.)

Additional notes:
  * Overlaying 3.8.0's libgdiplus* files on top of a 3.10.0 installation
  allows the test app indicated above to run so long as you run it from
  the debugger.
  * The test app still does not run from the console without the stated
  exception, indicating that the originally reported bug is still present.

I can confirm the same issue as well. The workaround I used was the following:

Edit /Library/Frameworks/Mono.framework/Versions/3.8.0/etc/mono/config and replace the entries for libgdiplus:

<dllmap dll="gdiplus" target="/Library/Frameworks/Mono.framework/Versions/3.8.0/lib/libgdiplus.dylib" os="!windows"/>
    <dllmap dll="gdiplus.dll" target="/Library/Frameworks/Mono.framework/Versions/3.8.0/lib/libgdiplus.dylib"  os="!windows"/>
    <dllmap dll="gdi32" target="/Library/Frameworks/Mono.framework/Versions/3.8.0/lib/libgdiplus.dylib" os="!windows"/>
    <dllmap dll="gdi32.dll" target="/Library/Frameworks/Mono.framework/Versions/3.8.0/lib/libgdiplus.dylib" os="!windows"/>

@Tim:  This does in fact fix the issue when running from the XS debugger.   It is also what was changed by the mono team in the 3.8.0 -> 3.10.0 timeframe.   Thanks for confirming this on your end.   The original reported regression, however (run this same assembly via "mono <xxxx>" from a bash shell, no added environment path changes to find libgdiplus.so, etc.) remains.   So XS/the debugger is invoking mono in such a way that it finds all of its implied internal bits...console mono invocation has lost [at least part of] its ability to do so across some relatively recent mono version boundary.

@Brian: Perhaps I misunderstand (not familiar with the mono source code), but for me the modifications to the config enable me to run apps  (Debug and Release builds) from the command line (eg: mono Blah.exe) again.

@Tim:  Nope, you didn't misunderstand---I misunderstood that you observe a fix both in-debugger as well as from command line.  I only see a fix within the debugger.   Confirm for me (at your leisure, mind you---this is not a blocking issue for me currently) that you have no local modifications to LD_LIBRARY_PATH or other environment changes that might make a difference?   This is a bit of a puzzle.  Cheers.

(The only 'magic' that happened today is that Quartz notified my that an update was available and I installed that. Current version: XQuartz 2.7.7 (xorg-server 1.15.2))

I see nothing special in my environment. Here is the output from printenv 

tims-mbp:Release timvw$ printenv
TERM_PROGRAM=iTerm.app
ANDROID_HOME=/Users/timvw/Library/Developer/Xamarin/android-sdk-mac_x86
SHELL=/bin/bash
TERM=xterm-256color
TMPDIR=/var/folders/qm/_dlpfyc52bl9ll0jkybd_q5w0000gn/T/
Apple_PubSub_Socket_Render=/tmp/launch-7pcKYL/Render
OLDPWD=/Users/timvw/src/keepass/Build/KeePass
ANT_HOME=/Users/timvw/Library/Developer/apache-ant-1.9.2
LC_ALL=en_US.UTF-8
USER=timvw
SSH_AUTH_SOCK=/tmp/launch-p8ktco/Listeners
__CF_USER_TEXT_ENCODING=0x1F5:0:0
__CHECKFIX1436934=1
PATH=/opt/local/bin:/opt/local/sbin:/usr/local/heroku/bin:/Users/timvw/Library/Developer/apache-tomcat-8.0.3/bin:/Users/timvw/Library/Developer/go_appengine:/Users/timvw/Library/Developer/apache-ant-1.9.2/bin:/Users/timvw/Library/Developer/Xamarin/android-sdk-mac_x86/platform-tools:/Users/timvw/bin:/Users/timvw/Library/Developer/Xamarin/android-sdk-mac_x86/tools:/Applications/Scheme.app/Contents/Resources:/Users/timvw/mongodb/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/git/bin
PWD=/Users/timvw/src/keepass/Build/KeePass/Release
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home
LANG=en_US.UTF-8
ITERM_PROFILE=Default
SHLVL=1
COLORFGBG=7;0
HOME=/Users/timvw
ITERM_SESSION_ID=w0t0p0
LOGNAME=timvw
LC_CTYPE=UTF-8
DISPLAY=/tmp/launch-sdY7Il/org.macosforge.xquartz:0
_=/usr/bin/printenv

Appreciate the words, Tim.  Thank you.   I'll have to look further once I can roll back to 3.8.0 (or when a fixed 3.10.0+ hits to resolve the unrelated empty-library issues.   I haven't changed my environment in any meaningful way either---it just started to happen here (cron jobs running long-reliable utility assemblies, custom build steps in XS running .net tools) when a runtime update landed.   Cheers.

With the fix in 3.10.0.20 for https://bugzilla.xamarin.com/show_bug.cgi?id=23553, this issue also looks resolved so far.   Many thanks.