Jack @ ASP.NET

A polyglot is a computer program or script written in a valid form of multiple programming languages, which performs the same operations or output independently of the programming language used to compile or interpret it.

Generally polyglots are written in a combination of C (which allows redefinition of tokens with a preprocessor) and a scripting programming language such as Lisp, Perl or sh.

For the past few years, many industry leaders were saying that developers needed to know multiple languages. They were right, because learning multiple languages (if done correctly) meant that you needed to learn different programming idioms: procedural programming, object oriented programming, functional programming, and so on.

But that’s painful. Why should I need to learn new syntax to use new idioms? Curly braces aren’t allowed in FP? semicolons aren’t permitted in dynamic languages?

Instead, why can’t a general purpose programming language support multiple programming idioms? C#, VB.NET, and C++ are starting to seriously support that. (Other languages may be doing this as well; I don’t know). All these languages have added (or are adding) lambda expressions which support functional programming concepts. (C++ has used Class Type Functors for this purpose for some time). C# is adding support for dynamic typing (as is VB.NET, in a more strict fashion than previously supported). Implicit typing is supported in C#, C++, and VB.NET as well.

This trend will continue as more and more developers want to use the best programming idiom for a particular task without learning a totally different syntax. Any programming language that calls itself a “general purpose language” will support multiple idioms.

The bad news is that only 52.7% of the users has .NET Framework 3.5 installed on their PCs, but as you can see from the table they become more and more very fast:

Unfortunately, because Visual Studio 2010 Beta 2 and ASP.NET MVC 2 Beta share components which are currently not in sync, running ASP.NET MVC 2 Beta on VS10 Beta 2 is not supported. Regarding Visual Studio 2010 and .NET 4 support, that is unfortunately not a feasible option. The most recent public release of VS2010 and .NET 4 is Beta 2. However, our internal builds of MVC 2 for VS2010 and .NET 4 depend on features that were available only after Beta 2. In other words, if we released what we have right now for VS2010 and .NET 4 then it wouldn’t even run.

The good news is that the Visual Studio 2010 Release Candidate will include a newer version of ASP.NET MVC 2. 

Highlights

As you might expect from a release candidate, most of the work focused on bug fixes and improvements to existing features. We also spent a lot of time on performance profiling and optimization.

Much of the focus on this release was in the client validation scripts. For example, the validation script was moved into its own file and can be included at the top or bottom of the page. Client validation also now supports globalization.

The other change related to validation is that the ValidationSummary now supports overloads where only model-level errors are displayed. This is useful if you are displaying validation messages inline next to each form field. Previously, these messages would be duplicated in the validation summary. With these new changes, you can have the summary display an overall validation message (ex. “There were errors in your form submission”) as well as a list of validation messages which don’t apply to a specific field.

What’s Next?

RTM of course! The RTM release of ASP.NET MVC will be included in the RTM release of Visual Studio 2010, which is slated for some time in March. The VS2008 version of ASP.NET MVC 2 might release earlier than that. We’re still working out those details.

Until recently your only choice for developing applications for Apple’s iPhone was to jump into the Apple development ecosystem. This means being willing to write Objective-C code in the XCode IDE. For many developers, learning Objective-C was seen as a huge barrier-to-entry. This is especially true for many .NET developers whom have never had to worry about memory management, pointers, and other C language responsibilities that they are unfamiliar with.

All this has changed with the introduction the MonoTouch framework, a part of Novell’s Mono Project. The Mono Project is an open-source implementation of Microsoft .NET Platform. It allows you to run .NET applications on nearly any platform, including Apple, FreeBSD, Linux, Unix, and others. MonoTouch, which is a new part of the Mono Project, allows you to write applications using C# with .NET platform that run on the iPhone.

The intent of this article is to provide a solid introduction to the MonoTouch platform, where to find all the necessary pieces, the limitations of it, and how to build a basic application.

How does it Work?

When building MonoTouch applications, most of the non-UI .NET 3.5 stack is either already available, or is in the roadmap to be included. This allows you to write applications using many of the .NET Framework Technologies that you’re already familiar with, including Windows Communication Framework (WCF), Workflow Foundation (WF), etc. It also includes nearly all of the Base Class Library (BCL) including things like Garbage Collection, Threading, Math Functions, System.Net, Cryptography, etc. For a list of available standard .NET assemblies see http://monotouch.net/Documentation/Assemblies. This is accomplished through a MonoTouch-specific set of base .NET libraries, similarly to how Silverlight and Moonlight work.

