VSLive! Speaker Interview—Jeff Prosise

As the shipment of .NET gets closer and closer, the issues of porting existing code and implementing .NET into new applications is becoming more and more important. VSLive! San Francisco will have tons of sessions on all your .NET needs. As a sneak preview, check out how Jeff Prosise, session speaker at the all day workshop, Writing Great Web Apps in C#, answered some of the most pressing .NET questions.

Cutting through the marketing hype, what's so good about C# from a C++ programmer point of view?
Actually, C# as a language isn't inherently better than C++, other than the fact that it makes it a little harder to make mistakes. What's REALLY important about C# is that C# code is managed code, meaning it runs in the highly managed environment of the .NET Common Language Runtime and has access to the .NET Framework Class Library, which is easily one of the most comprehensive class libraries ever written. In short, C# code leverages the .NET Framework. That's what's important about C#.

Would you port your C++ code to C#? Or would you start a new project, leaving your old programs to run with pre-.NET code?
I doubt a lot of companies will rush to port old apps to .NET. They should only do so if migrating an existing app to .NET provides clear and compelling benefits. Whether porting makes sense depends somewhat on the application type, too. Would I rush to port an MFC app to .NET Windows Forms? In most cases, no. But porting an ASP app to ASP.NET might just provide the clear and compelling benefits I mentioned earlier.

For new projects, it would be a mistake to not consider .NET. For Web applications, there is no better platform than .NET-period. Same goes for Web services. Once again, however, it depends on the application type and what the application is designed to do. For example, if a company is writing a stand-alone application that does real-time data acquisition, or a distributed system that runs behind a firewall and requires close coupling of components, then I wouldn't recommend .NET.

What are the advantages and disadvantages of porting your current code to .NET?
One advantage is that certain types of applications, especially Web apps, perform better (compared to ASP apps). ASP.NET Web apps are also easier to write and maintain than ASP apps, and they have richer feature sets, too. And apps that use the .NET Framework have access to the rich facilities of the .NET Framework Class Library. Not to mention the fact that managed applications don't leak memory like a lot of unmanaged applications do.

Disadvantages? Porting isn't easy, and it requires learning a whole new API-that of the .NET Framework Class Library-as well as new programming models.

What are some rules of thumb for performance optimization with ASP.NET?

• Don't use server controls when static HTML will do.
• Use StringBuilder to build strings dynamically.
• When using Hashtable and other collection classes, try to initialize them with an item count to avoid unnecessary reallocs.
• Design your apps to be compatible with server farms.
• Do as much as possible on the client side; avoid unnecessary postbacks.
• Don't call old COM components if you can help it.
• Used stored procedures for common database operations.
• Use caching whenever possible (ASP.NET has some wonderful caching features).

I've heard there are some wide-open security gaps in VS.NET. What's the story on this?
I haven't heard of them. Visual Studio.NET is a programming tool, not a platform, so I'm not sure how it could have security holes per se.

I understand C# does garbage collection for you. What do you still need to learn about garbage collection?
You need to learn about non-deterministic destruction (NDD) and understand its implications. It's too complicated to treat in detail here, but to make a long story short, classes that encapsulate only managed resources (that is, memory) work well in a garbage-collected environment. Classes that wrap unmanaged resources such as file handles and database connections require special care. Since you don't know when the garbage collector will kick in, you don't know when the objects will be destroyed. And if you rely on the objects' "destructors" to release unmanaged resources for you, those resources can remain open for a very long time. When you use objects that wrap unmanaged resources, it's important to explicitly dispose of those resources when you're finished with them. If you write classes that wrap unmanaged resources, it gets far more complicated. Don't think garbage collection is a panacea. It's not.

What are the ten coding mistakes VC++ programmers are most likely to make with their first C# projects?
I'm not sure I can think of ten, but here's one that bites a lot of C++ folks. Say you implement a Hashtable class in C++. The following statement declares an instance of that class on the stack:

Hashtable table;

If you write a Hashtable class in C# (or use the .NET Framework Class Library's Hashtable class), the same statement compiles fine but DOESN'T create a Hashtable; it simply creates a reference to one. You should write it this way instead:

Hashtable table = new Hashtable ();

Otherwise you'll generate a null reference exception the first time you access the Hashtable.

Another common problem that C++ programmers encounter is that in C#, conditional expressions MUST evaluate to booleans. In C++, this is perfectly legitimate code:

int x = 0;
if (x) { … }

In C#, these statements won't compile. They have to be written this way instead:

int x = 0;

if (x != 0) { … }

Subtle difference, but enough to cause a headache now and then.

Another potential trouble spot for C++ programmers moving to C# is the difference between reference types and value types. Your code can behave weirdly if you're not cognizant of whether a given data type is a reference type or a value type.

Most of all, C++ programmers must remember that in C#, destruction is non-deterministic. Classes that wrap file handles and other unmanaged resources are mistakes looking for a place to happen if not used properly. See the previous question for more information.