469,658 Members | 1,810 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,658 developers. It's quick & easy.

What is .Net?

I have read threads here and there and I have looked at MS but I can not get
a clear understanding of what .Net acutally is. I understand that C++ and Vb
and other languages are being out a .Net. I get some idea that it still is
OOP. I think it has different ways of managing the code. But what is it?

Thanks
--
SailFL
Aug 27 '05 #1
13 1909

"SailFL" <Sa****@discussions.microsoft.com> wrote in message
news:51**********************************@microsof t.com...
I have read threads here and there and I have looked at MS but I can not
get
a clear understanding of what .Net acutally is. I understand that C++ and
Vb
and other languages are being out a .Net. I get some idea that it still
is
OOP. I think it has different ways of managing the code. But what is it?

Thanks
--
SailFL


Here are some articles that will help:

http://msdn.microsoft.com/library/de...tframework.asp

http://msdn.microsoft.com/library/de...asslibrary.asp

http://msdn.microsoft.com/library/de...tframework.asp

http://msdn.microsoft.com/library/de...ials_start.asp

--
Peter [MVP Visual Developer]
Jack of all trades, master of none.
Aug 27 '05 #2
Thanks for the addresses. I will do some additional research.

--
SailFL
"Peter van der Goes" wrote:

"SailFL" <Sa****@discussions.microsoft.com> wrote in message
news:51**********************************@microsof t.com...
I have read threads here and there and I have looked at MS but I can not
get
a clear understanding of what .Net acutally is. I understand that C++ and
Vb
and other languages are being out a .Net. I get some idea that it still
is
OOP. I think it has different ways of managing the code. But what is it?

Thanks
--
SailFL


Here are some articles that will help:

http://msdn.microsoft.com/library/de...tframework.asp

http://msdn.microsoft.com/library/de...asslibrary.asp

http://msdn.microsoft.com/library/de...tframework.asp

http://msdn.microsoft.com/library/de...ials_start.asp

--
Peter [MVP Visual Developer]
Jack of all trades, master of none.

Aug 28 '05 #3
> I have read threads here and there and I have looked at MS but I can not
get
a clear understanding of what .Net acutally is. I understand that C++ and Vb and other languages are being out a .Net. I get some idea that it still is OOP. I think it has different ways of managing the code. But what is it?

The closest thing that comes to .NET is Java. Although it is equivalent is
is not the same, there are some differences.

Basically it comes to this. C#, VB.NET and C++ (in managed mode) will create
an virtual assembler code called IL as executable (you won't notis this
since the executable is still called exe and an assembly called dll). The
moment that you double click on that .NET program then the .NET compiler
(CLR) compiles it to native processor instuctions to be executed. Only the
functions that are actually executed are compiled, not the unsed functions.
This is why starting up a .NET program seems to be so slow compared to
none-NET programs.

VC++.NET is a special breed, it can create pute .NET programs (aka managed
code), it can cerate pure old style executables not needing the .NET
framerwork (aka unmanaged code) or mix it. It is not a dirty trick, because
the CLR has this managed/unmanaged functionality implemented in it's core so
in theory even C# might create mixed code if the developers would like
that.But they don't want to implement this as far as I know.

Now what about the .NET framework. This is a set of libraries similar like
the Microsoft Foundation classes or the Visual Basic runtime library. It is
a rich set classes that does most things you ever need.
But you still have access to the conventional WINAPI functions in case if
you need exotic functionality or have access to your existing old dll's.
This is what they call INTEROP, access from managed code to a unmanaged
part. This trasition takes time so must be avoided if it is possible.

One interesting feature of the .NET is that it can also create COM objects
(ActiveX) so you can create a .NET libarary that can just be used in older
program languages that have no clue what .NET is.

Regarding to your OOP, .NET is basically a WINAPI wrapper in a pure object
oriented way (you can inherit, extend,... anything according to OOP
conventions). Unlike MFC that is a WINAPI wrapper in aan none-object
oriented way. (It looks like OOP but it is absolutely no OOP). You are
forced to program the OOP way, which is a good thing.

