I am thinking of developing a website using the ASP.Net MVC framework on Linux. I would like to know:
what are the best practises for developing such a site (are they any different for mono/ Windows)?
any gotchas I should be aware of
any (material diffeences) - e.g. missing/proprietary libraries/componenst between Mono and .Net
are there any special directives, modules required to run Mono with Apache?
Are there any performance differences between a site hosted on Windows/IIS and Linux/Apache?
I intend to do most of my development using VS Studio - can the site be developed using VS and then deployed on Linux?
I am aware that this question has been asked several times here on SO. However, most of the questions date back to 2008 or 2009 - which is a very long time in internet time. Things may have moved on since those answers - so those answers may no longer be relevant.
I have to state that I am NOT interested in hosting the site on a Windows server - so I am only interested in what works for a Linux server deployment.
I'am currently working on a MVC 4 app and we are using Mono. If you are just planning to have a basic website, you should go for it. But for more complex flows, honestly, I think you should do a little bit of research first, to see if the features you want to implement are supported in Mono. Things you should consider:
only a set of restricted libraries are supported on mono ( for example, right now we are having some issues due to the fact that the mono libraries (Novell and DirectorySearcher) for LDAP do not support pagination)
the developing environment will be different than your server env ( I am using Visual Studio, we managed to pass this limitation by adding a lot of logs)
we do our publish using FTP, so yes, you can deploy it from VS, using a publish profile set up for FTP
it's free, but it will take a lot of time to research & do special thinks just for the sake of Mono
not a lot of documentation available, because not a lot of people use it, so if you have a specific problem, it will be more difficult to solve
My experience is from 2011, but I am pretty sure you will have to experiment to see works and what doesn't - that's my experience with Mono.
Most of your questions are extremely broad and I think your question will be soon closed.
As for your last question this was the way I did it and it worked (develop in VS->deploy to Linux), but you must be aware that:
just because your code will work in the VS debugger it doesn't mean it will work when deployed;
there is no one-to-one mapping between Mono and .Net. Even when things work it doesn't mean they will work the same way. For example the implementation of the encryption code used for http cookies was very different between mono and .net.
Related
I have to build an Automated Chat Application which will have it's front end as a widget on the website and back-end logic at server. It's main purpose will be to provide an interface to the customers to solve their queries with a chat personnel sitting at a location with the server as the communication point. If there is no person available then the application will parse the string and try to give a few answers by checking among a database.
I have a very good experience in C++ and a little experience in Java. The main concerns of the application are source code security and highest efficiency.
The restrictions which i am facing from the server side is that i have to run it on IIS and the only scripting languages supported are PHPv5, ASP, ASP.NET and FastCGI.
I am not going for PHP since i have found from googling that it's possible to reverse engineer it and it will take me a lot of time to learn a new language, so a strict no.
I prefer going for FastCGI cause it will serve exactly what my requirements are, but i am unable to find a way to compile on windows with C++ or any good tutorial. Most of the results i found on google related to FastCGI development were about Linux or in Perl for windows. I am also unable to find a way as to how to compile it on windows platform.
I am now being forced to go for ASP.NET, which will be my last option since it's an Interpreted Language and Interpreted languages have a tendency to be weak against reverse engineering.
So can anyone suggest me how to go about with it. If there is no way out for FastCGI then suggest me which will be good amongst MVC and WebForms for the given situations. I am new to both of them and i need to complete the application within two weeks.
First things first.
EVERYTHING can be reverse-engineered. It just depends on how smart the guy trying to reverse engineer your code is. Obfuscating is not a replacement for securing your code. If your server side PHP is safely stowed away on your server with all the proper security parameters configured, then you have nothing to worry about. But if you don't know PHP already then fair enough.
ASP.NET is only partly interpreted. The C# or visual basic that you use for the server side code is compiled. What IS interpreted is the code directly on the page. Remember though that most of your logic does not take place there... it takes place in the code pages which are compiled and the page code is mainly for displaying what you have already calculated. But don't forget that any server side tags that you put into your HTML on your pages get parsed and stripped out when the page is served to the user. If you have a tag <%: ViewData["value"] %>, the user will only see the value for "value" when they look at your source, and not the actual server side tag.
You are going to have a tough time learning ASP.NET AND completing your app in two weeks. I personally love ASP.NET MVC, but if you don't have much of a web programming background then it probably isn't the easiest thing to learn in comparison to Web Forms. That said however...
I'm not a fan of PHP, but it is widely used and a great language for setting up simple projects quickly. There are also tons of examples out there and it is of the first web languages that people learn (in part for those reasons). If you have two weeks to learn a language and set up a project, go with PHP. Even with a C background, there is a lot more to web programming than just knowing a server side language, so you'd be best off a quick and dirty language that gets what you want to get done, done, with minimal effort. That is to say, PHP.
FastCGI / C++ has a better performance. If you need a link on how-to: http://cgi.sourceforge.net/ and much more with google search.
First off, the little voice inside my head is screaming that this is a bad idea and it shouldn't be done, but my pragmatic side is asking "How bad could it be?"
The stark fact is most of my company's day to day "business" happens in one MS Office tool or another. Data is exported out of our custom tools as *.tab, *.csv, manipulated in Excel and imported back in with variying degrees of success.
Most of these custom tools are ASP.NET MVC web applications whose usability could be enhanced by more interoperability with Office.
I've fought the good fight for many years saying Office on a web server is a terrible idea. Lately I've been thinking that the enhanced usability outweighs the potential risks.
Am I going crazy?
You don't say what version of MS Office you are using in your workplace or what type of interoperability you are after.
If you want to generate Office documents 'on the fly' directly from the web application, then if you are using Office 2007 or 2010, the default document formats (.docx, .xlsx) are based on the Open XML SDK. This means that it is possible to generate documents dynamically without having to install MS Office on the web server.
If you are using Office 2003 or earlier, it is generally considered bad practice to install MS Office on the server - it is an unsupported configuration.
This Microsoft article outlines many of the possible issues you may face if you decide to go down this route.
Microsoft Office is not designed to work in a server which could be a highly distributed, multithreaded environment. It is a client application which by the way is mainly unmanaged code. So installing it and using it from a web server could hide potential problems: leaking handles, GDI objects, marshaling between managed/unmanaged memory, STA COM objects, etc. I would recommend you using only tools which have been designed to be used in a server environment.
You can create good office documents without installing office on the web server. Options include SpreadsheetML, components from aspose.net, and even just changing the file extension and content type on html responses to fool office itself.
If you do not want to install the full Office suite, then you can just install the Microsoft Office Primary Interop Assemblies?
http://msdn.microsoft.com/en-us/library/aa159923(office.11).aspx
I've seen this work in environments with very low loads...but as soon as the load increases the issues start to creep up. This has even be documented by Microsoft as the article pointed by Jazza clearly shows. Notice that this article is quite recent (July/2010).
The issues that I've seen are memory leaks, instances of Word/Excel not being stuck in memory, weird registry issues, and so on.
Another thing to consider is that Microsoft will not support you if you call them with issues related to Office on a server environment.
Again, if you only have a few users this might not be a problem for you initially but be prepared for scale issues.
I have little experience with ruby itself. I am going to hire somebody to write a web based application and I wanted it to be written in RoR but I was recommend mono. I guess because they like mono and because they think the RoR is slow.
The whole application would be some kind of social media meta management tool. There will be front end web based part and then back end doing the 'real stuff'.
I have no experience with mono at all and I am not experienced enough to comfortably say that RoR is the best choice.
I understood that if RoR is configured properly it could be pretty fast. I read that RoR has some troubles with scalability. I will start the application small and if it's successful I need to scale it up.
What would you recommend?
in the light of
performance
scalability
easiness to test
easiness to maintain, develop code/project
( I like ruby but I am not going to be the developer myself. I prefer to choose the 'better' option if there is such answer to that question)
please feel free to suggest anything else ...
If you are not going to write it yourself, you may want to go with what the person who will write it is most comfortable with.
Full disclosure: I have developed several sites now using Mono and I love it. I have used Ruby-on-Rails but not for anything nearly as big as what I have done in Mono. Keep that in mind.
Quick answer: In the greater scheme of things, Ruby-on-Rails and ASP.NET MVC have more in common than not. My choice would be ASP.NET MVC on Mono but I doubt you would regret choosing either.
Architecture: If you want one way of doing it out of the box, choose Ruby-on-Rails. If you want to be able to choose what you feel are the best-of-the-best technologies from a range of choices, choose .NET (Mono).
Ruby-on-Rails is more of a turn-key solution in that it provides a standard way of doing pretty much everything you need out of the box. .NET (Mono) offers a lot more power (my opinion let's say) but there are a lot of different pieces to choose from and you have to choose a technology stack yourself. As an example, RoR has a standard way of accessing databases while .NET Mono let/force you to choose from a dozen different ways to do that.
Mono and .NET generally have a little better separation of concerns so the purist in you might like that. If not, you actually find the roll-up-your sleeves and get it done attitude of Ruby more to your liking.
Performance and Scalability: This should clearly go to .NET and Mono. In fact, I believe the fastest way to run Ruby-on-Rails is to use IronRuby to run it on .NET. StackOverflow is written in ASP.NET MVC and, given the amount of traffic, it obviously performs great. Proof is in the pudding. That said, the performance bottleneck will probably not be your choice of framework.
Testing: Old style ASP.NET (now called WebForms) is considered pretty hard to test. The newer ASP.NET MVC was designed to be easy to test and is similar to RoR. One major factor is that in Mono you will probably be using a statically typed language (like C#) while Ruby is of course a dynamically typed language. You have to write more tests in a dynamic language (because the compiler/interpreter will not catch type problems) but it can also be easier to write tests if you are not fighting the compiler. I think it is a matter of taste and style (I like static) but this is a major factor in answering this question.
Of course, since .NET/Mono is a multi-language platform, you could always write your ASP.NET MVC tests in a dynamic language. You could even do it in Ruby (IronRuby). Perhaps that would be the best of both worlds (static checking on your real code and flexible dynamism in your tests). I have considered doing this myself using IronPython for tests.
Maintenance and development: This is a tough one. It depends what you are writing, what third-party libraries you might need, and what tools you are going to use. I would say that RoR is probably the more advanced MVC framework. My own thoughts are that Ruby-on-Rails is probably a shade easier to write but a little bit harder to maintain.
Community: I like the Ruby community more than the .NET one but I think I like the Mono one the best. That makes it a little confusing. The core Mono guys (like Michael Hutchinson that answered here) are simply awesome. I really like MonoDevelop as a tool (IDE) as well. It just keeps getting better and better. Michael, thank you for Git support if you had anything to do with that. :-)
Tools: If you are writing for Mono you can use the whole universe of .NET tools (VisualStudio, ReSharper, Reflector, etc) so that is pretty hard to beat. That is assuming you develop on Windows of course. On Linux or Mac the tool of choice for Mono would be MonoDevelop. It supports version control, a software debugger, and NUnit tests right in the IDE and is completely cross-platform.
It seems like a lot of Ruby folks just use a simple text editor. This may just be because an IDE just does not have as much to offer a dynamic language as it does a static one. Here is a SO question on what people like for Ruby:
What Ruby IDE do you prefer?
EDIT: Just to make things confusing...there is another MVC framework for .NET/Mono that is even more like Ruby-on-Rails; MonoRail even has an implementation of ActiveRecord. MonoRail has actually been around longer than ASP.NET MVC but I would stick with ASP.NET MVC these days as that is where the future lies. ASP.NET MVC is open source by the way and ships with Mono out of the box (the actual Microsoft code).
I can speak more to Rails than Mono. RoR is pretty scalable these days with all of the cloud hosting services available. Web applications query data and render web pages using that data, which really isn't that big of a deal. Most performance issues are caused by database and schema design issues, not the web framework. Typically, database response times dwarf other portions of server processing. RoR is also very easy to test. Testing is a more natural part of development than in other languages that I use. When I started RoR programming I was used to the much more structured world of Java, and the more dynamic Rails won me over for web development.
Firstly, I work on MonoDevelop, a crossplatform IDE for Mono (including ASP.NET & ASP.NET MVC), so feel free to consider my answer biased, but hopefully it will be helpful anyway.
Performance: a decent JIT compiler (Mono) should be much faster than an interpreter (Ruby). But it depends on the programmer's skill too - well-written Ruby could be faster than really badly written C#. The libraries and database and caching mechanisms you use will be a big factor too, but these aren't fundamental to the languages/frameworks.
Scalability: AFAIK there is no magic bullet for web app scalability, and although I don't have practical experience in this field, here's some info I've picked up. It really depends on your database usage, how your session state is stored, and how caching is implemented. This isn't really fundamental to either framework - once you start scaling to multiple machines, you'll probably have many machines/processes for database servers, cache servers, message queues, frontends, servers for static content, etc. Likely only the frontends will be ASP.NET or ROR, and if they're stateless, you can simply clone them and handle the scalability problems on the backend.
Testing: I can't speak for Ruby, but ASP.NET MVC (but not vanilla ASP.NET) was designed to be easily testable using .NET testing tools such as NUnit (Mono's own unit tests use NUnit).
Maintenance and development: Again, I can't really speak for Ruby, but it's pretty much a given that it will be easiest to develop (at least initially) in the language & framework that the developer already has experience with. Also, .NET has some amazing development tools on Windows - Visual Studio, ReSharper, etc. - and there's a huge pool of experienced C# and ASP.NET developers you can hire, though few of them will know Linux/Mono.
Also, StackOverflow uses ASP.NET MVC :)
To introduce a little levity...
How about DOS on Dope: the last MVC web framework you will ever need?
There are of course a dizzying array of choices but another nice alternative is Django.
It is basically Ruby-on-Rails for Python so most of the comparisons of RoR vs. ASP.NET MVC would apply. Depending on what kind of site you are building, the really interesting feature of Django is the automatic admin interface.
If you need to be up and running quickly, I would go for RoR. Scaling rails is becoming easier with time and you have a big range of ruby runtime environments to choose from MRI 1.8, 1.9, REE 1.8, JRuby (run on java VM), Rubinius.
ASP.NET MVC is nice, but I still think it has some way to go before it offers the same speed of development as RoR.
I have plans to work on a website using mono and asp.net mvc.But i would like to know where anyone has actually used mono for reasonably big production environment.
Does Banshee count? F-Spot too is developed in Mono. These are probably the two most-cited examples of "large" Mono products. If you're specifically after web-sites developed in Mono, then I'm afraid I've no knowledge in that area.
My advice would be to do some testing yourself, it's not hard, and different apps will behave differently.
You can write your own simple test harness or use something like OpenSTA http://opensta.org
There's a few more links here: http://en.wikipedia.org/wiki/Load_testing
The thing to be mindful of is that Web apps scale out, not up (more servers, not bigger boxes), so if Mono performance is 2/3rds that of a Windows server it may still be the better option in the long run. For example, Windows Web Server licenses are around $500. If a server is about $1000 that means the cost of 3 Mono servers = the cost of 2 Windows Servers.
I would say that website with "big" traffic could be http://www.orionsbelt.eu/ which is running on mono and nginx. However I doubt that they have 1M page views per month or anything close to that.
There are other companies using mono on heavy load stuff (not web related though), for example Second Life. IMHO lack of websites with big traffic running on mono is not the problem of mono itself, but it's rather related with successful business idea which may cause heavy usage of someones website.
Are you expecting to get that kind of traffic? Congratulations.
I do not know of any website with that much traffic using Mono but here are a couple of considerations:
The most similar load scenario might be seen by the Plastic Source Code Management tool since in that model you have a central server processing the load from distributed clients. I do not believe that they have run into any reliability issues with Mono. You could ask them about Mono under load though.
The ASP.NET MVC implementation in Mono uses the actual Microsoft code since MVC was released as Open Source. The ASP.NET implementation in Mono has been solid for a while and is really pretty mature.
Most websites are IO limited which means that Mono is unlikely to be the limiting factor. Mono is slower than .NET but for most stuff it is in the same ballpark. The GC is certainly less efficient though.
You can load test Mono yourself. In my experience, it stands up just fine.
I need to create a site that interact with some windows applications.
Currently this is done through direct calls so I would like these to run on the webserver.
This means that the site will have to run on a Windows based system.
I have been doing some ruby lately and am very keen on using rails for the site, but have at the same time seen plenty of discouraging posts regarding this.
Should I rather use ASP.NET (MVC) for a windows system or is rails stable enough to handle this?
Ruby on Rails on Windows is not ideal, but it does work, and works just fine for most purposes. The biggest issue you will likely run into is that the community of people running RoR on Windows is very small, so the issues you do run into which are specific to RoR+Windows may be harder to get help on.
If leveraging existing community is very important to you and/or your project, then I do recommend going with ASP.NET MVC. The community there is much larger and easier to connect with than RoR+Windows, which is fairly niche. Although it's difficult to put an objective value on the added benefit of having a community of support, it's clearly one of the biggest selling points for any platform - the RoR community in general, for example, is a huge part of its continuing success.
I would add to Rex's answer that RoR+Windows is fine for development, but i would not use that as a production setup. In my case i do a lot of work in Flash/Flex/Photoshop while working on the backend at the same time, and of course running those graphics heavy apps on Linux is not very ideal, but the server i deploy to is Linux which is the only part that really matters.