I was listening to a recent stack exchange podcast episode 11 and sometime during it Joel stated that ASP.Net was officially no longer supported by mono.
I've been looking around and haven't been able to find anything officially stating this.
Mailing list still seems active
XSP has commits as recent as July 6
Is asp.net support(or active core team development) actually stopping or was that statement inaccurate?
Perhaps this was related to Attachmate laying off all the Mono developers? Luckily that issue has been resolved.
ASP.NET is still actively developed, especially ASP.NET MVC 3. Don't know why Joel stated this.
Related
So begins from 0.75.1, Rebus no longer supports ASP.NET 4?
My question will be:
Is 0.75 a stable release for .NET 4 project?
Are we going to continue get bug fixes (if any) for .NET 4 target project?
Thanks
As of 0.75 Rebus has targeted .NET 4.5, which was a requirement to support the usage of async/await in the library.
I'm not an expert on ASP.NET and whether the version follow the versions of .NET, but Rebus will work as long as your host process targets (at least) version 4.5 of the framework. If ASP.NET 4 is only available for projects that target .NET 4, then that implies that you cannot use versions > 0.72 of Rebus.
And then an answer to your questions:
You should pick the latest version of Rebus, but that requires that you target (at least) .NET 4.5. If that is not an option, you should pick Rebus 0.72 (which is the last version available that targets .NET 4).
No (*)
As for the (*) above, I'd like to make the following fairly long and elaborate point: Generally, you can't count on getting bug fixes for the free, open-source software you have downloaded and are using, freely, without having paid a cent - at all!
If you want to be able to reliably count on getting bug fixes for your free software, I suggest you get a support contract with a company that is willing to provide that service. My employer provides that service for Rebus in case you're interested.
With that said, I'll add that I am a pretty helpful person, and I do a lot for people to have a nice experience with Rebus, but I am sure that you can understand that I cannot promise to provide bug fixes for the old versions.
I will be around for helpful advice if you run into something, but - as I am developing Rebus mostly in my spare time - you can probably understand why I need to concentrate my efforts on the current version.
I've started your typical web project from scratch using the Mono platform. You know, web services, a UI, MySQL database, all that. I've heard around the net that it's not a picture-perfect implementation of the .Net platform, but so far I can't find anything it's not good at. I see the odd "Not Implemented" pop up in intellesense, but haven't run into any snags or dead ends.
Have you hit a brick wall with a .Net feature that's not implemented in Mono?
From my understanding, the guys working on Mono have pretty much feature completed their version of ASP.NET 2.0. Now I know they have been working on getting the .NET 3.5 things like LINQ and such implimented, but I'm not too sure how far they've gotten with that. I do know that working the desktop has been a little more difficult and they've been working to get a few of the desktop specific namespaces worked out like System.Windows.Forms.
Here is an article that dives a little bit deeper into the whole Mono setup. It's a little old, but has a lot of code and descriptions to digest.
Good luck, and hope Mono works out for your project.
License is a problem, noncompacting GC is another problem, there is no WPF, WF, Entity Framework, has only basic WCF, MonoDevelop has a long way to race with Eclipse/VS.Net, mod_mono isn't stable or perfect as tomcat/IIS, I couldn't find any high traffic site using it...but, You probably will not face with a serious problem, if your project isn't enterprise level. C# is probably the best architected language ever and evolving fast. .Net framework is far better than jdk in my opinion and mono people working hard, but there are other problems as I said; another choice is Java. Java has the mature / rack-solid state of art projects like Terracotta, Hibernate (ported to .net), Ehcache, Compass,... but some people say that Sun is out of money and Java isn't evolving for years (as a language) so began to die,...
I think the most important thing is finishing the job done right and on time. Select the technology which you know best and like most and don't waste your time by looking back. It'll be not a problem until your project grows too much.
Cheers,
I am preparing to start on a new short-term contract (1-2 months) that involves replacing an Access application by moving it to ASP.NET and SQL Server.
I am only responsible for the ASP part and connecting it to the database.
The only requirement is that whatever technologies I use be relatively well-known in the area, so that if they need to have someone else work on it, it isn't specialized knowledge.
So, I could do this in Rails or ASP.NET, but, when should the development be aiming for .NET 4 Framework, as there are many changes coming out that may be advantageous to use.
Or, even though it may be useful, when is it better to just ignore new features and stay on an older version of .NET?
I am assuming that hardware isn't the limitation, as many computers won't be able to run .NET 4 Framework, but that would be an issue for a hosting company, as they can find a hosting company to support whichever framework the application is designed for. If Rails makes the most sense, as their hope is to have the application written quickly, but have it reliable, then again, the hosting company would need to support it, or they use a different one.
This company hasn't used a hosting company, they need to find one, so there isn't a relationship that could be an issue.
UPDATE: Part of my concern is that initially the application will not require javascript, but phase 2 will be to make it more interactive, as some clients won't be allowed to have javascript on their computers. In order to limit how much javascript must be known by a developer there are frameworks that will adapt to browsers and situations fairly well, which is why I am also thinking about RoR and the fact that there appears to be changes coming out in .NET 4 that may help with this.
As a general rule of thumb, I wait one year before building sites in a new framework unless the client specifically asks for the newest technology. This has worked out very well for me. The advantages are:
The technology is much more stable (hotfixes, service packs, etc.)
Common complaints about missing functionality are usually resolved
Hosting companies, support communities and corporate IT departments have had time to get used to the technology, find out more about it, play around with it and have it mature within their organization
Unless there is specific need for new functionality introduced by .Net 4, there is no point in subjecting your clients to the immediate problems with an initial release, or making it more difficult for them to find hosting. You should either investigate all of this up-front, or use .Net 3.5 in the meantime.
The only requirement is that whatever
technologies I use that it be
relatively well-known in the area, so
that if they need to have someone else
work on it, it isn't specialized
knowledge.
I would have thought that requirement was enough not to develop this project on .NET 4.0 - it takes time for a new framework version to filter down into the market, and it will be a while yet before there are a lot of developers around with .NET 4.0 experience.
Also, you would be essentially developing on top of a BETA product - while I'm sure most of the features will remain unbroken from BETA -> RTM, there is always a risk that something will break or not work like it did in BETA, so why risk this on a commercial project?
I wouldn't target .NET 4.0 yet on a commercial project unless there was a specific reason for doing so, and even then you would have to have buy-in from the client, ie "I can do this much more quickly and with less effort if we use the current beta version X rather than established, stable version Y" - good luck with that.
I worked on a commercial project that used the CTP version of LINQ to SQL - then when we went to VS2008 / 3.5, suddenly everything changed and we had to make a lot of changes just to get LINQ to SQL working again.
Stick with 3.5 - it's easier for hosting and getting developers.
Just a couple of thoughts, I wouldn't even think about creating an application for production use in .NET 4/ASP.NET 4 until:
There is a release candidate. It's
not the first time I've seen
features in beta's not make it to
RC/RTM.
Microsoft have permitted development and deployment
of production applications by way of a 'Go
Live' license.
There are some hosters out in the market such as OrcsWeb who are participating in public beta testing, but they aren't intended for production use.
I'd run with the .NET 3.5/ASP.NET 2.0 or MVC bits for now. Better safe than sorry.
Generally speaking it's going to be easier finding hosting for a Rails app. If you want to run .net 4.0 you're probably going to have to run a VPS or dedicated machine. However if you're bailing after the application is finished and assuming your client is in Knoxville, they're going to have a tougher time finding a Rails developer to maintain the application.
I think the bigger question is your role. They're looking to you to solve this problem for them. Are you productive in both technologies? How about getting a Windows server up and running? A Linux server? How's your SQL Server vs MySql? I'd guess that you're probably stronger on one stack vs the other - for a contract that short I wouldn't want to be doing a lot of experimental development.
i wait until the OS that everyone will be using has it.
Just last month i took a dependancy on GDI+, which first shipped with Windows XP.
I'm trying to do an informal feasibility study for work on if Mono/Apache/Linux is realistically 'ready' and in any way comparable to a more traditional .NET/IIS/Windows stack.
Any comparison of performance would be helpful too.
Take a look at companies using Mono.
It even says that Wikipedia uses Mono for its search facilities.
http://Fiducial.Biz, a financial company in France is running on Mono with ASP.NET
We're running a website/bunch of webservices on Mono/Apache/FreeBSD platform for one of our customers. The setup works great.
One thing to remember is 2.0 of Mono is out soon (I think this week) and it is even better now. So if you do any testing make sure you at least use the 2.0 RC
I am running a couple sites off ASP.NET over Mono. I am targeting 2.0 of the framework.
I haven't had Digg numbers, but I have also never had an issue.
Has anyone built a website with IronPython and ASP.NET. What were your experiences and is the combination ready for prime-time?
The current version of ASP.NET integration for IronPython is not very up-to-date and is more of a "proof-of-concept." I don't think I'd build a production website based on it.
Edit:: I have a very high level of expectation for how things like this should work, and might setting the bar a little high. Maybe you should take what's in "ASP.NET Futures", write a test application for it and see how it works for you. If you're successful, I'd like to hear about it. Otherwise, I think there should be a newer CTP of this in the next six months.
(I'm a developer on IronPython and IronRuby.)
Edit 2: Since I originally posted this, a newer version has been released.
Check out the Dynamic Languages in ASP.NET page on Codeplex. This has the newest IronPython bits. It doesn't give you any Visual Studio integration, other than the sample website project, but that's coming.
Keep a look out for ASP.NET MVC
The IronRuby guys have got some internal builds of MVC to work with IronRuby, and IronPython 2 and IronRuby have a lot of code in common with the DLR.
I'm not sure if they'll support IronPython/IronRuby when MVC is released, but it's definitely worth keeping your eye on anyway - The old ASP.NET forms-based development model is old, busted, and the sooner it goes away the better.