After switching to latest version (4.2), I'm not able to build anymore:

I've some remarks on the latest release of DO.Net 4.2 :

  • AddUpgradeHint not up to date in manual

Signature has changed : manual needs to be updated accordingly

  • Key.ToTypedKey<t> is gone How can I get an entity from its Key instance?

Scenario : I'm using Key.Parse() with a string, and I want to get My Entity instance from the key I get from Key.Parse()

  • Extensions methods in System namespace : this is a real problem

I'm not able to compile, because we have our own Stream.CopyTo() extension method.

Every C# file has an 'using System' at the start : we can't remove it. So the use of your extension methods is mandatory, if we have a reference to Xtensive.Core This not acceptable for a library : how are we supposed to do if every third party library has it own extensions methods in System?

This is very confusing: if I want to have my own extension method, I will not be able to tell explicitly in my code to the other devs in the team that this is the method to use, not your method.

Worse : you are actually potentially incompatible with other third party libraries. If they define exactly the same extension methods with the same signature, this will prevent compilation.

I suggest :

  • That you put extension methods concerning your own types (like TupleExtensions, ...) in some namespace you own (Xtensive.Core ?)
  • That you put extension methods concerning framework types (like StreamExtensions, StringExtensions, ...) in some special namespace (Xtensive.Core.Extension ?)

I'm waiting for your feedback on those topics.


This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Apr 02 '10 at 14:13

olorin's gravatar image


One Answer:

We've been discussing this internally yesterday, and finally decided to move all expension methods from System to Xtensive.Core namespace. The idea to move a part of extension methods to a special namespace seems bad, because:

  • Normally no any conflicts are expected here; and even in case of conflict such extension methods can be called using standard method call syntax.

  • Having just two namespaces (Core & Storage) where extension methods are located is much better than 3.

  • It's normal when extension methods are located in one of widely used namespaces of a library.

On the other hand, I think we really made a big mistake while moving them to System. The only reason for doing this was intention to simplify usage of these methods for developers that don't a tool like ReSharper. But besides obvious reasons for not doing this (convention violation, possible conflicts) there is another one: Sandcastle isn't capable of documenting System namespace from your own assemblies. So in fact, currently all these methods aren't even documented.

Taking all these "cons" into account, it's really better to move them to Xtensive.Core.

answered Apr 03 '10 at 10:19

Alex%20Yakunin's gravatar image

Alex Yakunin

olorin wrote: Hi,

Thanks for your answer : I think this is a good idea.

Could you post a message when this is done? We could use a nightly build ;)

Keep up the good work! Regards

(Apr 03 '10 at 10:19) Editor Editor's gravatar image

Yes, I'll post a message here. Concerning nightly build - ok.

(Apr 03 '10 at 10:19) Alex Yakunin Alex%20Yakunin's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA