A TFS project is not analogous to anything in Visual Studio. It is more for permissions and work item types.
For most people/teams they will work out of the same TFS Project. I've never strayed out of my TFS Project. We just have different folders for each Visual Studio Project. External teams have a different folder for their team still within our same TFS Project.
The only time I've seen people use other TFS Projects is when they have a different permission model, or different work item types they are tracking against.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
Keep in mind our WPF application isn't the only application that uses these 3 libraries, we have other solutions that use these libraries.
I think this here is what defines it. If these projects are used by more than just one solution, it is usually a good idea to keep them independent.
As for your TFS question, I think the other option you are missing is creating 1 independent Team Project for all these libraries so as for them to remain completely independent from the projects that are using them. As always the devil is in the details and it will depend, among other things, in how these libraries are connected to one another.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
Because many programmers or software engineers are overwhelmed even by single inheritance. Most classes with multiple inheritance in C++ I saw, were badly designed. But you can implement as many interfaces as you like. Try it, count them and give feedback
If we take a look at how Visual C++ implements multiple inheritance (on binary level) it becomes obvious that even the binary stuff under C++ is built up from the composition of single line inheritances (the reason for multiple vtables in the same object). So we can consider multiple inheritance as a language feature, a "syntactic sugar" that is somewhat a mixture of single line inheritance and object composition in "machine code". It would be possible to create a language supporting multiple inheritance on top of .Net with the same principles but multiple inheritance brings up some design-related questions. I think the single line inheritance is rather a design decision in C#.
Actually, the reason I mentioned it in regards to .NET not supporting it is because (to keep it in line with general .NET interoperability reasons), it would have to be baked into the CLS so that other languages could interact with it.
From Anders Hjelsberg:
"The question is, What about multiple inheritance? And will we get it? If not, why? The easy- the cop out answer at this point is that if we were going to have it, we needed to have it in the first release because it’s way too hard to add after the fact. Even if we did add it, we could never mandate it as being part of the CLS I don’t think, meaning that every language can support it. Multiple inheritance and VB, I don’t think that’s a great cocktail. If we had multiple inheritance, if it wasn’t usable in APIs, I wonder how useful it would really be. I think also when you analyze what is it that people want to do with multiple inheritance, in the vast majority of cases I think there are simpler answers than the full multiple inheritance enchilada with virtual base classes and the diamond problem and all of that stuff."
I don't just make this shizzle up after all.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
Yes, this was one thing I was thinking about because if you wanted to implement multiple inheritance on top of .Net then it would require you to introduce some anonymous base classes (that embody the single line inheritances inside the composite class) and then the composite class itself is just the syntactic sugar provided by the language and inaccessible by the other languages, and of course you would be unable to reach the anonymous classes (classes with auto-generated name) too from other languages. Only some parts of your code (with single line inheritance) could be reached from other languages. My statement about the possibility of providing multiple inheritance in a language on top of .Net still holds. The fact that they allowed just single line inheritance in .Net that is an intersection between languages was a wise decision though, read a list of reasonings about that somewhere.
What features would you like to have from C++ templates? I think they are overcomplicated, and since the C++ specification describes just how they should work - and nothing about implementation - different C++ compilers handle them differently. I could tell you at least 2 big horror stories about this (one bug and one source code porting).
The arithmetic part is indeed a huge problem in C#. About the template specialization: I think they are rarely used in C++ and even in those cases I've often use of it without good reason. A nice use of it is optimization like std::vector<bool> with packed bits, or code beautification. In other cases where it was used some other simpler solution could also do the job for me.
My opinion: Because multiple inheritance brings some problems to the langauge and its easier to go with single line inheritance and multiple interfaces. As an example I would mention C++ that supports multiple inheritance but has no interfaces. Because of this sometimes it occurs that you are forced to use virtual inheritance that usually isn't a clean solution compared to single line inheritance + interfaces. My experience is that virtual inheritance is avoided in C++ whenever possible because noone likes it. Besides that multiple inheritance can come handy but doesn't add more than the single line inheritance+interfaces solution that is automatically immune to virtual inheritance problems. Google "virtual inheritance" to find out more about this problem.
In contrast to some "experts" here on CP, I worked with a language which supports multiple inheritance: C++ (i.e. non-managed C++). Hence I think that your question is an appropriate question, it does not deserve downvoting.
Let me give you an example which shows where multiple inheritance is a pain. Imagine two base classes which have a function with the same name.
When you create a class inheriting from both of these classes
publicclass CombinedClass: FirstClass, SecondClass
//some other code
it inherits the DoSomething() method from both FirstClass and SecondClass.
When you call DoSomething() on an instance of CombinedClass
CombinedClass c = new CombinedClass();
which of the DoSomething() methods do you call - FirstClass.DoSomething() or SecondClass.DoSomething()?
Other object oriented languages may offer more features which are not supported in the .Net world, e.g. inheritance of static functions and properties.