Click here to Skip to main content
Click here to Skip to main content

ASP.NET Report Kit Grasshoper (Race to Linux)

, 2 Oct 2005
Rate this:
Please Sign up or sign in to vote.
Porting and deploying the report starter kit to Linux (RH7.3/Tomcat5.0.28/Grasshoper1.61)

Introduction

Oh my ! I can't belive it I'm writting this article, this is my first contributtion ever made at any place on the web; (it was really hard for me, but an XBox it's really an incentive!).

Before the race to linux was started (like 1 month before), i discovered this interesting tool, Grasshoper from MainSoft, trust me; very fine tool avaliable here: http://dev.mainsoft.com/.

I played with it for some time and then, whoa !; the race for linux was announced (i was very excited); I had the 1.60 version which caused me some troubles (that i hadn't noticed at first).

I liked a lot the article from Mark Cafazzo for the Linux race, so i will follow his writting a little.

Notes: The demo project file included here is pretended to be a self-contained package, ready to deploy on a tomcat server. But due to limitations of 2Mb file to the article the files

  • mscorlib.jar
  • Microsoft.VisualBasic.jar
  • System.jar
  • System.Xml.jar
  • System.Web.jar
  • System.Data.jar
  • System.Drawing.jar (Beta version)
  • System.DirectoryServices.jar
  • Novell.Directory.Ldap.jar
  • System.WebServices.jar

had been ripped of the demo project zip (war) file.

Requirements

For this article you will need:

  • A copy of the report starter kit from the guys at asp.net site (http://www.asp.net/)
  • A Sql Server database (or MSDE) to host the Reports DB.
  • Mainsoft grasshoper (v1.61) downloadable from their site http://dev.mainsoft.com/
  • Mainsoft beta modules (primary the System.Drawing beta) from their site
  • A java servlet container (an Apache Tomcat version is included with grasshoper)
  • Optionally and for the brave ones, a Linux distro (redhat, suse, debian, etc.) to test the final app

Methodology

To succesfuly port an ASP.NET app to Linux I know of two possible ways: re-code everything, or use a reimplementation of the .NET framework; (personally I think the second one is better and easier). Mono project aims to port the .Net framework so you can use it on other platforms; also Mainsoft has a similar way (they implement the .NET namespace components into java components so the can run in a java enabled environment).

Mainsoft provides us with effective aproach, compiled MSIL assemblies are converted to their similar at java (java bytecode); perfomance is not affected due the fact that they are not recompiled or modified, only translated to that of java.

Once our code is java-enabled bytecode, grasshoper will package it for us to deploy it via a WAR file (basically a zip renamed file which contains the files and assemblies needed for the app to run).

So basically, while our java framework components are named equal to that of the .NET (System, System.Data and so on) we can produce the same app for a java environment.

To port any app from ASP.NET to java i would recommend the following steps:

  • Generate J2EE project (via convert or new deployment copy/paste style)
  • Familiarize with the code in a sufficient manner to determine what components will need to be reimplemented or to be complemented by a java component. Also analize what of the .NET framework has not been implemented or is not supported.
  • Add neccesary components and overcome the missing pieces.
  • Compile and see if no warnings or errors are thrown, if they do, repeat the above steps.
  • Test you app completely, maybe some pieces may take a different behaviour than expected, if something breaks or malfunction do a DEBUG, get to the point where the code produces an error. Also READ the logs of the server, this can give you very important information of missing and required references or configurations.
  • Repeat until your app behaves as the way you need.
  • Once the app is working well on the testing environment, create the deployment package and test on at least other server (and preferrably on the final conditions environment).
  • Once the problems had been overcome, test again in the final environment.

Challenges

  1. Remember to download the System.Drawing beta from mainsoft, instructions on updating this references are here: http://dev.mainsoft.com/Default.aspx?tabid=136, copy the new System.Drawing to the jgac folder and update in your Visual Studio.
  2. The first thing noticed was the unsupported tags of web.config, for this project this tags weren't neccesary (sessionstate, pages validaterequest, customerrors), so I decided to comment them. Problem solved.
  3. If you have problems of complaining classes not found also check that the project namespace is correct, my generated project had a generated namespace of Reports_J2EE, so be aware that the project namespace is BLANK in this project.
  4. Be aware that the debbuging environment in grasshoper has ALL the dependencies at the server level. If you don't set references to the MSSQL jars it will function anyway; BUT for the deployment war file they will not be included. Make sure to add references to msbase.jar and msutil.jar; also when you create the final deployment war make sure you select Create self-contained package.
  5. Change the connection string in web.config so it points to the real db server and recompile, i was getting errors because my db was hosted on an other machine.
  6. At ChartGenerator.aspx.vb line 33 reads "Environment.UserDomainName.ToLower", if this function is causing troubles comment it.
  7. At the time of the first deployment i had this ugly representation because in Linux files are CASE SENSITIVE, make sure to rename Docs to docs, Images to images, and so on with the things you would think are not displayed correctly.
  8. I had a problem with the chart (visual report), that was caused by a version problem of grasshoper, I was testing on my development environment and didn't produce the graphics at ChartGenerator, MAKE SURE you have 1.61 version of grasshoper and the new System.Drawing component.
  9. Have an eye on this, if you deploy to a tomcat server on a Linux machine, and it is a windowless enviroment, add CATALINA_OPTS="-Djava.awt.headless=true" to the shell that is launching tomcat. If not you will not see charts and images. This is an issue of java.awt

Configure and deploy to Linux Machine

Installing Linux (at any flavor) is out of the scope of this this article, however you may find it useful if you google for "Installing Linux" or vitis here: http://www.tldp.org/LDP/gs/gs.html

Installing Linux has been made easy by the Linux providers, almost any distro has a graphical interface and should not be very hard to complete the process. As an alternative you can try Linux inside Windows from Mainsoft, avaliable at "Linux Tools" at their download site; as well you may try a virtual machine environment as VMWare if you like.

Virtual Machine environment also has the advantage that you can make a mistake and nothing fatal ocurrs, you just start from beggining.

To install the tomcat server in your linux box depends on the distribution you have chosen, you can use YaST or RPMs which are the package managers for applications on your linux machine.

For Suse you can open the YaST control center  an select to install

  • java-1_4_2-sun
  • java-1_4_2-sun-devel
  • java-1_4_2-sun-jdbc
  • tomcat5
  • tomcat5-admin-webapps
  • tomcat5-webapps

Which will enable you with the java required environment, if the manager complains about dependencies install them.

After installing tomcat make sure to start the tomcat service, the most generic way is

  • /etc/init.d/tomcat start

but also for Redhat/Fedora

  • service tomcat start

will do the job.

If your environment does not support YaST but does RPM this url may also be useful: http://mirrors.sunsite.dk/jpackage/1.5/generic/free/RPMS/

Once your tomcat is running you can test it on http://localhost:8080/, if you see that funny cat you are up and running. Test also the samples given onthe welcome page.

Your server-wide administrator for tomcat can be viewed at http://localhost:8080/admin, be sure to edit the "tomcat-users.xml" file at the config directory and that the groups manager and admin exists.

Your deployment web based tool is at http://localhost:8080/manager/html, you can deploy your war file here or deploy a directoy based app.

Once your war is deployed test it, voila !; your app is up and running in tomcat server.

For the bravest ones one final step is required, make it run on apache with the mod_jk or mod_jk2 connectors to have a real world java based app.

Additional installing instructions for other servers can be found here: http://dev.mainsoft.com/Default.aspx?tabid=32&src=ww_PackagingDistributingModules.html

Happy porting !

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

osohare
Web Developer
Mexico Mexico
Independant consultant living in Mexico City

Comments and Discussions

 
Generalisnt this the same article PinmemberMsftone2-Jan-07 1:09 
AnswerRe: isnt this the same article Pinmemberosohare2-Jan-07 4:39 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.141022.2 | Last Updated 2 Oct 2005
Article Copyright 2005 by osohare
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid