Package Details: monodevelop-stable

Git Clone URL: (read-only, click to copy)
Package Base: monodevelop-stable
Description: An IDE primarily designed for C# and other .NET languages
Upstream URL:
Keywords: mono monodevelop
Licenses: MIT
Conflicts: monodevelop
Provides: monodevelop, monodevelop-debugger-gdb
Replaces: monodevelop-debugger-gdb
Submitter: fusion809
Maintainer: coder2000
Last Packager: TheGoliath
Votes: 36
Popularity: 0.028505
First Submitted: 2016-10-21 19:09
Last Updated: 2020-05-22 15:28

Required by (4)

Sources (1)

Pinned Comments

coder2000 commented on 2020-08-03 13:35

According to the issue described by kingkhan94,, for the last year or so MonoDevelop 8.0 has not been buildable on anything but Mac. The community has created a fork for a new environment at

kingkhan94 commented on 2020-08-03 12:22

MonoDevelop (8.X) no loger compile in Linux (only Mac)...

"Embrace, extend, and extinguish!" (EEE) =[

Possible solution is using .

Install using pamac following packages

  • monodevelop-bin
  • mono-msbuild
  • mono-msbuild-sdkresolver

Hope this helps!

UPDATE: Install xps to easily debug web projects (ASP.NET)...


Credit: @eduardolucioac commented on 2020-06-08 19:24

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 ... Next › Last »

Toric commented on 2019-07-08 04:12

According to, the current latest version is Is 7.8 not stable?

notfood commented on 2019-06-02 21:47

To fix the libgit2 crashing on any project with git enabled you must compile it against OpenSSL-1.0

Append this line to the prepare()

sed -i -e 's|-DCMAKE_SKIP_RPATH=TRUE|-DCMAKE_SKIP_RPATH=TRUE -DOPENSSL_ROOT_DIR=/usr/lib/openssl-1.0 -DOPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0|g' $srcdir/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Git/

libgit2 was being compiled against OpenSSL-1.1 otherwise making it crash.

doctorzeus commented on 2019-04-29 01:54



Not quite as we are taking a .deb package that was only primarily designed to be used on debian-based distros. If we want to do something to make it work with arch that's on our end.

Tire* not wheel.Different tires, different standards of size.

lss40770 commented on 2019-04-29 01:43

Is there a proper way to fix the conflict between gtk-sharp-2 and gtk-sharp-3?

As it was previously pointed out, having gtk-sharp-3 installed prevents this package from being compiled. However, some other stuffs (like monogame-bin) actually depends on gtk-sharp-3 so they'll be uninstalled as well when uninstalling gtk-sharp-3 (and I'll need to rebuild them as well), even if's only temporary, for ensuring a successful build of this package.

archnix commented on 2019-04-27 08:25

Issue created at Github

:laughing: - Yeah - that is what we are doing when we refactor a deb package to a pkg.

Something like buying wheels to Mercedes and retrofit to a Porche - :laughing:

doctorzeus commented on 2019-04-26 14:52

@fhdk I'm not arguing against the validity of your solution. It's just not a distro or OS specifically targeted application so it definitely needs to be something that is generated from configurable vars pre-make as opposed to something the dev's have just plopped in there from their own systems or distro they use.

Again i'm happy to fix this up in the short term but again it should be something that is queried on github for the future. I'm talking from a software development standpoint here.

It's like buying what is meant to be a standardized tire size which actually only fits perfectly for one type of car. So then all the other people who buy it have to end up modifying it themselves so it actually fits on their car. What your saying to me is that this is totally fine. :P

archnix commented on 2019-04-26 13:42

@docterzeus I understand and thank you for maintaining the PKGBUILD, I appreciate it.

The monodevelop launcher script is not created during configure - it is a static file created for another operating system.

So translation to Arch using the mentioned sed replaces - is absolutely valid in my opinion.

Same result - another place

build() {
  cd $_pkgname

  export PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig
  export CFLAGS+=" -I/usr/include/openssl-1.0"
  export LDFLAGS+=" -L/usr/lib/openssl-1.0 -lssl"
  export MONO_IOMAP=all

  ./configure --prefix=/usr --profile=stable

  sed -i "/export LD_LIBRARY_PATH\=/c\export LD_LIBRARY_PATH\=\/usr\/lib\/monodevelop\/bin\:\$\{LD_LIBRARY_PATH\}" $srcdir/$_pkgname/main/monodevelop
  sed -i "/EXE_PATH\=/c\EXE_PATH\=\/usr\/lib\/monodevelop\/bin\/MonoDevelop.exe" $srcdir/$_pkgname/main/monodevelop

  XDG_CONFIG_HOME="$srcdir"/config make

And thank you for responding - have a great day.

doctorzeus commented on 2019-04-26 09:26

Hi @fhdk,

Yes but it would be nice to have these re-definable during configure rather than post-compile "hacking" if you see what I mean as it's much better practice.

I'll try and put this in next release after testing.

Thanks again.

archnix commented on 2019-04-25 18:20


this might be something to bring up with the github dev's

You may be correct but as I found, the conflicts rise due to Archs unified folder approach where /bin and /sbin is symlinked to /usr/bin.

A collision rise in the original script which expects a folder /sbin/monodevelop/lib/bin and that folder cannot exist because /sbin is symlinked to /usr/bin and therefore collide with the monodevelop script.

So the correct approach may be to run sed on the script during package to correct both the LD_LIBRARY_PATH and the EXE_PATH to match Arch.

The script is located in src/monodevelop/main/monodevelop so something like this in package()

cd "$pkgdir/usr/bin"
sed -i "/export LD_LIBRARY_PATH\=/c\export LD_LIBRARY_PATH\=\/usr\/lib\/monodevelop\/bin\:\$\{LD_LIBRARY_PATH\}" monodevelop
sed -i "/EXE_PATH\=/c\EXE_PATH\=\/usr\/lib\/monodevelop\/bin\/MonoDevelop.exe" monodevelop

It is tested but feel free to correct me - I am not an expert on sed :)

doctorzeus commented on 2019-04-25 09:15

@fhdk Great thanks but this might be something to bring up with the github dev's as from what I can see these are not options that you can specify on configure (maybe this should be added).

I will look into making this a patch in the next release but don't want it to become a slippery slope of slowly patching each script inside the actual repo! :P