Bug 1255204 - support xbuild targeting .net framework 2.0
support xbuild targeting .net framework 2.0
Status: NEW
Product: Fedora
Classification: Fedora
Component: mono (Show other bugs)
25
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Xavier Lamien
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-19 20:31 EDT by Hin-Tak Leung
Modified: 2017-11-16 13:59 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hin-Tak Leung 2015-08-19 20:31:07 EDT
Description of problem:

 Only /usr/lib/mono/4.5/mscorlib.dll exists.

Win32 mono, as well as wine-mono, when installed into the user's $HOME under wine, gives:

.wine/drive_c/windows/mono/mono-2.0/lib/mono/2.0/mscorlib.dll
.wine/drive_c/windows/mono/mono-2.0/lib/mono/4.0/mscorlib.dll
.wine/drive_c/windows/mono/mono-2.0/lib/mono/4.5/mscorlib.dll

While 4.0 profile can run 2.0 binaries, sometimes, as a developer, one wants to target the older profile still in use, and to build *for* 2.0, one needs all the 2.0 runtime support. 

I have encountered a 2nd project now with a targetframework declaration for 2.0 now. and without /usr/lib/mono/2.0/mscorlib.dll, this is the sort of mysterious error one gets:

SharpFont/Source/SharpFont.sln (default targets) ->
(Build target) ->
Source/SharpFont/SharpFont.csproj (default targets) ->
/usr/lib/mono/4.5/Microsoft.CSharp.targets (CoreCompile target) ->

	CSC: error CS0518: The predefined type `System.Object' is not defined or imported
	CSC: error CS0518: The predefined type `System.ValueType' is not defined or imported
	CSC: error CS0518: The predefined type `System.Attribute' is not defined or imported
	CSC: error CS0518: The predefined type `System.Int32' is not defined or imported
	CSC: error CS0518: The predefined type `System.UInt32' is not defined or imported
	CSC: error CS0518: The predefined type `System.Int64' is not defined or imported
	CSC: error CS0518: The predefined type `System.UInt64' is not defined or imported
	CSC: error CS0518: The predefined type `System.Single' is not defined or imported
	CSC: error CS0518: The predefined type `System.Double' is not defined or imported
	CSC: error CS0518: The predefined type `System.Char' is not defined or imported
	CSC: error CS0518: The predefined type `System.Int16' is not defined or imported
	CSC: error CS0518: The predefined type `System.Decimal' is not defined or imported
	CSC: error CS0518: The predefined type `System.Boolean' is not defined or imported
	CSC: error CS0518: The predefined type `System.SByte' is not defined or imported
	CSC: error CS0518: The predefined type `System.Byte' is not defined or imported
	CSC: error CS0518: The predefined type `System.UInt16' is not defined or imported
	CSC: error CS0518: The predefined type `System.String' is not defined or imported
	CSC: error CS0518: The predefined type `System.Enum' is not defined or imported
	CSC: error CS0518: The predefined type `System.Delegate' is not defined or imported
	CSC: error CS0518: The predefined type `System.MulticastDelegate' is not defined or imported
	CSC: error CS0518: The predefined type `System.Void' is not defined or imported
	CSC: error CS0518: The predefined type `System.Array' is not defined or imported
	CSC: error CS0518: The predefined type `System.Type' is not defined or imported
	CSC: error CS0518: The predefined type `System.Collections.IEnumerator' is not defined or imported
	CSC: error CS0518: The predefined type `System.Collections.IEnumerable' is not defined or imported
	CSC: error CS0518: The predefined type `System.IDisposable' is not defined or imported
	CSC: error CS0518: The predefined type `System.IntPtr' is not defined or imported
	CSC: error CS0518: The predefined type `System.UIntPtr' is not defined or imported
	CSC: error CS0518: The predefined type `System.RuntimeFieldHandle' is not defined or imported
	CSC: error CS0518: The predefined type `System.RuntimeTypeHandle' is not defined or imported
	CSC: error CS0518: The predefined type `System.Exception' is not defined or imported

	 0 Warning(s)
	 31 Error(s)

Win32 Mono ships 2.0/mscorlib.dll etc in their 4.0.x packaging, so this seems to be a fedora anormaly.

Version-Release number of selected component (if applicable):
mono-core-4.0.2-5.fc23

How reproducible:
always

Steps to Reproduce:
1. git clone git://github.com/Robmaister/SharpFont.git
2. git submodule update --init
3. xbuild

Actual results:
mysterious error as above.

Expected results:
build success

Additional info:

It is possible to do:
xbuild /p:TargetFrameworkVersion="v4.5" ...

but as I said, one likes build for the older framework still in use if possible.
Comment 1 Timotheus Pokorra 2015-08-20 01:23:51 EDT
The problem is, that the tarball of Mono 4.x contains the 2.0 dlls precompiled. So according to the Fedora rules, we have to delete them and cannot use them in the package.

One option for you could be to use the Xamarin RPMS, according to http://www.mono-project.com/docs/getting-started/install/linux/#centos-fedora-and-derivatives
Those packages include the 2.0 and 4.0 dlls.

The even better option that I recommend (and you mentioned already):
It is quite easy to upgrade your project to support the 4.5 framework.
We have done this for all packages in Fedora that depend on Mono quite similar to this:

sed -i "s#gmcs#mcs#g" configure
sed -i "s#gmcs#mcs#g" configure.in
find . -name "*.sln" -print -exec sed -i 's/Format Version 10.00/Format Version 11.00/g' {} \;
find . -name "*.csproj" -print -exec sed -i 's#ToolsVersion="3.5"#ToolsVersion="4.0"#g; s#<TargetFrameworkVersion>.*</TargetFrameworkVersion>##g; s#<PropertyGroup>#<PropertyGroup><TargetFrameworkVersion>v4.5</TargetFrameworkVersion>#g' {} \;
Comment 2 Hin-Tak Leung 2015-08-20 10:59:54 EDT
Thanks for the explanation.

I'll see if I can just drop the precompiled dlls into /usr/lib/mono/2.0 and have them working.

As I wrote earlier, as a developer one might like to develop for an older runtime stll in use - i.e. similiar to using compat-gcc-34-c++ and compat-gcc-34-g77 instead of gcc/gfortran, to support users who are not upgrading.

At the moment I have a slightly different and unusual need compared to this general one: I need to use a binary-only library that works well under MS .Net 2 in wine, but not in mono (either native or under wine). This is a mono bug/deficiency, but first I need to be able to do apple-to-apple build of a small test wrapper to file the issue :-).
Comment 3 Hin-Tak Leung 2015-08-22 13:44:04 EDT
I found that I can simply drop the binaries from git://github.com/mono/reference-assemblies.git into /usr/lib/mono/{2.0,3.5,4.0} and xbuild then seem to be able to target the older frameworks and build for them. It seems to run the compiler
with the /nostdlib option then explicitly referencing the versioned libraries,
which is somewhat expected.

However, "mono --runtime=v2.0.50727 ..." still won't work, and comparing those
directories with win32 mono's under wine, I found a whole lot of *.exe missing.
That probably explains it.

I'll leave the bug open, in case there is a way of making it work under redhat's
"not shipping 3rd party binaries" policy in the future.
Comment 4 Hin-Tak Leung 2015-08-22 13:48:19 EDT
Actually, since older mono supports the older runtime, the sources of the older runtime - or a compatible version of it - must have shipped with older mono.

So one way of not using the reference binaries is to scavenge the older source from older mono. It might be quite painful to make older sources build with newer compiler, though. :-(.
Comment 5 Fedora End Of Life 2016-11-24 07:21:04 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 6 Hin-Tak Leung 2016-11-24 15:42:01 EST
Still a problem with f25
Comment 7 Timotheus Pokorra 2016-11-24 16:42:17 EST
If we were including Mono 3.x from source in the Fedora packages, how would we provide security updates for that? Xamarin does not support Mono 3.x anymore, I think.

I honestly don't think your issue will be resolved with Fedora packages.
My suggestion stands to use the Xamarin packages instead. Would that work for you?
Comment 8 Hin-Tak Leung 2016-11-25 08:08:49 EST
mono 4.4 moves the reference assemblies to a slightly different place (adding '-api' to the directory name).

ATM I unpack the src rpm and drop the fedora patch, and rebuild... but I reckon building for older runtime/older windows isn't that rare a need.
Comment 9 Fedora End Of Life 2017-11-16 13:59:09 EST
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

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