Hints and Tips for Effective Porting

Introduction

If you want to run the 'Race to Linux' or if you simply want to migrate your existing ASP.NET applications to run on J2EE or Linux, and you weren't sure where to get started – then this article is for you! In here you'll find some valuable hints, tips and pointers for where and how to get started, and some valuable shortcuts that will help you get to Linux quicker and more easily!

Grasshopper Developer Edition

The first thing to do, of course, is to get your hands on the latest version of the Grasshopper developer edition. You can download it from here. If you haven't already used Grasshopper, you'll find it to be a very simple to use and powerful tool. It's a plug-in for Visual Studio.NET that takes your compiled ASP.NET code and translates it into Java Byte code so you can run it on your J2EE system on Linux. In many cases you don't need to alter your ASP.NET code at all – it just recompiles and runs! The latest version, 1.6.1, adds support for localized versions of .NET from several European countries as well as broader support for the .NET framework. You can read full details in the release notes. We've also published lots of articles around how you can get started with Grasshopper on our developer zone.

Running Linux Inside Windows

So, you'd like to enter the Race, or, you'd like to try out your ASP.NET applications on Linux, but you don't have a Linux box handy, or perhaps you don't have time to set one up straight away. Fear not! Linux Inside Windows is here to save the day! Linux Inside Windows (LIW) is a full virtual machine running Linux, Grasshopper, PostGres, Tomcat and all the other goodies that a typical Linux system needs to host server applications. What's more it's a simple download and install, and it runs straight on your Windows box. Click here to get full details on how to download, install and use it. You can be up and running your ASP.NET applications on the Linux operating system without any new hardware in no time flat...

Dependencies

There comes a time when a tool as powerful as Grasshopper cannot do everything. So, for example, if your application uses some dependencies for which you do not have the source code, or, if it uses some DLLs or COM controls via COM Interop, then you might think there's no way it can get to Linux. This isn't necessarily true, but it does present a challenge. In a circumstance like this, a best practice that you can follow goes something like this –

1. Isolate the dependencies by writing accessor classes for them. An accessor class is one that talks to the dependency on your behalf. The rest of the application should then only talk to the accessor class, and not to the dependency directly.
2. Find, or write (using Grasshopper or otherwise) a Java-based implementation of the functionality encapsulated by the dependency. For example, if the dependency was a charting object, then you could quite simply find a charting object that is implemented in Java and meets much of the same functionality.
3. Use Grasshopper to import the JAR files for the Java implementation. Write a new accessor class with the same property/method/event footprint as the one in step 1.
4. Remove the old dependencies and accessor class and substitute the new one. You should now be good to go to run on Linux using J2EE!

Database

Perhaps the biggest difficulty in migrating an application to run on Linux is in the database. For a typical web application, the web server that hosts the logic and the database server that hosts the data are likely to be separate machines. If the cost of migration for the database is too high (for example if a SQL Server has lots of stored procedures), the typical pattern is that the web server and applications get migrated to Linux, but the database server remains running SQL Server on Windows. However, if you really want, or have to migrate the data to Linux, here are some tips.

If using Postgres, there is a free tool available called ms2pg. This is a utility that assists in migrating a database from Microsoft SQL Server to PostgresSQL. It connects to each database and copies tables, primary keys, indexes and data. Full details on how to use it and how to download it and other supplementary items such as necessary drivers may be found at: http://www.edoceo.com/creo/ms2pg

It doesn't support Stored Procedures, so when migrating, take a look at the stored procedures that you are using carefully. In many cases developers write stored procedures to do simple tasks like SELECT, INSERT and UPDATE statements. Following a similar procedure (no pun intended) like that for dependencies (above) you can isolate these and migrate them cleanly by converting the stored procedures into straight SQL.

1. Write an accessor class for the SQL database functionality in your application. Modify all your application code so that it uses this accessor class.
2. Migrate your tables, keys, indexes and data using the ms2pg tool mentioned above.
3. Write a new accessor class for PostgresSQL database that has the same method/event/property footprint as the original. In functions where the original called stored procedures on the SQL Server database, you'll have to instead call SELECT, INSERT, UPDATE or other queries or functions on the PostgresSQL database, and manage the returned datasets.
4. Swap the accessor class from (1) with the accessor class from (3).

The difficulty of this task, especially from step 3, will vary based on your application. However, following isolation of code through accessor classes, and thinking in terms of what needs to go in, and what needs to come out of these classes should simplify things somewhat. Ultimately, for a successful migration, you migrate the functionality of the application, not the implementation of the application. So, if the application does the same thing, using one implementation type (i.e. SQL) instead of another (i.e. Stored Procedures), then you can still say that it is a successful migration.

Conclusion

This article was a quick one-stop shop where you were introduced to several tips and workarounds that you may need when migrating an application from ASP.NET in Windows to Linux. It's strongly recommended that you try out some of the practices outlined in this article if you want to get up and running quickly, including using Grasshopper, Linux Inside Windows and the outlined practices for handling dependencies or database issues.

Happy porting!

The Grasshopper team.