Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Software Microsoft IT Technology Linux

VS.Net Apps Can Now Run On Linux 245

MxTxL writes "EWeek is reporting here about a plugin for Visual Studio.Net, called Grasshopper, that allows web applications that once only ran on IIS to be run on Tomcat or other J2EE platforms. The Mainsoft Developer Zone has more details on how it works but basically it converts the MS Intermediate Language into Java bytecode. The developer is also a supporter of the Mono Project."
This discussion has been archived. No new comments can be posted.

VS.Net Apps Can Now Run On Linux

Comments Filter:
  • by Anonymous Coward on Wednesday May 25, 2005 @06:03AM (#12632239)
    For most developers, Visual Studio .NET is second to none when it comes to developing Web applications and Web services. And yet, we're hearing from Windows developers that they would also like to write applications for Linux.
    Wha... Second to none? .NET developers wanting to write web apps for Linux? What Bizarro world is this? I mod this entire project -1 Troll.
    • Re:Nothin' but .NET (Score:3, Interesting)

      by m0rph3us0 ( 549631 )
      I'd kill to be able to efficiently run ASP.NET on Linux.

      VS.NET is an excellent dev environment with good tools but Windows 2003 is clunky as a server. And MS SQL is a lot of money for a whole bunch of features most people never use. (I'm talking about federated databases, clustering, etc., NOT transactions, stored procs, etc)

    • Say what you want, but I love VS.NET so much I develop my PHP applications on it.

      http://jcxsoftware.com/ [jcxsoftware.com]
  • Well... (Score:5, Insightful)

    by Darren Winsper ( 136155 ) on Wednesday May 25, 2005 @06:06AM (#12632247)
    Considering that, using XSP or mod_mono, it's possible to run ASP.Net web applications on Linux using Mono itself, this is hardly a new development.

    Anyhow, there's no such thing as a "VS.Net App". It's been possible to compile .Net applications using VS.Net and run them on Mono (with certain exceptions) for a long time now.
    • Wohoo , if they'd finally port boehm's gc to openBSD I'd have best of all worlds!
    • Re:Well... (Score:5, Insightful)

      by hey! ( 33014 ) on Wednesday May 25, 2005 @07:42AM (#12632607) Homepage Journal
      Well, I'd say you're the victim of another poorly titled article.

      I'd have titled it "VS.Net applications now run on J2EE Servlet Containers".

      Personally, I think this is cool, but not Earth shaking. The most important reasons for users to do this would be to either migrate to J2EE or to get access to Java standard libraries. Since people on the MS side of the fence tend to rely heavily on the IDE to do a lot of the heavy lifting, I'm not sure it helps them that much. They can't maintain the software except by targeting the dotNet environment; their IDE doesn't know anything about the Java standard libraries or the J2EE container facilities. Maybe if they wanted to prototype stuff in VS IDE and then add things like security using filters or byte code modification to do AOPish method interception.

      In any case I see three possible applications. First, if some horrible security hole is found in IIS, you can get off in a hurry and deal with the maintenance issues down the line. Second, you may decide to use this to scale a successful application up using midrange iron. Third, you can show your boss that servlet containers do everything your application needs (but we all knew that, didn't we)?
      • Re:Well... (Score:5, Informative)

        by Locutus ( 9039 ) on Wednesday May 25, 2005 @11:28AM (#12634860)
        This all reminds me of how Microsoft got many of the UNIX CAD and EDA tools vendors to drop native UNIX coding for Win32 coding. They provided Mainsoft, Bristol, and others with a cheap license to the Win32 source code, which allowed them to sell tools which compiled Win32 apps to run on UNIX. The apps vendors liked this because one codebase supported both Windows AND UNIX. But then, Microsoft quadrupled the license fee for the Win32 source and only one vendor could afford to pay that new fee. The same vendor Microsoft hired to port MS Internet Explorer to UNIX. They did this so that they could afford to pay that huge licensing fee and provide proof in court that the increased fee was not excessive and preditory. All of a sudden, the CAD and EDA software that used to run on both Windows and UNIX, only ran on Windows. And porting back to UNIX would have been almost impossible because of the nice job Microsoft does at not supporting standards or best software practices for design.

        Mainsoft is that one company which Microsoft funded while it killed off the others. Mainsoft is the one announcing a tool that'll let you write software in Microsofts API( .Net this time ) and run it on other systems. Gee, where do you think this will end up going?

        IMO. History IS the best teacher.

        LoB
  • by darnok ( 650458 ) on Wednesday May 25, 2005 @06:08AM (#12632251)
    I'm in the early stages of experimenting with Mono's XSP as a drop-in replacement for ASP.NET. Looks quite promising at this stage, but I've got a lot more testing to do before I'll be turning off banks of Windows/ASP.NET servers and replacing them with Linux/XSP.

    Still, nice to know there's an alternative if for some reason XSP doesn't work out.
  • Was this only to take advantage of already existing VMs to create instantaneous cross platform usability? Are there plans to remove the byte-code to byte-code translation?
  • java ripoff (Score:5, Funny)

    by tines ( 806906 ) on Wednesday May 25, 2005 @06:15AM (#12632271)
    so the .net is really a java ripoff. the bytecode maps amazingly well. +1 obvious
  • by tezbobobo ( 879983 ) on Wednesday May 25, 2005 @06:18AM (#12632280) Homepage Journal
    It's all a microsoft conspiracy to prove that linux is the more insecure system - now vulnerable to the vast raft of windows insecurities. Muwhahahaha!!!!
  • by t_allardyce ( 48447 ) on Wednesday May 25, 2005 @06:20AM (#12632282) Journal
    ..but wasn't the whole point of dot net platform independence !?!
    • Independence of which hardware platform you're running Windows on. I think the .NET project was started when it was still believed that Itanium might make it. Then, there's the whole Issue of porting all those 32-bit x86 apps to the AMD64 architecture. Moving Windows to a new architecture is by no means as easy as it is to move GNU and Linux, or most other Free Software to another architecture. It's a chicken-and-egg problem, and as such, it's much more pronounced on proprietary systems, you have to get all
      • actualy "porting" 32-bit apps to amd64 is pretty much a non-issue. The 64-bit Long Mode is just 32-bit Protected Mode with the ability to optionaly have longer word size and more registers. It's absolutely nothing like moveing from 16-bit Real Mode to 32-bit Protected Mode.
        • I'm aware of that, but try convincing semi-bad programmers to use 'size_t' rather than 'int' when appropriate, or making use of the 'sizeof' operator instead of hardcoding the values. (I don't let people like that anywhere near my source code repositories ;)) Besides, if you don't have access to the source, you're still stuck, no matter how easy it would be to port if you did have the source. I think this is the issue that MS (and Sun for that matter) wanted to address with .NET and Java.

          ~phil
    • by mattyrobinson69 ( 751521 ) on Wednesday May 25, 2005 @07:00AM (#12632401)
      the whole point of .NET was so they had yet another buzzword to throw around:

      PHB: Is this 'Linux' thingy written in .NET?
      tech: no.
      PHB: does it leverage the power of XML?
      tech: er, no

      thats all i'm afraid, my buzzword library has gone blank.
    • To answer this I refer here dotnetspider [dotnetspider.com].

      specifically this quote:

      Many people ask this question "Java is platform independant, what about .NET ?".

      The answer is "Yes" and "No" ! The code you write is platform independant, because whatever you write is getting compiled into MSIL. There is no native code, which depends on your operating system or CPU. But when you execute the MSIL, the .NET framework in the target system will convert the MSIL into native platform code.

      So, if you run your .NET exe in

      • Talking about this, I have had a question for quite some time, what about the speed performance of .NET VM versus Java VM??

        Is .NET faster than Java? more reliable? also, Which one generates smaller files for the same amount of (average) code?

        And, do you know of any serious commercial application in .NET now? I mean, something as big as mmm Paint Shop Pro or like that, I would have to ask the same for Java, but I have seen some really good (and serious) proprietary applications where I used to work (Mexic
        • Many companies run their entire enterprise on .net, already. We do, and have since v1.0. .NET performs VERY well, however it does suffer from a ton of sub-par developers migrating from ASP/VBScript/VBA(office dev) who don't understand the power they've been handed.

          I will however readily admit that I've very little experience in java enterprise development, but if java can outperform some of the amazing features of .net managed code, I would be surprised.
    • PROCESSOR independence, maybe - but certainly not platform independence. It was supposed to be Windows-only (but able to run on different CPU architectures).
    • but wasn't the whole point of dot net platform independence !?!

      Actually a good chunk of the "point" of .NET is language independence. Right now I'm on a couple of projects where portions are written in C# and portions are written in VB.NET. If we wanted to, we could do portions of it in Managed C++. The notion is that if you have a developer that's good in C# and one that's good in VB.NET instead of one having to learn the language of the other, they can both work together.

      Of course the limitation to

    • The whole point is language independance, not platform independance.
  • Is EWeek's server using this bytecode-to-bytecode translator or are they running IIS?

    http://www.eweek.com/article2/0,1759,1819422,00 .asp [eweek.com]

    Classic ASP apps can run under a .NET enabled server. EWeek should eat they dog food they're writing about.

    • Re: (Score:3, Insightful)

      Comment removed based on user account deletion
    • They're running Vignette.

      Another buzzword of it's day, whose single trick was to save every file requested as a file on the docroot.

      The URL can be pulled apart to show the caching technique:
      0,1759,1819422,00.asp

      0 = cache|don't cache

      1759 = template id to use... the template is bound to the path so you don't need to send this in

      1819422 = some ID used to fetch whatever you want on the page, article in this case

      00 = features... consider them flags for other platforms, re-format for WML, etc

      The .asp is ir
      • With the newer versions of Vignette they supported coding in both ASP and JSP and working within the vignette platform. They might be better now, but when they first added this feature the native Tcl code ran much faster than a template written in ASP or JSP. And if you're writing in ASP or JSP, why bother with vignette? The only thing vignette ever got right was charging a million dollars per installation so that managers would think 'wow, this must be good if it costs so much'.

        Vignette was the biggest
    • EWeek is reporting news, not endorsing it. The story is linked on Slashdot; should slashcode be rewritten in ASP.NET?
  • Vanilla please (Score:5, Insightful)

    by asliarun ( 636603 ) on Wednesday May 25, 2005 @06:26AM (#12632302)
    I think that half-baked solutions like this plugin is a bad idea, at least for code that will land up in production servers. I would prefer a vanilla implementation anyday. By porting a .NET assembly (or IL code) to Java bytecode, i would be unnecessarily increasing the chances of getting wierd or untraceable bugs. Then, there's the question of maintaining the ported code.

    A better albeit more time-consuming solution would be to rewrite the source code itself. The plugin in question might possibly be of some use if we need to quickly port a small application from .NET to Java. But for an enterprise or complex system, no way!
    • Yeah, I agree this sounds more like a dirty hack than anything else. I'm not even sure you save so much time either because of the possible weird bugs from a translated bytecode you talk about. I'd say: spend that time of ensuring your app still work as it should and solving any such bugs, instead with taking your source to Mono and fix up GUI code etc for GTK# or whatever. I'd feel much safer that way, for personally having worked with the code instead of an automated tool.
    • Re:Vanilla please (Score:3, Insightful)

      by jellomizer ( 103300 ) *
      How is this different from ordinary .NET development. You get weird and untraceable bugs in .NET normally. Maintaing it is just as easy as it was before you just make changes in the code and recompile it. And if it is a compiler issue that is why Pre Processor Directives are their. It is the same as OSS people developing code code for PowerPC, x86, and Sparc. with GCC. Yes it is a bit more complex then writing in one platform, but about the same for writing for multiple platforms.

      My guess is that you
      • Re:Vanilla please (Score:4, Insightful)

        by asliarun ( 636603 ) on Wednesday May 25, 2005 @09:39AM (#12633511)
        " How is this different from ordinary .NET development. You get weird and untraceable bugs in .NET normally."

        The same can be said for ANY platform. The number of bugs that you'll encounter is a function of the quality of your system architecture and the quality of code that you write, NOT the platform. The .NET framework, in its current stage (1.1) is a reasonably stable and robust platform, and is no better or worse than the other alternatives.

        "My guess is that you are either a student (Or recent Grad), work for a government agency, or Non Profit agency, education, or a Really big company that has a lot of disposable money. time-consuming == waisted money."

        Yes, i do work in a reasonably big company, and i've developed over 10 medium-scale and enterprise solutions. Believe you me, no company has money to throw away. Every decision has to be justified across several parameters, namely ROI, stability, performance, maintainability, and so on. Furthermore, funding for a project comes out of a department, not from the company itself. Hence, your argument of a big company having a limitless budget is irrelevant, as the (big company's) department budget is never limitless. In fact, it might be much less that the budget of say, a startup or a much smaller company.

        Again, i'm not saying that the plugin serves no purpose. All i'm saying is that this mechanism of porting to a different platform is only limited for simple and non-critical applications. As a project manager or a technical lead, are you willing to stake your reputation (or your career) and say that the ported Java code will be as stable as the original .NET code?

        Will the plugin successfully translate a remoting application, a web service with SOAP serialization, an ASP.NET application that extensively uses HTTP Handlers and HTTP Modules?? A lot of features that exist in .NET, and ASP.NET/IIS don't even have an equivalent in the other frameworks. How about something as simple as delegates or the ASP.NET support for out-of-process sessions (state servers), which you NEED for a web farm deployment?
        • "Yes, i do work in a reasonably big company, and i've developed over 10 medium-scale and enterprise solutions. Believe you me, no company has money to throw away. Every decision has to be justified across several parameters, namely ROI, stability, performance, maintainability, and so on."

          You've never worked for a government contractor have you? I spent a couple years working for one of the largest US defense contracting companies and trust me when I say government contracts are literally black holes that
  • by Fuzzums ( 250400 ) on Wednesday May 25, 2005 @06:57AM (#12632383) Homepage
    EWeek is reporting here about a penguin for Visual Studio.Net, called Grasshopper...
  • by Decker-Mage ( 782424 ) <brian.bartlett@gmail.com> on Wednesday May 25, 2005 @07:16AM (#12632482)
    Well I did. Guess what, bring money if you want to deploy using this beast. Here's the limitation right from the EULA:

    "Small Workgroup Configuration" means a Java-based hardware and software configuration supporting the execution of a Developer Application and limited to (a) Apache Tomcat excluding any other J2EE application servers and (b) single CPU (Central Processing Unit) computers excluding computers with multiple CPUs' and excluding cluster or grid of computers.

    You can forget running on your personal multiple cpu development machine, let alone anywhere reasonable, unless you pay the price. It ain't free folks!

    I went digging to find the price for deploying it on anything but what they consider a workgroup machine. You'll find that in What are the licensing terms for Grasshopper [mainsoft.com]. Bring lots of money! At least MS gouges me only once.

    I believe I'll stick to doing my own porting, thank ye!

    • Sure that's a BIG number, but ultimately $5000 is worth 2.5 weeks of my time which is hardly an earth-shattering amount.

      I suppose they do price themselves out of the water for smaller apps, but assuming this can run large apps correctly then it could save a LOT of cash.
  • I see failure! (Score:3, Insightful)

    by cyberjessy ( 444290 ) <jeswinpk@agilehead.com> on Wednesday May 25, 2005 @07:41AM (#12632601) Homepage
    No large IT implementation would trust an MSIL to Java byte code conversion. In most cases downtimes are simple un-acceptable. And if one pessimistic guy suggests data corruption they would not even think about it. They might even buy a source code conversion tool (like Microsoft Java to C# converter JLCA), but not converted byte-codes.

    Again such large clients are most likely to want this tool too, a common case being new .Net projects failing to integrate into their predominantly Java-based applications.

    Medium sized companies would most likely run it on .Net. itself.

    For smaller companies, looking to save money on MS licensing, Mono will be a better alternative since they would not have the integration requirements of the larger companies, which only Java can provide. Mono has been tested more rigorously than this byte-code conversion magic.

    Then there are software development companies, looking to port their .Net applications into Java. They wouldn't care about reliability as long as they make quick money. But then, .Net has been around for relatively short period and hence .Net-Java conversion would be less likely than a Java-.Net conversion.

    So who would try this product, other than purely out of academic interest or curiosity? I have a totally pessimistic view about this product.
    • [cynical mode on]
      The market I can see for this is consultancy companies with expertise in VB.Net that are required to deliver a solution running on Linux.

      No staff retraining will be necessary so they can make use of the existing skills. The costs involved will be way less than those of such retraining. Furthermore they will be able to deliver something quickly to the client. The ongoing server fees can be hidden in the consultancy fees.

      Any ongoing problems will require more consultancy to remedy them

  • I think the biggest problem with running .net apps on non-microsoft platforms is working around the gaps in the framework.

    Off the top of my head I can think of two specific examples that will cause problems, but I'm sure there are many more:

    1. Printing the contents of a rich text box.

    Microsoft's solution to working around this hole is detailed here [microsoft.com]. Note how it starts with the line [DllImport("user32.dll")].

    2. Clearing the console

    Microsoft's recommended way of doing this is detailed here [microsoft.com] and, once

  • Hooray! (Score:5, Funny)

    by Greyfox ( 87712 ) on Wednesday May 25, 2005 @10:22AM (#12633934) Homepage Journal
    All the ease of use of Linux combined with all the security of Windows! My prayers are answered!

    Yeah... that's just what the world needed...

  • Now I can run all of the poorly converted Java programs I like back in the Java container again instead of just using the originals! That is awesome!

  • How far away is a converter to bytecode that runs on J2ME? I'd love to target easily developed .NET apps at more reliable mobile devices.
    • Hey, what about the other way round? There is no good, free Java implementation of any kind for recent WinCE. (Kind of obvious, since there is no good, free Java at all. Maybe one should start contributing.)

      I imagine it could possibly be simpler to get J# code from MS running, combined with the NetCF and a byte-code converter from Java. Kind of like running Win95 in Bochs on your PDA... (i.e., useless)

"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs

Working...