Bug 200811 - gtksourceview-sharp-2.0-13.fc5.x86_64 installs assembly where monodevelop can't find it
Summary: gtksourceview-sharp-2.0-13.fc5.x86_64 installs assembly where monodevelop can...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gtksourceview-sharp
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul F. Johnson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-07-31 19:45 UTC by Dean Brettle
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-07-31 20:49:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dean Brettle 2006-07-31 19:45:34 UTC
Description of problem:

On my FC5 x86_64 system, monodevelop can't find gtksourceview-sharp.dll after
installing the latest update.  I believe this is because it is installed under
/usr/lib64/mono/gac while everything else is installed under /usr/lib/mono/gac.
     Shouldn't the assembly be installed somewhere that monodevelop can find it
without needing to set any env vars?

Version-Release number of selected component (if applicable):

mono-core-1.1.13.7-1.fc5.1
monodevelop-0.11-7
gtksourceview-sharp-2.0-13.fc5

How reproducible:

Everytime.

Steps to Reproduce:
1.  Run monodevelop
  
Actual results:

The error is:

[brettle@ibexpc ~]$ monodevelop

** (MonoDevelop:19744): WARNING **: The following assembly referenced from
/usr/lib/monodevelop/AddIns/MonoDevelop.SourceEditor.dll could not be loaded:
     Assembly:   gtksourceview-sharp    (assemblyref_index=2)
     Version:    1.0.0.2
     Public Key: 35e10195dab3c99f
The assembly was not found in the Global Assembly Cache, a path listed in the
MONO_PATH environment variable, or in the location of the executing assembly
(/usr/lib/monodevelop/bin/../AddIns).


** (MonoDevelop:19744): WARNING **: The class
GtkSourceView.SourceLanguagesManager could not be loaded, used in
gtksourceview-sharp, Version=1.0.0.2, Culture=neutral,
PublicKeyToken=35e10195dab3c99f

** ERROR **: file class.c: line 2505 (mono_class_setup_parent): should not be
reached
aborting...

Expected results:

Monodevelop should start without error.

Additional info:

FYI, I was unable to use MONO_PATH or MONO_GAC_PREFIX to convince mono to use
that directory, but perhaps I just didn't provide the correct setting.

Comment 1 Paul F. Johnson 2006-07-31 20:12:02 UTC
Monodevelop is not in FE yet. There is an open report on this (#178904). The
version currently in development fixes this problem.

Thanks for the report.

Comment 2 Dean Brettle 2006-07-31 20:37:44 UTC
Good to know that monodevelop is being reviewed.  However, I'm reopening because
I'm concerned that this is a larger problem.  Shouldn't gtksourceview-sharp be
visible to mono in general, not just monodevelop?  For example, gacutil can't
find it either:

[brettle@ibexpc ~]$ gacutil -l gtksourceview-sharp
The following assemblies are installed into the GAC:
Number of items = 0

Also, gtk-sharp installs under /usr/lib/mono/gac.  Is gtksourceview-sharp more
platform-dependent than gtk-sharp in some way?

I'm not trying to be a pain.  I just want to make sure that this issue is
resolved in the correct/consistent manner.  Thanks!



Comment 3 Paul F. Johnson 2006-07-31 20:49:07 UTC
The problem is actually an upstream one. Due to the way mono is done (it has to
be platform and processor agnostic), everything is placed in /usr/lib -
irrespective of hardware considerations..

There has been much debate on the packagers lists over this and for now, the
decision is that /usr/lib is fine, but upstream really have to fix the problem.
It looks like gtksourceview-sharp was caught in the cross fire.

I'm building a fixed version and will commit it tonight. It should hit extras on
the next push. If it still comes back as a problem, please open a new bug rather
than this one (it looks like it is a monodevelop bug report!)


Note You need to log in before you can comment on or make changes to this bug.