[Mono-bugs] [Bug 353597] System.Xml.Linq installed in 3.5 profile while System. Core in 2.0 profile
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Mon Jan 14 07:20:29 EST 2008
https://bugzilla.novell.com/show_bug.cgi?id=353597
User gert.driesen at pandora.be added comment
https://bugzilla.novell.com/show_bug.cgi?id=353597#c1
Gert Driesen <gert.driesen at pandora.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gert.driesen at pandora.be
--- Comment #1 from Gert Driesen <gert.driesen at pandora.be> 2008-01-14 05:20:28 MST ---
In my (humble) opinion, these should all be installed in the 3.5 directory.
Users should be aware what framework version of .NET or Mono "Profile" they're
using, and choose explicitly to target a specific version instead of seemlessly
rolling into a new version.
I think there probably is already enough confusion with regards to our version
scheme (when compared to MS .NET). THe only constant right now was that our
"profiles" matched a given framework version (not CLR version). So I'd vote
against combining multiple .NET framework versions in a single mono profile.
In fact, I think the way our toolset is named and packaged could have been
better. We currently have a mixture of unique names (mcs <-> gmcs), and version
suffixes (al <-> al2). While other tools are even only available for a given
profile version (eg. xsd).
If we had at least a complete set of tools available for each profile, then we
could have separate distributions for each profile, or at least have clearly
defined dependencies.
Even if the 2.0 and 3.5 profile use the same CLR and core system assemblies,
the toolset of both profiles is different (new changed/functionality, new
tools, ...).
If API compatibility with MS is considered "important", then so should tool
compatibility be.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the mono-bugs
mailing list