The nice thing about this OOP way of programming is that now, a dll created
by C# can be used in VB.NET without dirty tricks and that VB.NET can be used
in C# and C++, freely intermixed. With one exception that the dll writer
must not use case sensitivity otherwise VB.NET will have problems with it.
If you create big programs that you will see that a program will contain
mixed C++/C#/VB code all working happily together.

Another thing about .NET is security. This might be a problem for people
coming from none-NET since the learning curve is a litle bit high in order
to understand this. But basically it comes to this. 2 people must tell what
the progra is allowd to do. The programmer and the user/administrator where
the program will run. E.g. The programmer must decide if this program is
allowed to access the Internet or a networkdrive. Because default it does
only run on your local machine. And a stupid clock might not need to access
the internet. So it cannot be taken over by a worm/virus to send SPAM. But
imaging that thic clock does need internet for the about box to go to the
vendors URL, then user/admin of the machine where this program will run can
then restrict the access to none-Internet only. From IT point of view I
would trust .NET programs far more than none-.NET programs.

Another interesting feature if the .NET is regarding to memory cleanup. This
is also know as GC. Unlike conventional programming, you do not need to free
memory after you used the memory and have no need for it anymore. The GC
will fire up the moment you are tending to run out of memory and analyze
which memory blocks might be discarded. The GC is pretty advanced but so far
it works great. Only regarding to file closing and other windows resources,
could there be a problem. So you must not writer the file close in a
destructor otherwise you have no idea when the GC will close the file. It
becomes unpredictable.

It took a few years to understand this, I hope now you have a much clearer
view? ;-)
Aug 29 '05 #4
Olaf,

The closest thing that comes to .NET is Java. Although it is equivalent is
is not the same, there are some differences.


No certainly not, .Net is a kind of operatingsystem layer from which is one
part the CLR. Java is a program language that uses a runtime.

Cor
Aug 29 '05 #5
> > The closest thing that comes to .NET is Java. Although it is equivalent
is
is not the same, there are some differences.
No certainly not, .Net is a kind of operatingsystem layer from which is

one part the CLR. Java is a program language that uses a runtime.

Cor

I knew it is a sensitive topic, but I wanted to make it simpler to
understand for novice people.
That is why I uses the word equivalent. ;-) But that is of course from one
point of view.

Anyway, this .NET is a vey good thing :-)
Aug 29 '05 #6
Thank you for taking the time to give me your explination. I appreciate it
very mcuh
Regards
--
SailFL
"Olaf Baeyens" wrote:
I have read threads here and there and I have looked at MS but I can not

get
a clear understanding of what .Net acutally is. I understand that C++ and

Vb
and other languages are being out a .Net. I get some idea that it still

is
OOP. I think it has different ways of managing the code. But what is it?

The closest thing that comes to .NET is Java. Although it is equivalent is
is not the same, there are some differences.

Basically it comes to this. C#, VB.NET and C++ (in managed mode) will create
an virtual assembler code called IL as executable (you won't notis this
since the executable is still called exe and an assembly called dll). The
moment that you double click on that .NET program then the .NET compiler
(CLR) compiles it to native processor instuctions to be executed. Only the
functions that are actually executed are compiled, not the unsed functions.
This is why starting up a .NET program seems to be so slow compared to
none-NET programs.

VC++.NET is a special breed, it can create pute .NET programs (aka managed
code), it can cerate pure old style executables not needing the .NET
framerwork (aka unmanaged code) or mix it. It is not a dirty trick, because
the CLR has this managed/unmanaged functionality implemented in it's core so
in theory even C# might create mixed code if the developers would like
that.But they don't want to implement this as far as I know.

Now what about the .NET framework. This is a set of libraries similar like
the Microsoft Foundation classes or the Visual Basic runtime library. It is
a rich set classes that does most things you ever need.
But you still have access to the conventional WINAPI functions in case if
you need exotic functionality or have access to your existing old dll's.
This is what they call INTEROP, access from managed code to a unmanaged
part. This trasition takes time so must be avoided if it is possible.

