Most developers tend to think in the context of the language they are currently writing. If you’re writing C#, you are accustomed to having the core .NET Framework class library at your disposal. If you’re writing VB.NET, you’re used to having many more classes above and beyond the core class library, and in J# (assuming anyone actually uses J#) you have yet another pool of classes to choose from. This language-specific focus can lead to an unfortunate bit of tunnel vision.
To make a stunningly obvious point (once you think about it for a minute): your C# application is free to use any class available in the VB.NET or J# class libraries (or any others). Your VB.NET application is free to use any class available in the J# class library, and so on. Whatever language you are using, you can, and should, take advantage of all of the class libraries available to you! Less work and less custom coding is always a great thing.
In the context of a C# application, this means adding a reference to Microsoft.VisualBasic.dll. (What? Is he nuts?!?) Sure, it might seem odd at first, but all high-level language code for .NET is reduced to one intermediate language in a managed code assembly — IL. It makes no difference if it originated in COBOL.NET, C#, VB.NET, J#, etc., and there is absolutely nothing wrong with having “using Microsoft.VisualBasic” in your C# code. The core .NET Framework already includes the extra VB class libraries, but to get the J# class libraries you need to have the J# Runtime installed.
There is a lot of great code just waiting to be used. For example: need to work with ZIP files (unlike System.Compression)? Check out the java.util.zip namespace in the J# runtime. Yeah, that’s .NET managed code, despite the “java” in the namespace. Remember that the J# runtime and J# itself was designed to be compatible with Java, so the runtime attempts to recreate as much of the (older) Java class libraries as possible. Another example: the Microsoft.VisualBasic.Financial class. How cool is this? Asset depreciation calculation, present value of an annuity and more. If you’re coding in C#, you may well have gone off and coded all of this yourself, or looked to open source for a solution — all while it was right under your nose.
I found an old article from MSDN magazine that demonstrates writing a ZIP utility in C# using the J# runtime, which is a great example for this topic.
Some of you will be saying “Duh!” by this time, but the reactions from years of saying this to developers has told me that it is not immediately obvious to everyone. Hopefully this will save you some time!
I happened to be building an ASP.NET 2.0 website earlier this year when the ASP.NET 2.0 AJAX Extensions RTM’d, so I decided to try it out. Someone recently asked me my impressions of the Extensions and Control Toolkit and how best to get started, so I thought I’d pass on my comments.
Thinking of existing ASP.NET developers picking up AJAX for the first time with this framework, it is an extremely well designed and natural development model. It integrates almost seamlessly into the existing development environment and “<asp:xyz>” tag model.
One thing that should be high on everyone’s to-do list as a web developer is mastering CSS. If you are not very strong with CSS, it is going to become tougher to use the new tools, including AJAX and WPF/E. For many of the fancy controls noted above, you need to create a number of CSS styles just to get them to work. I recommend one site for CSS that may open your eyes to the possibilities. Check out all the layouts you can do with no nested tables involved, and cross-browser too.
I believe that the AJAX toolkit documentation is lacking, in some areas significantly. You will probably find yourself with questions that are not answered at all, or poorly. However, that has not proven to be a major issue. For the most part things work as expected, but there are certainly subtleties to learn.
I have had some issues with the collapsible controls not sizing correctly in a stacked configuration, but that is in an absolute positioning-based CSS website that may have another CSS issue that I’m missing. On the same site, we have an issue with the stacking and with calendar controls not appearing in IE6 only, but again, that could be related to the other CSS.
A not-to-miss blog for a wide range of ASP.NET topics, not just AJAX, is Scott Guthrie’s. Here are some more ASP.NET AJAX labs. And training videos. The good news is that you can start using the Extensions for very small bits of functionality on your site and expand from there. For instance, I put an existing checkbox that simply turns a flag on and off in a database inside an UpdatePanel to avoid a complete postback. I’m sure you can think of areas like this on your websites where a simple operation could be easily optimized with AJAX Extensions for a much bigger benefit in user experience.
I’ve been forgetting to write about this one for the better part of a year… Many of you have probably seen the exception dialog box in the SQL Server 2005 GUI’s. It lets you copy the exception text to the clipboard and so on. It’s pretty nice, certainly an improvement over past dialogs that just printed the error and made you take a screenshot or copy down the error message.
Microsoft quietly released that very exception dialog as a standalone, supported managed assembly that you can use in your own applications. This is a great thing to take advantage of if you are working on any WinForms 2.0 apps. (I haven’t checked, but it is probably .NET 2.0 since it is part of SQL 2005.)
From the source:
Microsoft Exception Message Box
“The exception message box is a programmatic interface that you can use in your applications for any tasks for which MessageBox may be used. The exception message box is a supported managed assembly designed to elegantly handle managed code exceptions. It provides significantly more control over the messaging experience and gives your users the options to save error message content for later reference and to get help on messages.”
I’ve written before about installing .NET Framework 1.1 and 2.0 side by side (SxS) on the same box. Microsoft recently added to the mix .NET Framework 3.0, so it’s about time to clear up any confusion on the newest release.
Above all, you should understand that the version designation of 3.0 was strictly marketing-driven. At the most basic level, .NET Framework 3.0 equals .NET Framework 2.0 plus a bunch of new DLLs. If you install .NET Framework 3.0 on a box that does not already have .NET Framework 2.0, the installer installs Framework 2.0. Therefore, if you already have .NET Framework 2.0 installed on a box, you should not be too concerned that installing 3.0 will break existing applications. In fact, you will find that in the ASP.NET tab in IIS Admin, .NET 3.0 is not even a choice.
It is worth noting that .NET Framework 3.0 is pre-installed on Windows Vista and will be pre-installed on “Longhorn” Server. However, .NET 3.0 may be installed on any Windows XP SP2 or Windows Server 2003 SP1 box.
If you’re working with a mission-critical server then you should, of course, be cautious and do some planning and testing anyway. Just be aware that the 1.1 to 2.0 story is identical to the 1.1 to 3.0 story, because 3.0 is in effect 2.0 with more files.
By now you may be asking what .NET Framework 3.0 is good for if it is essentially Framework 2.0. .NET 3.0 delivers a number of long-anticipated and important features, though mostly of interest to application developers rather than server administrators. The list includes Windows Communication Foundation, Windows Workflow Foundation, Windows Presentation Foundation and Windows CardSpace. You can read more about them on the official .NET Framework 3.0 site.
- .NET 3.0 is not a major change to the core .NET Framework as was 1.0/1.1 to 2.0
- If you currently have only .NET Framework 1.0 or 1.1 and you are looking to install 2.0 or 3.0, see my side-by-side post
- If you currently have .NET Framework 2.0, installing .NET Framework 3.0 is not a major change as the version numbers would suggest
- If you currently run .NET 2.0 applications, they will not know or care that you have installed .NET 3.0
Please feel free to contact me with questions and your own experiences with the upgrade. Thanks for reading!
I frequently hear comments that Web services are inappropriate for carrying large data messages, say greater than 1 MB. In the past there was some truth to that, but no longer. There is really no reason to avoid a Web service simply because you have to send or receive a bunch of data.
By default, transferring non-ASCII data over a SOAP call means using Base64 encoding. You have to go back to the early days of the Internet to find the Base64 definition in IETF RFC 1521, which was adapted from an even earlier RFC. Base64 typically increases the size of the encoded data by 33%, not to mention the CPU and memory required to encode and decode. Imagine sending a 3 MB PDF over a SOAP call with Base64 encoding. That PDF gets translated into a 4 MB ASCII string, transmitted to the other endpoint, and then converted back to the original 3 MB PDF. Clearly this is not an efficient scheme.
Years ago, Microsoft first addressed this issue in the Web Services Enhancements (WSE) add-on to .NET with their proprietary DIME extension to SOAP. Like MIME, DIME is designed to define message attachments of varying data types, but in this case to a SOAP message. According to Microsoft, DIME was a more efficient format than MIME for message parsers. It was not widely adopted.
Why attachments? Just like sending an email, you might want to send a SOAP message that carries alongside it one or more other chunks of data, whether that’s a ZIP file, another XML file, a PDF, etc. An attachment scheme like MIME defines in the message header the list of attachments, and for each attachment an encoding method. We would prefer to use a binary encoding method that does not increase the size of our data.
The W3C standards organization got involved with the advent of the Message Transmission Optimization Mechanism (MTOM), which today is a W3C Recommendation. MTOM uses concepts from MIME/Multipart to add attachments to a SOAP message, and it can optimize elements of type base64Binary. If you put data into a base64Binary element with MTOM disabled, you will literally see a Base64-encoded version of your data (and much bigger than the original). If you look at the same element with MTOM enabled, you will find a pointer to a MIME part that contains your actual data in binary format.
MTOM is available today for .NET 2.0 Web services in Web Services Enhancements (WSE) 3.0 and Windows Communication Foundation. Both of these are freely available and fairly easy to use. WSE 3.0 is perfect for your existing ASMX Web services because there is usually no code to change to take advantage of MTOM. Keep in mind that clients of an MTOM Web service also need to be MTOM-aware. The only requirement is that the data element you wish to optimize is of type base64Binary in the XML, and a byte array in your .NET code. Once you enable WSE3 on your Web service project, you can simply enable MTOM in the WSE configuration. Remember to enable it on the client side too.
Attached to this post you will find a sample .NET 2.0 solution that demonstrates a single Web service implemented in plain ASMX, ASMX with WSE3 and WCF. You’ll notice that there is no special code at all for MTOM, just configuration. If you use an HTTP monitor like Fiddler to examine the SOAP messages, you will see the differences with and without MTOM.
It is worth pointing out that BizTalk 2006 Web services CAN take advantage of MTOM! When you publish a schema or orchestration as a Web service, what comes out is a regular old .NET 2.0 ASMX Web service. Again, as long as the large data elements are defined as type base64Binary and as a byte array in code, MTOM can be enabled with no code changes. Just update the BizTalk Web service project to enable WSE3 and MTOM.
Please contact me if you have questions, and please take advantage of these free and easy tools to make your Web services faster.
You might have used the VB6 to VB.NET Upgrade Wizard in Visual Studio, or maybe the Java Language Conversion Assistant (JLCA) to convert Java code to C#. These tools have something in common – the technology comes not from Microsoft, but from a company called ArtinSoft.
This is a company with some very intriguing products based on artificial intelligence engines. Their business is all about source code and platform conversion – VB6 to VB.NET, Java to C#, PL/SQL to T/SQL, Linc to J2EE – you name it, they can probably do it. They have two AI-based engines, and the one called Freedom is behind JLCA and the VB.NET Upgrade Wizard. Through a complex process, this engine creates a langage-agnostic intermediate representation of the original source code, which can then be written out in a completely different language.
Now, people tend to complain a lot about the VB.NET Upgrade Wizard, but if you stop and think about what the tool has to do, it works incredibly well. The quality of the original source is obviously going to be a major factor. If the VB6 source has Option Explicit off and looks, well, like most VB6 code does, it’s amazing that the wizard can make any sense of it.
One important thing to know is that ArtinSoft sells their own versions of both of these tools: the Visual Basic Upgrade Companion and the JLCA Companion. These products are much more advanced versions of the free tools. The VB Upgrade Companion can even convert your VB6 code to C#. Yes, VB6 directly to C#! How cool is that? ArtinSoft also offers consulting services to help with your migration projects.
Sometimes the right answer is to redesign and rewrite your code. Other (most?) times, that is very hard to justify to your CIO, and that’s when your company might want to consider ArtinSoft’s paid applications and services. Cost may still be an issue, since I hear that these tools are licensed by number of lines of source code, but that’s something to evaluate while you look at all of the pros and cons and make a final rewrite/upgrade decision.