VShost.exe in .NET:

If you are developing with Visual Studio 2005 you probably have seen the *.vshost.exe files inside of your bin folder or you saw the process running while debugging. The vshost.exe file is coming from Visual Studio and serves a very good purpose. The vshost.exe is a new Visual Studio 2005 feature and is actually a hosting process

Actually when you open the project in vs. express it copies this file vshost.exe from Program Files\Microsoft Visual Studio 8\Common7\IDE and renames it to yourassemblyhost.vshost.exe
The hosting process is a feature in Visual Studio 2005 that improves debugging performance, enables partial trust debugging, and enables design time expression evaluation. The hosting process files contain vshost in the file name and are placed in the output folder of your project. For more information, see Debugging and the Hosting Process.

Improved Debugging Performance
The hosting process creates an application domain and associates the debugger with the application. Performing these tasks can introduce a noticeable delay between the time debugging is started and the time the application begins running. The hosting process helps increase performance by creating the application domain and associating the debugger in the background, and saving the application domain and debugger state between runs of the application. For more information on application domains, see Application Domains.

Partial Trust Debugging
An application can be specified as a partial trust application in the Security page of the Project Designer. Debugging a partial trust application requires special initialization of the application domain. This initialization is handled by the hosting process.

Design-Time Expression Evaluation
Design-time expression evaluation enables you to test code from the Immediate window without having to run the application. The hosting process executes this code during design time expression evaluation. For more information, see Immediate Window.
NOTE: Hosting process files (.vshost.exe) are for use by Visual Studio 2005 and should not be run directly or deployed with your application.

The *.vshost.exe files are exclusively used by the VS 2005 IDE, they serve no other purpose.
If you want to disable the generation of the vshost files you can do so under your projects settings.

In general, when the hosting process is disabled the time needed to begin debugging increases.

Note:Hosting process files (.vshost.exe) are for use by Visual Studio 2005 and should not be run directly or deployed with your application..

Window Based Application Creation

If you create a sample application in windows (E.g.: Practice) it will create following default files:
{} – Type
() – My Project Name as Practice
1) Project Name folder (Practice)
a) Bin folder
i) Debug Folder
(1) Project Name (Practice).vshost.exe

Hosting Process (vshost.exe)
The hosting process is a feature in Visual Studio 2005 that improves debugging performance, enables partial trust debugging, and enables design time expression evaluation. The hosting process files contain vshost in the file name and are placed in the output folder of your project. For more information, see Debugging and the Hosting Process.

b) My Project folder
i) Application.Designer.vb {VB Source File} – it will contain some code about application .This code was generated by a tool.
i i) Application.myapp{MYAPP File}
iii) AssemblyInfo.vb{VB Source File} –Assembly attributes Information
iv) Resources.Designer.vb - resource code generated by tool
v) Resources.resx{.NET Managed Source File}
vi) Settings.Designer.vb{VB Source File}
vii) Settings.settings{Visual Studio settings-Designer File}
c) Obj folder
i) Debug folder
(1) TempPE folder
d) Form1.Designer.vb {VB Source File} – Design code (location, controls info….)
e) Form1.resx{.Net Managed Source File}
f ) Form1.vb{VB Source File}
g) Project Name (Practice).vbproj{VB Project File} – contains project files info
2) Project Name (Practice).sln {Microsoft Visual Studio Solution}
3) Project Name (Practice).suo{Visual Studio Solution User Options}

After Build your Applcation it will create following new files:
Bin folder: Project Name(Practise)[.exe,.pdb,.xml
A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program. A PDB file is created when Visual Basic/C#/JScript .NET program with /debug mode.
Debugfolder:Practise.exe,Practise.pdb,Practise.xml,ResolveAssemblyReference.cache,Practise.Account.resources,Practise.Resources.resources,Practise.vbproj.GenerateResource.Cache,Practise.exe,Practise.xml,Practise.pdb
Default Added References:
1) System
2) System. Data
3) System. Deployment
4) System. Drawing
5) System. Windows. Forms
6) System. XML

.NET Compliant Languages