One interesting feature of the .NET is that it can also create COM objects
(ActiveX) so you can create a .NET libarary that can just be used in older
program languages that have no clue what .NET is.

Regarding to your OOP, .NET is basically a WINAPI wrapper in a pure object
oriented way (you can inherit, extend,... anything according to OOP
conventions). Unlike MFC that is a WINAPI wrapper in aan none-object
oriented way. (It looks like OOP but it is absolutely no OOP). You are
forced to program the OOP way, which is a good thing.

The nice thing about this OOP way of programming is that now, a dll created
by C# can be used in VB.NET without dirty tricks and that VB.NET can be used
in C# and C++, freely intermixed. With one exception that the dll writer
must not use case sensitivity otherwise VB.NET will have problems with it.
If you create big programs that you will see that a program will contain
mixed C++/C#/VB code all working happily together.

Another thing about .NET is security. This might be a problem for people
coming from none-NET since the learning curve is a litle bit high in order
to understand this. But basically it comes to this. 2 people must tell what
the progra is allowd to do. The programmer and the user/administrator where
the program will run. E.g. The programmer must decide if this program is
allowed to access the Internet or a networkdrive. Because default it does
only run on your local machine. And a stupid clock might not need to access
the internet. So it cannot be taken over by a worm/virus to send SPAM. But
imaging that thic clock does need internet for the about box to go to the
vendors URL, then user/admin of the machine where this program will run can
then restrict the access to none-Internet only. From IT point of view I
would trust .NET programs far more than none-.NET programs.

Another interesting feature if the .NET is regarding to memory cleanup. This
is also know as GC. Unlike conventional programming, you do not need to free
memory after you used the memory and have no need for it anymore. The GC
will fire up the moment you are tending to run out of memory and analyze
which memory blocks might be discarded. The GC is pretty advanced but so far
it works great. Only regarding to file closing and other windows resources,
could there be a problem. So you must not writer the file close in a
destructor otherwise you have no idea when the GC will close the file. It
becomes unpredictable.

It took a few years to understand this, I hope now you have a much clearer
view? ;-)

Aug 30 '05 #7
Olaf Baeyens wrote:
Now what about the .NET framework. This is a set of libraries similar like
the Microsoft Foundation classes or the Visual Basic runtime library. It is
a rich set classes that does most things you ever need.
But you still have access to the conventional WINAPI functions in case if
you need exotic functionality or have access to your existing old dll's.
This is what they call INTEROP, access from managed code to a unmanaged
part. This trasition takes time so must be avoided if it is possible.


INTEROP not only exists between managed part and unmanaged part, but
also can be seen between Microsoft world (.NET/COM on Windows) and
non-Microsoft world (Java/CORBA on UNIX, Linux, AIX, Solaris and etc).
Three major interoperability issues, Java<->COM, Java<->.NET and
CORBA<->.NET, can be easily solved with J-Integra Interoperability
Suite. For a free evaluation, visit our website at
http://j-integra.intrinsyc.com/

Regards,

Raymond HE
Intrinsyc Software International, Inc.
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
When Web Services are not enough

Aug 31 '05 #8
> Thank you for taking the time to give me your explination. I appreciate
it
very mcuh

The hardest part was understanding this security thing.
You have a policy and you have permissions.

Permissions are intended for the programmer to tell what this program is
allowed to do: E.g. allow network access.
Policies are intended for the computer user/administrator to decide what the
program running on his machine is allowed to do: E.g. access to nework.

The system is built in such a way that you have minimum, required and
optional permissions.
In a lot of cases these are definded the assembly.cs file. But if for
example only one function needs Internet acces and the rest of the librarie
doesn't then you can dynamically change the permission on the fly to give
this part access to Internet.

Important to know is that both the permission and policy must be satified or
the program won't run. A typical example is that of a pure .NET program
created in C#, that crashes when you double click on it when it is executed
from a shared network drive and it doesn't crash if you copy it local to the
C: drive and start if from there: reason : not enough security rights.

