Don't get me wrong, ASP.NET applications rock. But there are still many applications that don't fit well in an HTML and HTTP world because of complex state management and user interface requirements. Additionally, many enterprises don't have the skilled developers to quickly complete a web project.

But what if you could create a WindowsForms project, make it easily deployable, and not have to worry about configuring .NET security on the client to get your users to run?

Well, if you can guarantee that your users will have the .NET Framework version 1.1 or better, then you can accomplish your goals of easy deployment using WindowsForms, Internet Explorer, and Web Services. Note that by default there are severe security restrictions on WindowsForms applications executed within Internet Explorer using this method. But it is acceptable for an embedded WindowsForms application to call web services on the same server that the assembly was downloaded from. So as long as you can wrap your business classes in a web service, you can proceed....

Here's a quick step-by-step to get a WindowsForms app deployed through your web server, and embedded into IE:

1. Create your WindowsForms Interface
You will need to create a User Control to contain your WindowsForms User Interface.

2. Create your Web Site
Create a new ASP.NET Web Application and add an ASPX page to host your User Control created in Step 1.  Also add a new Web Service (.asmx) file and implement any server side (business logic) classes. Copy the assembly containing your User Control (from Step 1) to your web directory. Don't put it in the bin directory as this will likely cause security problems when the client attempts to download.

Now you can add a tag in your ASPX page to embed the user control. It follows a syntax like so:

Note that the “http:” prefix will cause the assembly to be download from the same web directory that the ASPX page exists in.

3. Backtrack and call the web service
Now that you created a web service in Step 2, you can go back to your WindowsForms User Control and add a reference to it. Since the release of the .NET Framework 1.1, any user can call a web service from a downloaded WindowsForms assembly. But note that this did not work in version 1.0 of the framework.

Everyone who is cool uses Classes instead of Structures, right? But I came across this FAQ that explains really well why: http://www.geocities.com/csharpfaq/structs.html

While looking for links on skinning in WindowsForms, I found some interesting links-

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet01142003.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchShapedWindowsFormsControlsInVisualStudioNET.asp

OK, so I installed VS.NET 2003 on a machine without IIS some time ago. Later on, I went back and installed IIS to do some web development. So how to get the ASP.NET web components into IIS without re-installing all of VS.NET?

From the framework directory, usually C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322, run...

aspnet_regiis -i

... and all of the framework web components will be installed. This is also useful if for some reason your components become hosed up (one of my past co-workers would have this problem every couple of weeks, and he had to re-run regiis... weird)

If your .NET app is lagging, it may be because of excessive or inefficient network traffic to your database server (or in the case of web services, your web application server). Sometimes this is because of your database provider, or your chosen Formatter for your web service. The best way to target the problem is to gather detailed metrics through a network trace. Here are some pointers for gathering this data:

(1) You'll need a network monitor. Windows 2000/2003 Server has Network Monitor available under Programs/Administrative Tools, but if you're running XP you'll need to get a copy of Network Monitor yourself. Network Monitor is available in SMS, so if you can get a copy of SMS you'll find it under the SMSSETUP\NETMON\I386 directory. Just copy the contents of that directory to your test workstation.

(2) Start Netmon. The first thing you'll need to do is create a filter, so that your capture only shows you the data you need (between your client and data server). Select Capture/Filter. Click the Addresses button and then the "Edit Addresses button on the next popup. From here you want to enter addresses for the Client, and any Server(s) involved in the capture. When you're done, click Close and in the "Address Expression" dialog, select Station 1 and Station 2, where Station 1 is your client workstation and Station 2 is your server. Click OK to go back to the Capture Filter Screen, then click OK on the Capture Filter Screen.

(3) Now you're ready to capture data! Select Capture/Start to begin capturing. Then fire up your client application. You should see packets start accumulating in the bottom panel. When you are done running through your client application, select Capture/Stop.

(4) Now you can view your captured data. Select Capture/Display Captured Data.

(5) Notes on Reporting: It's a shame there aren't better export function in NetMon. But what you can do to get your data out is: Select File/Print; Be sure to check the "Print To File" Checkbox. Also make sure to select a Generic/TextOnly Printer (you can install the driver if you don't have it). Go to the Netmon tab of the Print Dialog and select the options you want. It is possible to strip the output right down so that it can be imported into Excel or another report.

Another useless yet interesting metric: How many languages are available to the .NET CLR? There is at least a partial list here - http://www.gotdotnet.com/team/lang/

update 12/12/2004 - Got a site that is a bit more maintained - http://dotnetlanguages.net/DNL/Resources.aspx

Ada	Ada
APL	Dyalog APL
AsmL	AsmL is the Abstract State Machine Language for .NET
CAML	Microsoft Research F#
Cobol	Fujitsu Cobol
Delphi	Borland Delphi
Forth	Delta Forth
Eiffel	Interactive Software Engineering Eiffel for .NET
Fortran	Lahey/Fujitsu Fortran for .NET
Fortran	Salford FTN95 for Microsoft .NET
Haskell	Hugs98 for .NET
Lisp	DotLisp - Lisp dialect for .NET
Lua	Lua.NET embedded scripting language
Mercury	Melbourne University Mercury Project
Mixal	Mixal for .NET
ML	Standard ML from Microsoft Research
Mondrian	Mondrian for .NET
Nemerle	hybrid functional/OO language for .NET
Oberon	ETH Active Oberon for .net
Pascal	Queensland University Component Pascal
Perl	ActiveState Perl Dev Kit with PerlNET
PHP	PHP_Sharp compiler for .NET
Prolog	Compiles Prolog to C#
Python	ActiveState Python for .NET Research
RPG	ASNA Visual RPG
Ruby	NetRuby interpreter
Ruby	Ruby/.NET Bridge
Scheme	Northwestern University Hotdog Scheme
Scheme	Tachy (Scheme-like) language
Scheme	Indiana University Scheme.NET
Smalltalk	SmallScript from SmallScript LLC
Smalltalk	#Smalltalk compiler

Sometimes it's handy to create an inherited textbox that only accepts certain keys. For example, a textbox for inputing a monetary value. To do so, create a new user control, then change it's inherits clause to System.Windows.Forms.TextBox. You can then implement the KeyPress event to filter out any ANSI keyvalues. You can also implement the KeyDown event to handle other control keys such as the arrow keys.

Note that setting Handled = True will prevent the textbox from processing the key.

   Private Sub ucTextBoxFilter_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles MyBase.KeyPress

            ' allow only numerics

            If Not IsNumeric(e.KeyChar) Then

                e.Handled = True

            End If

    End Sub