For Visual Basic programmers, the new version of Visual Studio includes some nice features such as implicit line continuation (no more underscore characters to continue lines), auto-implemented class properties, collection initializers and lambda expressions (essentially functions within functions). On the C# side of things, they’ve added support for late binding to dynamic types, and improved interoperability with COM objects. This is a real benefit to C# developers who need to make extensive use of the Office automation APIs, since these changes make it significantly easier to work with. For the most part, the language changes make it easier to do more with less code, and brings VB and C# into parity with one another in terms of language features and overall functionality. Microsoft decided to merge the VB and C# language teams together, ensuring that both languages are “first class citizens” in the .NET universe.

For those who are interested in working with Visual Studio 2010, here’s some useful links:

• Visual Studio 2010 Express Editions
• Visual Studio 2010 Professional
• .NET Framework 4 Installer
• Visual Studio 2010 Help Keyword Index
• Help Viewer Power Tool

Visual Studio 2010 Professional can be installed as a 30-day trial and you can get an additional 60-day extension, if necessary. The Express Editions are free, of course, but are more limited. New projects build with VS2010 will target the .NET 4 Framework, so your end-users would need to have that installed. You could either have them install it using the web installer I linked above, or you could have your own installation program pre-install the framework.

The link to the keyword index addon is something that addresses the one significant negative in VS2010, which is the new help system that they’re using. It lacks an index, and the searching functionality leaves a lot to be desired (for example, there’s no ability to filter search results). This addon adds a panel that provides an index that integrates directly into the IDE, and is really something that should have been included with the product. One caveat is that this addon won’t work with the Express editions because they don’t support tool extensions. The Help Viewer power tool allows you to configure the VIsual Studio 2010 help to use a standalone viewer, rather than your browser. Keep in mind that if you want to make full use of the Help Viewer power tool, make sure that you install all of the Visual Studio documentation locally.

For example, in Visual Basic the code could look like this:

  SecureShell.HostName = "remote.server.net"
  SecureShell.UserName = "username"
  SecureShell.Password = "password"

  Dim strResult = SecureShell.Execute("/bin/ps -ef")
  If strResult.Length = 0 And SecureShell.LastError > 0 Then
      MessageBox.Show(SecureShell.LastErrorString)
      Exit Sub
  End If

  TextBox1.Text = strResult

In this example, the typical property values are set for the SSH server domain name or IP address, the user name and password required to authenticate the session. The Execute method is then called, providing the command to execute as a parameter, and the output from the command will be returned to a string value. In this case, we’re connecting to a UNIX based system and listing all of the running processes using the /bin/ps command.

If an error occurs, then the return value will be an empty string and the LastError property will be set to a value which identifies the error condition. In this case, we simply display a message box that shows a human-readable description of the last error code and then exit the subroutine.

As with an interactive terminal session, the entire operation is encrypted over the network, including the command that is sent and the output that it returns. For this reason, using SSH is preferred over the old rexec protocol which would send both the user credentials and the command as plain text. If you’re currently using the Remote Command class in your applications, it’s recommended that you consider rewriting your code to use the SSH component as a secure alternative.

Although the class makes developing server applications significantly easier, there are a few important things to keep in mind when using this class:

Although the code that you’ll write will look like typical single-threaded code that responds to events, it’s actually a multi-threaded application, with each client session isolated in its own thread. When network events are raised, they are being raised within the context of the thread that’s generated them. For example, this means that when the OnRead event fires, it’s not firing within the thread that created that instance of the InternetServer class (e.g.: the main UI thread). Any code that you have inside that event handler is executing in the context of the thread that’s managing that specific client session.

Because network events are being raised in the context of the client session threads, this means you cannot update user interface controls directly from within the event handlers. .NET does not allow one thread to modify a control that was created in another thread (usually the main UI thread). This is an absolute rule, and if you break it, your program is either going to hang or throw an exception. If you want to change any property values or call methods in a control, you need to create a delegate and marshal the call to the UI thread to using the Invoke method. Both the VB.NET and C# examples show how to do this; in the example, it’s used to update a ListBox control. Frequently updating the user interface from within an event handler can have a very negative impact on the overall performance of your program. Marshalling calls across threads to those UI controls is an expensive operation, and while you’re doing it, you’re not servicing network events like OnRead. You should keep it to a minimum, only updating the UI when absolutely necessary.