One of the imperative features of the .NET is the facility to program in multiple languages, which allows programmers to use their favorite languages. Right now, the Microsoft programming languages including Visual Basic .NET, Visual C#, Visual J# and Visual C++ with managed extensions are part of Visual Studio .NET 2003 and developers can make use of these languages for developing different applications.

The other few .NET compliant languages from other vendors are:

ASML for .NET [AsmL: Abstract State Machine Language]: AsmL is an executable specification language based on the theory of Abstract State Machines. The current version, AsmL 2 (AsmL for Microsoft .NET), is embedded into Microsoft Word and Microsoft Visual Studio.NET. It uses XML and Word for literate specifications. It is fully interoperable with other .NET languages. AsmL generates .NET assemblies which can either be executed from the command line, linked with other .NET assemblies, or packaged as COM components.

Mercury on .NET: The current release of the Mercury compiler includes preliminary support for generating code for .NET. It also includes a partial port of the Mercury library and runtime to .NET. This is still work in progress.

SmallScript and Smalltalk for .NET: The S# language implementation (pronounced s-sharp) is a complete modular redesign of the Smalltalk language, offering transparent cross-language integration and component based deployment.

Perl for .NET: Download a trial version of NetCOBOL for .NET V1.1 Now

Eiffel ENViSioN! 1.2 offers users an enhanced experience within VS .NET. It now supports both Visual Studio.NET 2002 & 2003, so developers can choose the version of Visual Studio most suited for their needs.

Fortran for .NET, download our Technology Preview. Lahey Computer Systems and Fujitsu are currently developing a new product called Fortran for .NET with a compiler that generates MSIL and has new language extensions for object-oriented features and interoperability with other .NET languages.

AVR for .NET: AVR for .NET is ASNA’s next-generation of Visual RPG. AVR for .NET “snaps” into Microsoft’s Visual Studio.NET 2003 and provides an RPG compiler that works with Visual Studio’s built-in debugger. AVR for .NET’s RPG compiles to native, managed code, Microsoft Intermediate Language (MSIL) assemblies.

ActiveState PerlASPX enables professional Perl programmers to use Perl for dynamic content generation on ASP.NET Web servers. For more information or to download PerlASPX, click here. Perl for .NET Research is the result of a research project, creating a native code compiler for Perl to the Microsoft .NET Framework. The status of this compiler is experimental; it also supports just a subset of the language. The latest version of Perl for .NET Research is PerlForDotNet-5.6.0.613.msi.

Python: Perl for .Net and Python for .Net will provide programmers with easy interoperability between languages, cross-language inheritance and they will enable programmers to simply create, extend and consume .NET components.

Oberon for .net: Oberon is a member of the Pascal language family. From its ancestors Pascal and Modula-2 it inherits a compact, highly expressive and self-explanatory syntax, strictly enforced data types, and a concept of module in combination with public view.

NetCOBOL for .NET: Fujitsu NetCOBOL for .NET smoothly integrates with other languages such as Visual Basic, C#, and Eiffel. Fujitsu Software is the only COBOL vendor to announce support for Microsoft .NET and ASP.NET, including Web Services.

Delphi: Vendor: Borland

Mondrian for .NET: Mondrian is a functional language specifically designed for interoperating in OO environments.

F# is an implementation of the core of the Caml programming language for the .NET Framework, along with cross-language extensions. The aim is to have it work together seamlessly with C#, Visual Basic, SML.NET and other .NET programming languages.

Dyalog APL for .NET

Check the following links for more detials:
Visual Basic, C# , JScript , C++ , J# , APL , Cobol , Component Pascal , Delta Forth .NET compiler, Eiffel , Fortran , Haskell , Mercury , Oberon , PERL , Python , Salford FTN95 , Scheme SmallScript , Standard ML , TMT Pascal & F#

VB.NET and C# Comparison

Nice link to know differences between VB.NET and C#:
http://www.harding.edu/fmccown/vbnet_csharp_comparison.html

Differences Between Visual Basic .NET and Visual C# .NET" white paper is available:http://support.microsoft.com/kb/308470