I am using:
- MonoDevelop 7.1
- .NET Framework 4.6.2
- Mono 5.0.1.1 (2017-02/5077205 Thu May 25 09:16:53 UTC 2017) (64-bit)
- No PCL or profiles (to my knowledge)
- msbuild 15.2.0.0 (Thu May 11 17:28:41 UTC 2017)
<NoStdLib>
is not specified; that is, it's left at its default.
<TargetFrameworkVersion>
is set to v4.6.2.
When I build in the IDE, I see no warnings or errors. However, when I build the solution with
msbuild /v:detailed my.sln
I see a few of these messages:
Dependency "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea77
98e, Retargetable=Yes".
Could not resolve this reference. Could not locate the assembly "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
Browsing through the Mono files, all of the following assemblies match the above version and key:
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile102/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile19/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile225/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile5/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile92/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile47/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile14/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile24/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile328/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile6/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile158/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile255/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile37/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile240/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile136/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile147/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile42/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile344/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/Profile/Profile336/mscorlib.dll
/usr/lib/mono/xbuild-frameworks/.NETPortable/v4.0/mscorlib.dll
Other mscorlib
assemblies either have the wrong version, or have the key token b77a5c561934e089
instead of 7cec85d7bea7798e
.
My questions are:
- Why is my solution attempting to make a reference to a portable .NET?
- Is there an assembly reference tree tool I can use to find out what the referring culprit is?
- Why is it that this is a non-fatal error, and doesn't even appear in the IDE build output at all?
- Should I make a manual reference to one of these assemblies? If so, which profile?
- If I do not make a reference to one of these assemblies, what are the consequences?
- Does the fact that all of my assemblies are strong-name-signed affect the importance of resolving this error?
Thanks in advance.
Edit:
Using monodis --assemblyref
, I see that the problem is Common.Logging
:
Common.Logging.dll
AssemblyRef Table
...
4: Version=2.0.5.0
Name=mscorlib
Flags=0x00000100
Public Key:
0x00000000: 7C EC 85 D7 BE A7 79 8E
./Common.Logging.Core.dll
AssemblyRef Table
...
1: Version=2.0.5.0
Name=mscorlib
Flags=0x00000100
Public Key:
0x00000000: 7C EC 85 D7 BE A7 79 8E
./Common.Logging.NLog41.dll
AssemblyRef Table
...
6: Version=2.0.5.0
Name=mscorlib
Flags=0x00000100
Public Key:
0x00000000: 7C EC 85 D7 BE A7 79 8E
This, despite my packages.config
specifically asking for .NET 4.62:
<package id="Common.Logging" version="3.3.1" targetFramework="net462" />
<package id="Common.Logging.Core" version="3.3.1" targetFramework="net462" />
<package id="Common.Logging.NLog41" version="3.3.1" targetFramework="net462" />
So I guess this is a bug in Common.Logging
?