Another important consideration is that you should never modify shared objects without first synchronizing access to that object. In VB.NET it’s typically done using the SyncLock statement; in C# it’s done using the lock statement. The VB.NET and C# examples show to do this using a shared instance of a Hashtable class which is used to keep track of the number of bytes echoed by the server. While our lower-level API provides thread-safe queuing functions (InetServerEnqueue, InetServerDequeue, etc.) this doesn’t exist in the .NET class, largely because it would be redundant. If you want to use a queue, then you use the .NET Queue class, but the same rule applies; make sure that you synchronize access to the queue. While the InternetServer class does have Lock and Unlock methods, you should never use it for general purpose synchronization in your program. Calling the Lock method will cause every single client thread to block, and so while using Lock and Unlock would seem to be the easiest approach, it’s not a good idea for performance reasons.

The InternetServer class provides two general forms of many methods which are used to exchange data with the clients, ones which requires a handle to the client socket, and ones that do not. It’s not required that you specify a client handle if your code is inside an event handler (or in a function that’s being called by an event handler); the class knows which client raised the event and calls to Read and Write will work with that client (referred to as the “current client” in the documentation). However, if you want to exchange data with a client outside of an event handler, or with a client other than the current client, then you must specify a handle. Also, certain properties only return meaningful results from within an event handler. For example, the ClientAddress property (which returns the IP address of the client) should only be referenced from within an event handler such as OnConnect. The documentation notes when a property or method should only be used inside an event handler.

Finally, while it is possible to exchange data in an event handler with a client other than the one that generated the event, it’s not recommended. This is a case where you should use the Lock method to ensure that you’re the only thread that is attempting to read or write on that socket at the time. Two threads that attempt to read or write data on the same socket has undefined results; there’s no guarantee which thread would “get there first”, and the end result can be really unpredictable behavior by your program. One way to think about this is to think of your server program as a house, with each client connection being a room inside that house. You can do pretty much anything you want inside your own room (from within the event handler code that you write). However, if you want to go into another room and start rearranging the furniture, you need to make sure that every other thread is locked out while you do that. When you’re done and back in your own room, then you unlock the server and continue on.

Catalyst File Transfer .NET
The File Transfer .NET component is a managed code class designed to simplify the process of uploading and downloading files from within your application. The class supports both the File Transfer Protocol (FTP) and Hypertext Transfer Protocol (HTTP), providing a seamless interface that is both easy to understand and implement in your own software. In addition to basic file transfer functionality, the class also supports remote file management features, such as the ability to list available files, rename files and move folders.

The File Transfer .NET class also supports secure connections using the standard SSL and TLS protocols, providing strong encryption and support for the latest security features. If you are already familiar with the ActiveX version of this component, you’ll find that it has an exceptionally low learning curve, with an interface that is similar enough to make the transition to the .NET platform as simple as possible.

Catalyst Internet Mail .NET
The Internet Mail .NET component is a managed code class that provides a comprehensive interface for sending, downloading and managing e-mail messages on a mail server. This single component supports both the Post Office Protocol (POP3) and Internet Message Access Protocol (IMAP4) for accessing e-mail messages on a server, managing them remotely and downloading them to the local system. It also supports the Simple Mail Transfer Protocol (SMTP) for submitting e-mail messages for delivery, either directly to the recipient, or routed through a relay server.

In addition to the Internet protocols supported, the class also provides an interface that makes it easy to compose, parse and modify e-mail messages. Attaching files to messages or creating styled messages with HTML formatting is simple to do, typically requiring only a line or two of code. The Internet Mail .NET class also supports secure connections to the mail server using the standard SSL and TLS protocols, ensuring that the mail that you send or receive is encrypted. If you have used the Internet Mail ActiveX control, then you’ll find the .NET class to be extremely easy to use, with an interface that is similar enough to minimize the transition to the .NET platform.