Bug 1294967 - CSC fails with "SDK path could not be resolved"
CSC fails with "SDK path could not be resolved"
Product: Fedora
Classification: Fedora
Component: mono (Show other bugs)
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Timotheus Pokorra
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-12-31 05:55 EST by Matthias Mailänder
Modified: 2016-01-04 09:13 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-04 09:13:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthias Mailänder 2015-12-31 05:55:35 EST
Description of problem:
error CS8001: Warning as Error: SDK path could not be resolved

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

How reproducible:

Steps to Reproduce:

Actual results:
error CS8001: Warning as Error: SDK path could not be resolved

Additional info:
Comment 1 Matthias Mailänder 2015-12-31 06:01:43 EST
See https://github.com/OpenRA/OpenRA/issues/10248 for the downstream bug.
Comment 2 Timotheus Pokorra 2016-01-02 14:32:48 EST
It seems that dmcs should be deprecated.

easy solution:

change in your Makefile for OpenRA:

CSC         = mcs

then make core works for me.

It seems that dmcs targets the 4.0 sdk, which is not delivered with Fedora 23 anymore. The 4.0 sdk is only available as binaries in the Mono 4.x tarball, and we cannot build the files 4.0 sdk from source.
So we are only providing the 4.5 sdk.

So we could probably dump the /usr/bin/dmcs because it is not useful anymore at all.
Comment 3 Matthias Mailänder 2016-01-03 15:58:19 EST
Have you reported that the 4.0 SDK sources are missing in the tarball and/or is this already fixed in Mono 4.2.1?
Comment 4 Timotheus Pokorra 2016-01-04 02:04:15 EST
As far as I understand, the support for .Net 2.0 was dropped: http://lists.ximian.com/pipermail/mono-devel-list/2014-October/042145.html
This somehow also affected all versions up to and including .Net 4.0, and only .Net 4.5 is supported in the release branches.
I guess the reason was that the code is now much cleaner, and only one .Net SDK needs to be supported by the Mono team.

Also reading http://www.mono-project.com/docs/about-mono/languages/csharp/
"Starting with Mono version 2.11 a new unified compiler mcs is available. It replaces all previous runtime specific compilers (gmcs, dmcs, smcs). They still exist (as scripts only) to ease the migration path to mcs but we strongly recommend to use mcs."

It seems to me that the best way is to use the latest .Net framework, ie. 4.5.
For Fedora 23, when we upgraded to Mono4, we replaced all occurences of TargetFramework in the csproj files with 4.5:

eg. for MonoDevelop: in http://pkgs.fedoraproject.org/cgit/monodevelop.git/tree/monodevelop.spec#n78

you find these lines:

#Fixes for Mono 4
sed -i "s#gmcs#mcs#g" configure
sed -i "s#gmcs#mcs#g" configure.in
sed -i "s#mono-nunit#nunit#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 5 Timotheus Pokorra 2016-01-04 09:13:05 EST
I have now removed dmcs from Mono in Rawhide to avoid confusion:


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