In my opninion, Microsoft could have created a more user-friendly default
error message, because the error you get now scares the hell out of even the
most hardened programmers. A simple dualog box telling that this program
does not have enough security rights to run and please contact your
administrator would be preferable. On that dialog box might also be a
details button to give details what is loaded and what is not. This should
be standard in the .NET framework because beginning programmers will
guarantee get into trouble like this.

Now what about trusting a program coming from one vendor and not all other
vendors?
Well you can sign your program and libraries (dll's) with a key you
generated on the fly. The .NET configuration can be configured to trust all
programs with this key, to the maximum. So you can reuse that key for all
your programs, it is free to generate that key. But of course you must never
ship that key to anyone or else they can imporsenate your software for
malware.

Now comes the final part, how the hell can you configure the .NET framework
to trust that key without having the user to go through the administrator
hell of setting the .NET policies. Suprisingly simple, you create a dll that
configures the key to be trusted, but the pitfall is that ONLY the setup can
execute that part of the code since the setup is not a .NET program and have
unrstricted access to the NET configuration tools. The reasoning is simple
that if you start an installer, then the .NET assumes that you know what you
are doing and that this software can be trusted, or else you won't install
it.

Although I am basically a low level programmer (C++/assembler) I do see a
big future for .NET applications if only Microsoft forces it to be installed
on all PC's. My company still creates none-.NET programs because
administrators simply refuse to install the .NET framework because of some
emotional based assumption that is completely incorrect. I need the extended
functionality of the .NET to create code faster, but I am forced to use the
MFC stuff and create everything myself because of the scare of the .NET
framework slowing me down dramatically. :-(

I hope this helps? :-)
Aug 31 '05 #9
Hi Olaf,

My company still creates none-.NET programs because
administrators simply refuse to install the .NET framework because of some
emotional based assumption that is completely incorrect.


Is the company already running on Dos 6.0 or still Dos 3.2

:-)

Cor
Aug 31 '05 #10
> > My company still creates none-.NET programs because
administrators simply refuse to install the .NET framework because of some emotional based assumption that is completely incorrect.


Is the company already running on Dos 6.0 or still Dos 3.2

:-)

Oops correction I was refering to our client's administrators.
Luckily here we have a good administrator that understands the value of .NET
programs and the increased security that it gives. ;-)
Ik just happens to be that I am the IT/Administrator, next to the
programming. ;-)

For the last 2 years I have been trying to promote .NET because I can
develop code far much faster (C# compiling is lightning fast) but our
clients are big companies and our sales tells me that the administrators of
these big companies don't like the .NET installed. So this is why we still
have to create code that does not use .NET technology. :-(

Right now I have 2 programs, one using OpenGL (using Tao) that are mostly
managed code, and they work nicely but I get many requests to rewrite them
without the .NET code. :-( Last time they asked me, I ended up programming
the none-NET version 3 whole months with reduced functionality while the
..NET version I started with was near completion after 2 weeks.
Since I discovered that creating the program in .NET (C#) first and then
port it to C++ makes me develop faster, then if I would do it directly in
C++ only because of the slow compiling, I first want to complete the .NET
version and then start the porting. And who knows, maybe they finally see
the light and starts to accept it withou me having to lose time in porting.

Anyway, doing it this way makes my code be ready for the future. :-)

For OpenGL like code, this .NET is fantastisc! But I don't create high
performant graphics, I only need visualization tools and a high frame rate
is not that important, but so far OpenGL in .NET seems to work great since
most rendering is done by the video driver.
Aug 31 '05 #11
Olaf,

Thanks again for the length information. It is clear you have been
programming in .Net for some time.

--
SailFL
"Olaf Baeyens" wrote:
My company still creates none-.NET programs because
administrators simply refuse to install the .NET framework because of some emotional based assumption that is completely incorrect.


Is the company already running on Dos 6.0 or still Dos 3.2

:-)

Oops correction I was refering to our client's administrators.
Luckily here we have a good administrator that understands the value of .NET
programs and the increased security that it gives. ;-)
Ik just happens to be that I am the IT/Administrator, next to the
programming. ;-)

