I'm a student and started developing some projects in VB.Net and I'm liking it a lot. However, I asked this question to some colleagues and they couldn't answer. Even my teacher wasn't able to clarify what was exactly VB and .Net. I have checked this question here but even the accepted answer gives me some doubts.
For example, for this bit of code here
Class Example
Private _value As Integer
Public Sub New()
_value = 2
End Sub
Public Function Value() As Integer
Return _value * 2
End Function
End Class
Module Module1
Sub Main()
Dim x As Example = New Example()
Console.WriteLine(x.Value())
End Sub
End Module
How can the language be separated from the framework? I know the language is syntax and all but, where is the framework?
I've read that frameworks contain libraries: what are exactly libraries? The language (syntax and all) I can see it, it can be seen, but is the framework visible too? If so, where?
So in a VB.Net application, when I look at the code, all I can see is VB: the same goes for C#.Net applications.
Maybe silly example: For instance, for a car to function, all components must be good - from the tires to the hood, the engine, the fuel - but all of them are visible, and while from the outside we can't see the oil or fuel running inside or the pistons working, we can see them if we want.
Is it possible to see all the components when looking at a VB/C# .Net application? I mean, to look at code and clearly distinguish what is VB or C# and .Net?
Thanks
There are three primary parts to the .NET framework:
Compiler (MSBuild)
Runtime environment (CLR) - virtual machine, garbage collector, etc.
Supporting libraries (FCL)- System, ADO.NET, LINQ, WPF, WCF, etc.
All three of the above are included with the freely-distributed .NET Framework. The term .NET Framework refers collectively, and loosely, to all of those things, but they each perform very different roles. The answer to your question is different for each of those parts.
Compiler
As you probably know, you cannot run VB.NET code directly. It must first be compiled into an executable which can be launched as a Windows process. The compiler is used to compile a variety of high level languages (such as VB.NET and C#) into assemblies (e.g. EXEs, DLLs). Unlike native compilers, though, .NET assemblies do not contain native machine code. Instead, the .NET compiler compiles into .NET assemblies which contain MSIL code. MSIL is a slightly-higher-level-than-machine-code language which, in theory, can be run by a virtual machine on any platform.
The compiler is obviously not visible in your code. Obviously there is no place in your code where you can say "that's the compiler". Rather, the compiler is the tool that you use to compile all of your code. The compiler, though, does dictate what languages you can use. If the .NET framework does not contain a Ruby compiler, then you can't very well write a .NET application in Ruby. So, in that way, the fact that your code is written in VB.NET or C# at all is the indication that it will be compiled using the .NET Framework.
You may be thinking, "The compiler isn't part of the framework--that's part of Visual Studio." But if you were thinking that, you would be wrong. The compiler is installed as part of the .NET framework. You don't technically need Visual Studio to compile a .NET application. You could write an application in any .NET language, using Notepad, and then compile and run it with the .NET Framework without ever having installed Visual Studio.
The compiler portion of the .NET Framework is referred to as MSBuild.
Runtime Environment
Since the compiler compiles your high-level code into MSIL assemblies, rather than into native machine-code binaries, you must have the .NET Framework installed in order to run any .NET application. When you run a .NET application, the Framework is responsible for just-in-time (JIT) compiling the MSIL code into machine code so that it can be executed on your current platform. It also provides the memory management features such as garbage collection.
The same runtime environment is shared by all .NET languages (since all .NET languages compile to MSIL code). Therefore, it's not a VB.NET runtime environment nor a C# runtime environment, but rather, it's a MSIL runtime environment. Instead of having one runtime environment per language, there is actually one runtime environment per platform. A separate environment must be custom implemented for each processor architecture and each operating system on which the Framework will run.
This part of the framework is largely invisible to you and your code. There are some methods you can call to access the GAC, or the garbage collector, or the .NET security system, but other than that, you don't even know it's there. Unless the Framework isn't installed, that is--in that case, it becomes clear very quickly just how necessary it is.
The runtime-environment portion of the .NET Framework is referred to as the Common Language Runtime (CLR).
Supporting Libraries
The .NET Framework comes packed with many extraordinarily useful libraries (DLLs). For instance, every application references the mscorlib.dll and System.dll libraries, which provide many of the core data types in the System namespace. There are many other libraries which you can optionally reference with your projects as necessary.
These supporting libraries are provided as already-compiled MSIL assemblies, so they can all be referenced and used by projects written in any .NET supported language. When you call Console.WriteLine("Hello World") in VB.NET and Console.WriteLine("Hello World"); in C#, you are calling the exact same .NET Framework library. The Console class is defined in the mscorlib.dll library. It doesn't matter which language you use to call it, it always does the same thing.
The supporting libraries are very visible in your code. Any time you use anything that is not explicitly defined by you in your own code, you are using the Framework (unless, of course, it's something from a third-party library). In your example code above, you are using Integer and Console. Both of those types are defined by the .NET Framework's supporting libraries (both are defined by mscorlib.dll). In other words, the language is all of the syntax that you use to make the calls to the Framework. Everything else is the Framework.
If you want to "see" the supporting libraries, the best place to start is in Visual Studio. You can use the Object Browser to browse through all of the types defined by the libraries that you currently have referenced in your project. If you want to reference more .NET Framework libraries, go to your Project Properties designer's References tab, click the Add... button, then select the Asseblies > Framework option. That will list all of the supporting libraries that are provided as part of the .NET Framework. If you want to find out more about any of the functionality provided by any of those libraries, your best resource is the MSDN (and Stack Overflow, of course).
The supporting libraries portion of the .NET Framework is referred to as the Framework Class Library (FCL).
Here is how I envision the two
The framework is the set of libraries, APIs and runtime components that are available for the language to use
The language is the syntax by which the framework is accessed
In many cases it's hard to separate the two because the language when used is nearly always accessing some part of the framework. Take for instance even this very simple definition
Class Example
End Class
Even though it is unstated, this definition depends on the targeted framework having a definition of System.Object. This is necessary for the language to setup the appropriate base class for Example.
You have to keep in mind that if you're using a programming language, at some point it all must boil down to binary 1's and 0's.
This means that when your program gets compiled and run, it's making use of the C# compiler. The C# compiler is a program written in a native language (probably c or c++). This program allows yours to be converted into stuff that the .net framework runtime can understand. Essentially, your C# code becomes some sort of intermediate bytecode.
Similarly, after your program is compiled into this intermediate bytecode, it is run on top of a virtual machine (JVM for Java or the .net framework runtime for C#). This virtual machine is a pre-compiled program written in a native language (c or c++), which allows your program to interface with the computer's processor in a way that both understand.
All of these pre-written, pre-compiled pieces are part of a framework. They are installed to your machine in some particular location (which is why they might not be readily visible with the rest of your code and assets) and provide APIs to anything that wants to make use of them.
The APIs are analogous to the understanding between a gas pedal and an engine. An engine accepts more fuel as a result of someone pressing the gas pedal. In some sense, the engine "talks" to the gas pedal and understands that if you press firmly on the pedal, the engine should respond by injecting more gasoline into the combustion chambers.
These individual pieces, along with their "understandings" represent a framework. You might add a "Driver" who can operate a gas pedal as your "C# Application".
How can the language be separated from the framework?
For example... take for instance English, English is a language, while a book would be a Framework. In this example, you can write whatever you want in English, but you can't write in "The Hobbit", because it is a book, not a language.
However, you can make references to the book. For instance you can talk about Trolls, and you don't have to define it's behavior or looks, because the book already defines them for you.
Where is the framework?
The framework exists whenever you make reference to it. In the Trolls example, if you ask "Do you know how do Trolls look like?", I would need a context for that, it may be Harry Potter's, Tolkien's, World of Warcraft's, etc. And I will give you compilation errors because I can't understand you.
If however we "use" the same "Framework" (book), or if you tell me about them before, I would be able to respond you (compile).
Is the framework visible too? If so, where?
VB/C# are languages, you can't "really see" where it is, because you write it. It is like asking where is English. You can however compile it, and that is what you can "find", just like you can find a printer.
The Framework is a set of libraries/utilities already packed into a beautiful black box that you download and trust your life to.
VisualStudio helps you a lot, and it will hide "complicated stuff", imagine like it is a movie called The Lord of The Rings, and it removes a lot of stuff that you can't really look into unless you read the book.
You can't really dive into "what .NET does internally", because it is closed software. Imagine that I burn down all the books and you have to trust the movie.
But you could use an Open Source example such as Struts (a JavaEE Framework) because it is open source (books should not be burned in Open Source examples).
Here is an abstract example.
Speech is similar to a framework, you have phonation, producing sound;
resonance; intonation, variance of pitch, etc. Those are all the building blocks for communicating.
To speak a specific language, you must utilize phonology, morphology, language syntax, proper grammar; semantics, etc - all the rules for that Language.
...
In a programming framework, you have building blocks (code libraries, dependent files, specific folder/file layout, ect.) that you might need to complete a programming task.
A programming language is the set of rules you must abide to in order for your application to correctly work.
....
In the Java programming language, I could open notepad and write java code, compile it, and run it on any machine that has the JVM installed.
Java Server Faces (JSF) is a framework where a Model-View-Controller (MVC) paradigm exists as the basis to run web applications. You have necessary dependent files (like web.xml) that must exist for the server to correctly implement, structured layout of classfiles, and implementation/configuration of other libraries. In an essence, your files are still written in the Java Programming language and your syntax must be correct, but if you want to build a web application using that framework, you must have adhere to those other specific patterns and constraints.
We have Bigloo.NET does anyone know of such a project that offers the same but for the Java and/or Objective-C language?
I am developing a component of a project that will also have a Windows and Apple GUI built around it. Would be nice if I could develop this component in a single language and have it compiled into the native language for the current GUI. Any ideas?
Do you know that Bigloo initially targeted the JVM, and only later the CLR? I'm assuming you do, and that it's insufficient for you. If you weren't aware:
Java code and Bigloo code can be
merged together. Bigloo functions can
call Java functions and vice-versa,
Bigloo code can use and instantiate
Java classes. Bigloo functions and
variables can hold Java values (Java
classes values). Bigloo data
structures can point to Java data
structures and vice-versa.
If that doesn't do it for you, but you still want a Lisp, Clojure is a Lisp, though neither Scheme nor Common Lisp. It shares with Scheme a single namespace for functions and variables, however, and I've found it pretty comfortable in my short acquaintance with it. Clojure is also Java --- anything you do from Clojure can be used from plain Java, and vice versa.
Maybe you could give more detail on why Bigloo doesn't work for you, and that could help us give better answers.
Schemes for the JVM: SISC and JScheme. Both are interpreters with good Java interoperability.
I could use a little advice on naming my assemblies
(ie. When to turn a logical naming convention in my
namepaces into its own DLL).
I recently downloaded an example project with a ton of
class libraries in it that almost exactly mirrored the
namespaces.
To date, I have been building one massive class
library - MyProject.DLL - and referencing it in my
project. This way, I only need one library and can
access all namespaces using it.
But, in the project I downloaded, there seems to
be a DLL for every namespace (and, in some cases,
subcategoreis within a namespaces. For example,
SomeProj.Web.Security has SomeProj.Web.Dll and
SomeProj.Web.Security.Dll).
I understand that having multiple DLLs can make
it easier to focus on particular areas of the project
(and, probably, updating the DLL withing the site
easier) but is there a best practice here?
Thanks in advance...
OK, this pretty much answers my question:
http://msdn.microsoft.com/en-us/library/ms229048.aspx
I've been working non-stop for the last three days on a completely managed interface to Erlang. At this point, I've decided that there simply must be an easier way. I've got a little over 3000 lines and it's not even in a compilable state yet. To be honest, I'm getting lost in my own code.
So, I then remembered that Erlang has a C library called erl_interface. Unfortunately, it only comes as a .LIB file, which isn't usable via P/Invoke. I'm now investigating ways to expose the static library through a DLL.
I'd like to stay away from Visual C++, mostly because I'm not a C/C++ programmer by nature and I find it really difficult to configure. TinyC is my compiler of choice when working with anything in C.
How can I go about this?
I know I can link erl_interface to a DLL, but how can I expose the functions? Do I have to essentially wrap each and every one of them in my own exports? That probably won't be a problem, since I could write a script to generate the code from the header file. But is there an easier way that I just don't know about?
Also, please don't recommend OTP.NET. It's a nice library, but I'm looking to use this is a large project, so I'd like to keep it in-house.
So, your problem is one of turning a static lib into a dynamic one.
The least-effort solution would be to write a thin shim file in 'C', that just delegates to the files in the .lib e.g.
ReturnType my_method1(args...) {
return real_method1(args...);
}
...
and build a DLL from that and the static lib.
Afterthought -- There is another approach you could take -- which is build the .lib into a C++/CLI assembly and do the transition/wrapping in that. It's what C++/CLi is there for, after all.
If you want some help with interfacing to Erlang with C, have a look at "EPAPI" (Erlang Port API) link text. You can of course browse the source code since it is hosted on Google Code. A DEBIAN repository is also available.
For me, a library is a collection of classes that do useful things. Typically something, that can be useful in a lot of projects. Is that also the case in terms of objective-c? What exactly is a library there? Only classes that have methods? Or also collections of functions? And do they have to be compiled to be called a "library"? Where is the segregation between an "Framework"? Aren't bove the same thing?
According to Wikipedia: "Frameworks are functionally similar to shared libraries, a compiled object that can be dynamically loaded into a program's address space at runtime, but frameworks add associated resources, header files, and documentation."
A framework is essentially a shared library (binary, similar to a DLL) in a bundle that also includes all of the information needed to use that library (like header files, documentation, internationalization resources, etc). A framework without all of the extras is just a library.
There is no requirement that a framework be object-oriented in nature, though I assume that's the norm with Cocoa.
For Cocoa, the concept of a framework generally replaces (enhances) the concept of a library. However, the Objective-C toolchain imposes no such requirement. You can use source-only "libraries" or unix-style binary libraries (e.g. an .so file). I think of a "library" in these generic terms... it's just a collection of useful code, in source or binary form. A framework, on the other hand, is a specific thing with a specific meaning for OS X.
Assuming you are talking about a library that uses the Cocoa frameworks and not just one written in the plain old Objective-C language, a library (or framework) is a collection of classes that work together to perform a specific task. I would not organize an ObjC framework as a collection of functions since that totally goes against the paradigm of the language.
As for the difference between a library and framework, that's probably a bit subjective. To me, a library (in the context of your question) is something written in C that probably more closely resembles a non-OO collection of functions. A framework would be a full package of classes as I described above. So the Messaging framework on CocoaDev would be a framework, whereas the sqlite3 APIs you can access on the iPhone would be a library. Again, that's just me. Other people may interpret the terms differently.