Visual Studio 2005

[Mads Peter Nymand]

Hi,

Background: I'm a Java programmer new to c# and Visual Studio.

Problem: When I compile in Visual Studio 2005, the compiler complains,
that it can not find several different namespaces. Examples:

Error 1 The type or namespace name 'Soap' does not exist in the
namespace 'System.Runtime.Serialization.Formatters' (are you missing an
assembly reference?)

Error 2 The type or namespace name 'Drawing' does not exist in the
namespace 'System' (are you missing an assembly reference?)

When I compile from the command prompt there are no problems.
What can be wrong? It seems like Visual Studio is somehow not including
the full API.

Kind regards,
Mads Peter Nymand

 

[Stoitcho Goutsev \(100\)]

The VS doens't reference all dlls. How many dlls it references depends on
the type of project you've created (wizard).

If you open the "References" node you'll see all ther referenced assemblies.
Keep in mind that one namespace might be spread over more than one assembly
(even though it is not the common case), so you may have some classes form
the namespace available and some not.

If you in doubt what dll to reference open the MSDN docs (if it goes for a
API type) and in the "About ... type" section you can find out the dll it
comes from.

Why it can compile in command prompt? I guess is because the line compiler
is set up to reference bigger set of dlls.

 

[Mads Peter Nymand]

Thanks a lot for your answer.

Maybe the command prompt compiler is set to include the full C# 2.0
Class Library the same way, that the Java command line compiler is set
to include the full java API class library.

It raises a new question though:

In the command prompt and in the Java IDEs I have used, the whole API
class library of the SDK is included by default. Why isn't it so in VS.
Why do you have such a limited set of references in a C# project in VS?
In the top of a file, you are declaring which namespaces to use. That
makes sense, because you have to define, which namespaces the classes
you are using, are belonging to. In my opinion, it does not make sense,
that you have to define new references (add refernces) at project
level, when you are using namespaces, that is part of the standard C#
library. That's just extra work for no reason. Can anybody give me a
reason why it is so - better stucture? faster execution? - something

Mads Peter

 

[Jon Skeet [C# MVP]]

Thanks a lot for your answer.

Maybe the command prompt compiler is set to include the full C# 2.0
Class Library the same way, that the Java command line compiler is set
to include the full java API class library.

No - it's set to include a certain set of assemblies. (The difference
is that with Java, all the standard libraries are in one big jar file -
rt.jar.)

If you look in your .NET framework directory, find a file called
csc.rsp. That lists the command-line options which are specified by
default.

It raises a new question though:

In the command prompt and in the Java IDEs I have used, the whole API
class library of the SDK is included by default. Why isn't it so in VS.
Why do you have such a limited set of references in a C# project in VS?

Because Java doesn't really have "references" to start with. You can
put lots of things on a classpath, but it's not really the same thing.
Instead, it's got a huge standard library in one big file. That's not
really great from an organisational perspective.

In the top of a file, you are declaring which namespaces to use. That
makes sense, because you have to define, which namespaces the classes
you are using, are belonging to. In my opinion, it does not make sense,
that you have to define new references (add refernces) at project
level, when you are using namespaces, that is part of the standard C#
library. That's just extra work for no reason. Can anybody give me a
reason why it is so - better stucture? faster execution? - something

Firstly, it's not the standard C# library - it's the standard .NET
framework. C# is just *one* language targetting the .NET framework.

Secondly, namespaces and assemblies are very different things. An
assembly often happens to have types within a namespaces of a similar
name to the assemblies, but they're different to namespaces.

"using" directives just provide shortcuts so you don't need to type the
full name of every type you're using. Assembly references govern which
types are available in the first place.

The .NET framework is better organised than Java in terms of the
standard library being broken up into separate units of functionality.
If you don't need anything to do with System.Messaging, why make either
the compiler or the runtime load that assembly?

 

[Mads Peter Nymand]

Thanks a lot for your answer Jon, that cleared things up pretty well.

The .NET framework is better organised than Java in terms of the
standard library being broken up into separate units of functionality.
If you don't need anything to do with System.Messaging, why make either
the compiler or the runtime load that assembly?

I see your point. Does the Java compiler and runtime have to load the
hole standard library (rt.jar) everytime you compile and run a java
program? If this is the case, it doesn't seem optimal. I always thought
that Java only loaded the packages specified in the import statements.

Mads Peter

 

[Jon Skeet [C# MVP]]

Thanks a lot for your answer Jon, that cleared things up pretty well.


I see your point. Does the Java compiler and runtime have to load the
hole standard library (rt.jar) everytime you compile and run a java
program? If this is the case, it doesn't seem optimal. I always thought
that Java only loaded the packages specified in the import statements.

No - the import statement is only the equivalent of the "using"
directive in C#. It's just a namespace issue.

Now, I don't know the extent to which the Java runtime loads the whole
standard library. I'm sure it loads the index telling it which classes
are available and where within the jar file. My guess is that it then
memory maps the file and accesses the classes it needs as it needs
them.