Bug 177410

Summary:	gacutil not accepting dlls
Product:	[Fedora] Fedora	Reporter:	Paul F. Johnson <paul>
Component:	mono	Assignee:	Alexander Larsson <alexl>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-01-31 20:36:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Paul F. Johnson 2006-01-10 14:04:49 UTC

Description of problem:
I've compiled MySql Connector .net (with the fixes!) and when I attempt to add
them to my assembly cache using gacutil, gacutil reports that the assembly
cannot be found

Version-Release number of selected component (if applicable):
mono-core 1.1.12.1-1

How reproducible:
Always

Steps to Reproduce:
1. Download Connector .NET from the MySQL website
2. Apply the patches from lists.mysql.com/internals/30054?f=plain
3. Compile
4. cd bin/net-1.1/release; gacutil -i MySql.Data.dll
  
Actual results:
gacutil reports
Failure adding assembly to the cache: The system cannot find the file specified

Expected results:
The file is there, the dll was compiled using the mono rpm and should be
accepted as a non-root user

Additional info:
I am testing mono rpms on one machine but build from source on my other
machines. The built from source version accepts the dll.

(from source)
mono --version
1.1.13

Comment 1 Alexander Larsson 2006-01-11 09:51:14 UTC

It seems to work for me. (Although i didn't apply the patches, just used the
prebuilt .dll)

Comment 2 Paul F. Johnson 2006-01-11 10:02:02 UTC

Are you then able to build the table editor in the Samples/TableEditor/CS
directory just with

mcs Form1.cs -out:tableed.exe -r:System.Windows.Forms -r:System.Drawing
-r:System.Data -r:MySql.Data

?

It is possible that it's an x86_64 fault, but things like this have been
reported on the mono-devel list.