I am seeing the following mix of references specified for a csc command in a Visual Studio build:
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll
/reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll"
/reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.Runtime.Serialization.dll"
/reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.ServiceModel.dll"
/reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll"
(The above is from sample code supplied with the EMGU system.)
I was under the impression that the proper way is to use reference assemblies for all cases when/where available.
Why would the developers include some assemblies as reference, and some as absolute? Can we assume there was a deliberate reason?