This means that you can compile standard .NET 3.5 code libraries using the MonoTouch core assemblies and use them in your application. So if, for example, you have a specialized library that does advanced math functions for engineering problems that you use for other applications, you can simply include the code library in your MonoTouch solution, and reference it. When you build your solution, it will compile it using the MonoTouch libraries, and it will then be available in your application.

MonoTouch also includes wrappers to the native iPhone APIs such as Location (GPS), the accelerometer, address book, etc. It also gives you the ability to bind to native Objective-C libraries that are not wrapped, so you can interop directly with existing Objective-C code.

How do I Distribute My Apps?

MonoTouch applications are distributed the exact same way that traditional iPhone applications are distributed, either via the Apple App Store, or Enterprise deployment.

The App Store is an online repository that allows users to pay for applications (if they’re not free), and download them. It is available from within iTunes, or directly from the iPhone itself. In order to get a license to distribute via the App Store, you must register with Apple, and pay $99/year.

Enterprise deployment is for those wishing to develop internal applications for a company, and distribute them to employees, etc., without listing them with the App Store.

What is the Licensing Model?

Unlike Mono, MonoTouch is not open source and is a commercial product. That means if you want to do anything useful with it you have to purchase a license. MonoTouch comes in three flavors and prices:

• Professional ($399) – A single personal developer license that allows you to develop applications and distribute them via the Apple App-Store.
• Enterprise ($999) – A single corporate developer license that allows you to develop applications and distribute via the App-store, or enterprise deployment.
• Enterprise, 5 Seat ($3,999) – The same as the Enterprise license, but includes 5 seats.

All three options include a year of free updates.

There is also an evaluation edition that allows you deploy to the simulator only. For the purposes of this introduction, that is all we’ll need.

It should be clear from the additional content what’s new: I added coverage of the significant C#4.0 features like dynamic invocation and named / optional parameters. New library additions like PLINQ are also covered.

It’s much harder to see how I decided which items to drop. There are 15 completely new items in the 2nd edition, so that meant finding 15 items to drop. (Several other items have the same title, but were significantly rewritten – that will be the subject of another blog post.) Here’s how I decided which items to remove:

Items that are less important now. A number of the items in the first edition discussed techniques that were much more important before generics were available. Some of these items were those that discussed boxing and unboxing, the collection classes, and the data set class. All of those techniques and libraries were far more useful in C# 1.x than in the current .NET universe.

Items that have become common practice. C# has been around for almost a decade, and the community is much more mature than it was in 2004, when Effective C# was published. Some of the items are part of the conventional wisdom now

Items that assumed your last language was C++ or Java. The early adopters of C# were developers that came from C++ (on the Windows platform) along with some developers that came from Java. That’s no longer true.  College grads (since 2002 or so) are using C# for their first professional programming experience. Others are coming from VB, Ruby, Python, or PHP. (I’m not claiming that C# is grabbing market share from all those languages; the migration happens in all directions.) It just wasn’t right to assume that every C# developer has C++ or Java experience anymore.

The poster child for dropping items is the original Item 41, where I advocated using DataSets rather than implementing IBindingList yourself. I didn’t rewrite this item because the obvious answer now is to use BindingList<T> when you need the IBindingList capability. If you were using DataSets for some other reason, pick some other generic collection type. There are many, and the options grew again in .NET 4.0. Those generic collections have better APIs (the type parameter means the compiler ensures type correctness), and better performance (boxing / unboxing doesn’t apply. It’s not often that it’s trivial to get better performance and better chances at correctness. Even in the 1.x days, I didn’t advocate using DataSets are part of a service API. That was and still is a painful choice.

There’s also been many enhancements in the .NET framework that mean there are better data solutions. LINQ, along with the query syntax pattern (See Item 36 in More Effective C#), means there are much better ways to work with data in .NET 4.0.  Chapters 4 and 5 of More Effective C# discuss these important techniques. The entity framework has matured, and is a better way to handle data transfer between layers and machine boundaries. (I still need to look more closely at the latest EF, I know some of the changes, but not all).

MaximumASP is offering a free hosting account so you can get started with ASP.NET 4 and Visual Studio 2010.

On this account you can test ASP.NET 4 applications in a hosting environment and try out the new publishing features with Visual Studio 2010 and the Microsoft Web Deployment Tool.

• Windows Server 2008 R2 / IIS 7.5
• .NET Framework 4 Beta 2
• 1GB disk space
• 50 MB SQL Server 2008 database
• MS Deploy Access
• FTP over SSL Access

The environment on which your apps will be running is a slimmed down version of our robust MaxESP platform. Experience some of the platform’s features such as instant scaling, application aware load-balancing, and the IIS Remote Manager. If you like what you see during the ASP.NET 4 beta, sign up for a full account. We would love to have you.

http://aspnet4beta.maximumasp.com/