For the last 2 years I have been trying to promote .NET because I can
develop code far much faster (C# compiling is lightning fast) but our
clients are big companies and our sales tells me that the administrators of
these big companies don't like the .NET installed. So this is why we still
have to create code that does not use .NET technology. :-(

Right now I have 2 programs, one using OpenGL (using Tao) that are mostly
managed code, and they work nicely but I get many requests to rewrite them
without the .NET code. :-( Last time they asked me, I ended up programming
the none-NET version 3 whole months with reduced functionality while the
..NET version I started with was near completion after 2 weeks.
Since I discovered that creating the program in .NET (C#) first and then
port it to C++ makes me develop faster, then if I would do it directly in
C++ only because of the slow compiling, I first want to complete the .NET
version and then start the porting. And who knows, maybe they finally see
the light and starts to accept it withou me having to lose time in porting.

Anyway, doing it this way makes my code be ready for the future. :-)

For OpenGL like code, this .NET is fantastisc! But I don't create high
performant graphics, I only need visualization tools and a high frame rate
is not that important, but so far OpenGL in .NET seems to work great since
most rendering is done by the video driver.

Sep 1 '05 #12
Raymond,

Go sell your product some place else. These forums are for help and support
not selling. I have told MS that I don't think you should be allowed to post
because you are selling a product and not providing useful comments to
problems.
--
SailFL
"j-***************@intrinsyc.com" wrote:
Olaf Baeyens wrote:
Now what about the .NET framework. This is a set of libraries similar like
the Microsoft Foundation classes or the Visual Basic runtime library. It is
a rich set classes that does most things you ever need.
But you still have access to the conventional WINAPI functions in case if
you need exotic functionality or have access to your existing old dll's.
This is what they call INTEROP, access from managed code to a unmanaged
part. This trasition takes time so must be avoided if it is possible.


INTEROP not only exists between managed part and unmanaged part, but
also can be seen between Microsoft world (.NET/COM on Windows) and
non-Microsoft world (Java/CORBA on UNIX, Linux, AIX, Solaris and etc).
Three major interoperability issues, Java<->COM, Java<->.NET and
CORBA<->.NET, can be easily solved with J-Integra Interoperability
Suite. For a free evaluation, visit our website at
http://j-integra.intrinsyc.com/

Regards,

Raymond HE
Intrinsyc Software International, Inc.
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
When Web Services are not enough

Sep 1 '05 #13
> Thanks again for the length information. It is clear you have been
programming in .Net for some time.

I still have a lo to learn. :-)
It has big potential.

One thing I forgot was that unlike dll's you can actually protect you
classes so that only .NET dll's and managed executables with a certain type
of key can use it. Remember that free generated key that you are not
supposed to publish outside the company?
This is protection against 3rd party software (or misuse like a Trojan)

An example is here:

[StrongNameIdentityPermission(SecurityAction.Inheri tanceDemand,PublicKey="A2
A..B22")]
[StrongNameIdentityPermission(SecurityAction.LinkDe mand,PublicKey="A2A..B22"
)]
[StructLayout(LayoutKind.Auto)]
public class GLModel : IDisposable {
......
}

And another fantastisc thing is form inheritance.
You take a form (user control), put some components on that, and put the
interaction code.
Now make a new form (user control) , put these newly created controls on it
and add some more.

Finally you can have pretty customized controls and put it on your main
form.
One of such combined control is a title, slider and spinbutton, all working
together.
Another one is a image viewer with a slider to see the next image and an
checkbox that inverts the image.
Try this in MFC, it is a nightmare to even think about trying to do this.
;-)

The biggest problem with .NET will be the transition and relearnign how to
program in .NET.
But it is worth the effort in my opinion.


Sep 1 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

220 posts views Thread by Brandon J. Van Every | last post: by
699 posts views Thread by mike420 | last post: by
92 posts views Thread by Reed L. O'Brien | last post: by
137 posts views Thread by Philippe C. Martin | last post: by
12 posts views Thread by Dario | last post: by
47 posts views Thread by Neal | last post: by
121 posts views Thread by typingcat | last post: by
8 posts views Thread by Midnight Java Junkie | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.