Ziya1995 wrote:
Guys, I really ask a simple question, you get my question as something hard, but it is not, look:
I open new Windows Forms project in Visual Studio, then I add references like System.Drawing and so on.
But how can I know how to add a reference, if I don't know names of references.
I repeat, I use namespaces, add references and so on, and now I wanna add a reference to use it, how to add if I don't know a name of reference???
Until today I go to .NET Framework Class Library and copy reference names, but Windows Forms provides access only to a part of the whole Framework and it is not only about System.Windows.Forms namespace, it is also about, for examples, next ones:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Linq;
using System.Text;
And now I am a simple guy, I must know names of references, to write them and add, that is one the easiest questions.
I read what you write and understand you are really smart and wise people, but the problem that you are so professional that don't understand my simple question, because you get it as something very hard.
Only now you are getting a bit closer to your question. Before, you never mentioned that you there is problem because you "don't know a name of reference". You said that you were "curious".
First thing to understand is: you listed some
using
declarations with some namespace. But namespaces are not references. References are
assemblies. I don't want to add redundant explanation on what namespaces are, but want to point out: the assembly names are close to the namespaces, but this is done only for convenience. Technically, those names are totally unrelated. Also, there are no any predefined correspondence between those names. In particular, it means:
- Any assembly can define types using different namespaces, those different namespace don't have to be related.
- Two different assemblies can define types using the same exact namespace. This approach is actually used in .NET FCL. For example, the namespace "System" is used for defining types by two assemblies: "System" and "System.Core".
- The assembly name (this is a big separate topic: strong names can be used or not, the names of the main executable module can be used for referencing) does not have to match to any namespace. For example, as far as I know, .NET FCL doesn't declare namespace "
System.Core". - In rare cases, you can even get fully identical full type names which come from different libraries. There is a little-known feature for the resolution, extern alias. Our inquirers sometimes faces such cases; I helped to resolve such situation, maybe just couple of times.
Now, let's create a brand-new Forms project in Visual Studio, from a standard template and look at the references:
System, System.Core, System.Data, System.Data.SetExtensions, System.Deployment, System.Drawing, System.Forms, System.Xml and System.Xml.Ling. Do one really needs these references (all from the GAC, by strong names)? No! For forms programming, you only need:
System, System.Drawing and System.Forms. That's
all!
So, what to do? If I create a real thoroughly developed project, I
actually remove all the references except those three, but I also leave System.Core (which is not formally needed for Forms programming), and, depending on my expectation and knowledge of future development of the project, leave System.Xml, often also System.Xml.Linq. Everything else is totally redundant and can only confuse. It may make the project fail to compile, but I also remove a number of auto-generated files and auto-generated code. And Visual Studio have very convenient feature, remove unused "using".
I add all other references at the moment I really need them and only if I need them. I don't want to insist on my style of developing projects, but I insist that the thoroughly developed project should not have any redundancies of this sort; it is helpful for future developers who support the project to see what is actually involved. That's why I would recommend my course of action.
By the way, why Microsoft creates so redundant project templates? I'm sure, support of the thorough developed project is by far not the first priority. First priority is to have as many developers as possible, and that it done to increase the probability of having it all "up and running". For experienced developers this redundancy is not a problem.
Now, how to know what other assemblies to add to the project?
The short answer is: there is no a way, by a very apparent reason: only the developer knows what to add. There is nothing wrong with that. First of all, you do have a list of possible references, if we only considered the assemblies from GAC.
When you add such references, we use the tab ".NET" of the "Add Reference" window. Which one to add? There is no a predefined recipe. You have to gradually learn what .NET FCL can help you with and know what you really need and what not. Note that there are other kinds of references: 3rd-party and your own. Both kinds can be strongly-named or not (they should better be), put in GAC or not (should be put in rare cases and responsibly). For your own assemblies you reference, the best way is to put them all in the same solution and reference by projects (the tab "Projects" of the "Add Reference" window).
See also:
http://en.wikipedia.org/wiki/Framework_Class_Library[
^],
http://en.wikipedia.org/wiki/Global_Assembly_Cache[
^],
http://en.wikipedia.org/wiki/Strong_key[
^].
—SA