As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been waging a bit of a battle with MVC recently, trying to get it deployed and working correctly on my web host server. While the host (ixwebhosting) has been very prompt and efficient at resolving some of the technical difficulties, I'm still encountering odd behaviours around getting the views to render.
Specific issues I've struck so far are the application not being recognised at all (returning 404) and individual views returning 404s.
Is this typical of other peoples' experience when trying to deploy to a hosted environment or am I just a bit green in this department?
Should I consider falling back to web forms until MVC matures a bit more?
(...) views returning 404s (...)
Actually, some of the problems you've been having may be related to some confusions you are having regarding MVC on the web. For example, a View in web MVC is a presentational unit handed back by the controller to the client. The same View can be used for many resources and action methods. These action methods, in turn, can also return 404s. The ASP.NET MVC tutorials on ASP.NET are good starting points for getting to know MVC.
I thought getting ASP.NET MVC to run on IIS6 would be a hassle, but I had zero problems after following the normal installation guidelines. Even special cases where IIS is involved (caching, redirecting, static content etc) has worked fine on IIS6. On IIS7, of course, there are no issues.
I clicked the Publish option and waited until the site got uploaded via FTP. After that everything worked fine.
ASP.Net MVC is an extension to the .net framework, it is a separate install (at least until .net 4.0).
Does your hosting environment have ASP.Net MVC installed?
It could also be that you are having problems with the routing, therefore a URL is giving a 404 (file not found), because it cannot match a route to the url.
Are the URL's different in your hosting environment?
Are there specific issues you are having?
My personal experience: an ISP that can't support 301 redirects under ASP.NET MVC. But that's not MVC's fault; the ISP just hasn't caught up yet. They are still running IIS6, and ASP.NET MVC is better (less problematic) under IIS7.
MVC 1.0 is stable and mature enough for production applications. I also use elements from MVCContrib (i.e. RenderAction) without problems.
I recently hosted on GoDaddy w/out (any) issues at all! I simply published the site and uploaded it via FileZilla.
I even have a DB and that was no issues what so ever.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been in some discussions lately and the talk is about moving over to ASP.NET MVC and Knockout for future work on a product that is currently ASP.NET web forms. This product has many of the characteristics of the general current definition of a SPA.
I've never quite seen how MVC actually fits in when you start generating all your views with JS view models which get their data from calls to JSON web services.
Is there a "sweet spot" that leverages the best parts of Knockout w/JS models and JSON and the MVC framework?
Here are some things that I've been thinking about this (a little random - just seeing if I can spur on some discussion/answers):
When would you use Knockout vs. Razor? Knockout generates the view elements at run time on the client browser. Razor runs as part of the server request before the client receives the response. Are there times that one is clearly better than the other or does it come down to personal taste?
Is there value in keeping more code under the guise of C#/Razor for the purpose of code completion? Also, when exceptions get thrown, stack tracing to compiled code seems easier than JS debugging.
Is it better to completely separate the view from the back-end by creating a blank ASP.NET application and an independent Web API project?
Lots of great questions, I'll share some of my thoughts on the subjects. (Questions have been paraphrased):
1) Is there a place for MVC in a Knockout world? - Absolutely. MVC is a lot more than just Razor. Server side routing, Areas, Authentication, and more, are all provided by MVC. So in my mind, I can still use MVC for all the "admin and organization" but still have all my Views be primarily (but not necessarily completely) AJAX driven. I have discussed using MVC and KO together on SO before. I also have a video dedicated to that topic at WintellectNOW dot com.
2) When should I use Razor? - Let's actually switch up the terminology. It really isn't about Razor vs. Knockout: it's really about server-side vs. client-side rendering.
So when should you use server-side rendering? One ideal time for this is when you are loading data that only has to be done once when the page is initialized. For example, if you have a list of States for a drop down, and that list is extremely unlikely to change, go ahead and load that on the server side. Why turn around and make another request back to an API in that case? I would reserve those calls for dynamic or context sensitive data.
3) Is there value in keeping more code in C# for tooling purposes? - IMHO, no. It's true that debugging JS can be painful, but that is not enough justification for me to disregard all the awesome things I can do client side. It's worth the occasional frustration to provide a better user experience.
4) Should I move Web API to a different project to keep the code separate. - It completely depends on the needs of the project. If the Web API project is going to service multiple applications, then YES it should be in a separate project. That will also put it on a separate DOMAIN, SUB, PORT, or something to differentiate it from the rest of the Web app. Doing so introduces Cross Origin Resources Sharing (CORS) issues. CORS is a particular hell I wouldn't go through unless absolutely necessary. If your Web API is only going to service your single web app, do yourself a favor and keep it in the same project.
As with everything else, a lot of this comes down to personal preference. Mine is to use Server side for managing the bigger picture of my app, and client side for all the UI/UX.
I am using legacy DNN (CMS + its portal capabilities, though CMS capabilities are not that important, its portal capabilities are used extensively) to build web apps. Am looking to move into ASP.net MVC3, but am wondering if there are any frameworks which gives me the same portal capabilities as DNN while using ASP.net MVC3.
At the risk of being ridiculous, a simpler way to frame the above question would "how can we use ASP.net MVC3 to build a portal based application like stackoverflow/stackexchange".
I tried best to find answers to this question in meta.stackoverflow, but could not.
These are the meta questions I went thru, to find answers (mentioning here to say that I did my homework before asking this question)
https://meta.stackexchange.com/questions/55725/does-stackexchange-2-0-share-the-same-codebase-with-so
http://blog.serverfault.com/2011/02/11/stack-exchanges-architecture-in-bullet-points/
I am posting this question in SO and not in meta.stackexchange, because I am looking for building portal based webapps with MVC3. Stackoverflow/stackexchange happens to be one (well known) implementation, there can be other implementations as well.
Edit: I also saw http://code.google.com/p/stacked/, but it does not directly address my "mvc portal" part of the question
A good place to start might be the Orchard project:
http://docs.orchardproject.net/Documentation/frequently-asked-questions
There are at least 3 projects I am aware that are open source SO type projects:
2 are non asp.net
There is Stacked while Phil made a HaackedOverflow project though I have never seen source code for it.
Umbraco V5.O is based on MVC - not sure, unfortunately, what that means exactly in terms of how it affects how you develop.
Also, as of this answer, its just heading into beta
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
With the release of ASP.NET MVC 3, I am wondering what are the major reasons (killer features) we should upgrade our app to MVC3.
Our app is currently in MVC2 using:
Ninject & Ninject.Web for IoC,
Linq to Sql
jQuery (no ASP.NET Ajax)
flot charts.
MVC Contrib
Custom REST (through dynamic WCF no XML config files)
We do not use ASP.NET charts or EF etc.
Is there any real compelling reason we should upgrade to ASP.NET MVC 3?
Here's a few additional features in ASP.NET MVC 3
Razor view engine (Widely seen as a vast improvement on the previous ASPX view engine)
Improved model validation with unobtrusive JavaScript and jQuery support. Including new remote validation amoungst others
Partial page output caching.
Dependency Injection Improvements, new IDependencyResolver`
More imporvements and details can be found at ASP.NET MVC site along with Scott Guthrie's anouncment
But only you can evaluate whether you should upgrade or not for your specific project.
It should be noted (as Robert Koritnik commented) that MVC 3 requires .NET 4.
No more custom controller factory! This will apply to you. They wrote a new IDependencyResolver that you implement and DependencyResolver.SetResolver(...). Your IoC will go through out the application.
http://weblogs.asp.net/shijuvarghese/archive/2011/01/21/dependency-injection-in-asp-net-mvc-3-using-dependencyresolver-and-controlleractivator.aspx
The main two reasons we're about to upgrade are:
1) The ability to control HTML validation on a per textbox basis rather than on a whole page- this means we can allow the users to enter HTML into some textboxes on a page, rather than having to control it at the page level.
2) Remote validation - much less ajax for us to write!
1 Razor
2 Razor Intellisense within Visual Studio
3 Partial Page Output Caching
4 Validation and JavaScript/AJAX improvements
The Razor View Engine will make your view code nicer.
More details here
Apart from all the answers there are few other reason for adopting MVC 3
Unobtrusive Javascript
Global Action Filters
Custom Validation attributes and Self validation
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I find myself on the edge of trying out ASP.NET MVC but there is still "something" holding me back. Are you still waiting to try it, and if so, why? If you finally decided to use it, what helped you get over your hesitation?
I'm not worried about it from a technical point of view; I know the pros and cons of web forms vs ASP.NET MVC. My concerns are more on the practical side.
Will Microsoft continue to support ASP.NET MVC if they don't reach some critical threshold of developers/customers using it?
Are customers willing to try ASP.NET MVC? Have you had to convince a customer to use it? How did that go?
Are there major sites using ASP.NET MVC (besides SO)? Could you provide links if you have them?
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
If you have any other concerns preventing you from using ASP.NET MVC, what are they?
If you had concerns but felt they were addressed and now use ASP.NET MVC, could you list them as well?
Will Microsoft continue to support ASP.NET MVC if they don't reach some critical threshold of developers/customers using it?
They will for sure.
Are customers willing to try ASP.NET MVC? Have you had to convince a customer to use it? How did that go?
Customers care about high quality products and price. Just convince them that Mvc will help to raise quality and lower price. Shouldn't be hard.
Are there major sites using ASP.NET MVC (besides SO)? Could you provide links if you have them?
Isn't it enough with SO? :)
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
I did try and didn't regret it at all. It kills me being forced to work on web forms project again.
Go for it!
I believe ASP.NET MVC has reached that critical threshold, as evident by VS 2010 tooling, ASP.NET, MS employee blog and the extensive effort Microsoft put into the framework thus far. I don't see this framework perishing in the next decade (or two).
By customers, I assume you mean people that I build websites for? The only issue I find with ASP.NET is the hosting solutions. However, this issue is becoming moot as more affordable hosting solutions are found. But usually, if I believe in the technology and that it will work for my customer, my customer trusts me and agrees on it. The customer is also usually comforted by the fact that ASP.NET-MVC is a Microsoft product. Having a big company behind a technology is always a nice thing to have, since you can rest assured it will be supported for quite awhile with frequent updates.
ASP.NET MVC is a relatively new framework, and slow adoption of new technology is expected. But this is what I found: http://weblogs.asp.net/mikebosch/archive/2008/05/05/gallery-of-live-asp-net-mvc-sites.aspx . I think you'll see a big influx of websites using ASP.NET-MVC this year when VS 2010/.NET 4 are released with built-in support for ASP.NET MVC.
I never enjoyed developing with C#/ASP.NET more than when I started using ASP.NET-MVC. To a certain extent, ASP.NET-MVC forces you to write good code more so than WebForms due to ASP.NET-MVC inherit separation of concerns and easy customization. And the ability to control HTML output is essential, a feature that was difficult with ASP.NET-WebForms (pre 4.0).
I use MVC and hate it, especially, the front end, web form are far more better in the front end... With loads of javacript on the page, that means it is hard to maintain and take a longer time to develop and debug..
To do a very complicated page, the flexibility of MVC is limited, you will end up with using a lot of javascript control, and you know what? Different controls use different version of jquery, and they have conflict..
It is actually the javascript, and lack of UI flexibility that pulls me off, especially you are NOT working on your code
and we have more issues of browser compatability, with the new browsers coming, you are going to shoot yourself with MVC
MVC front end is very fast if your web site is not too big.. The backend of MVC is very good, it is the front end that blows it over
Why not? The rest of my team doesn't want to.
I have not yet actually tried coding up some ASP.Net MVC(looked at a few examples though) but the main thing holding us back from using it is that all of our code is currently written using Webforms.
Regarding Microsoft support ASP.Net. First Scott Guthrie, the VP of Development at MS is behind it, so that's one feather in its cap. Second its open source now so even if for some strange reason MS decides not to support it going forward you can still tweak it on your own if you need to. In addtion the MVC pattern is somethign that more and more web development platforms are using. It is a great pattern for web development and as a result I can't think of any reason MS wouldn't continue to support it.
If by customers you mean end users, honestly they shouldn't care how you implement the site. If by customers you mean consulting clients, if you can develop faster and they have the servers that can host it, I would think they would be open to it. On top of that youre MVC sites should use less bandwidth than a typical Web Forms web site (IMHO) mainly because there is a lot of additional stuff put into a Web Forms page (for example extra attributes in the HTML htat are tailored for web forms, ViewState) so that should be seen as a positive by them. Now if by customers you mean people integrating with you, then its also a plus since MVC makes it very easy to implement REST based web services (not that WFC doesn't but MVC works very nicely as well).
Hmm major sites using MVC, so far I've found a list here I also know of a number of apps at different companies where large scale MVC apps are in development. I wish I could give more detail, but unfortuantely I can't at the moment.
When I first started out with ASP.Net MVC I thought I was going to hate it. I wasn't a huge fan of Web Forms either, but MVC just felt like a step back to ASP development back before .Net came out. Then I started really getting into it and really finding the pattern is clean, concise, extensible, maintainable, and easy to pick up. Honestly I don't want to ever go back to Web Forms, and anytime I find myself doing a .Net web app I make a point of making it an MVC project.
You need to choose what's more appropriate to your product. Webforms has a few things to recommend it over mvc in some situations.
The big one is a developer working on in-house tools at small to medium shops. In these circumstances:
Large viewstates are not likely to be a problem, because your users typically have 100Mbit upload to your web server rather than a measly 128Kbit or less.
Javascript is likley to be supported by everyone
Development time matters more than widespread cross-browser compatibility or even nice design.
You're likely stuck working with inherited devs who used to do desktop/forms style development, or have a lot of churn among junior devs who don't really know web development.
All of those things together mean that webforms is still a very good fit. And let's be honest: a lot more programmers work at these small to medium in-house shops than do public internet work. So webforms isn't going anywhere.
That said, one of the big things coming up among these small shops is likely to be taking their internal tools and making them available offsite for telecommuters. In that situation, you need to start worrying more about WAN performance odd browser issues where MVC might be a better fit.
Dell is hiring masses of ASP.NET MVC developers in Texas and India for major work on many of their websites.
According to The Gu, ASP.NET MVC will have it's own product and development cycle. It is now 100% detached from ASP.NET WebForms and it's not going away.
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
I do not regret trying out MVC in fact I love it. When I started it out I hated it I kept looking for the code behind file and was unsure at first how to get values out textboxes and stuff without going textbox1.Text;
Now I cringe every time I go back to webforms and wish I could write it in ASP.NET MVC because I just love how your working with html instead of using drag and drop controls that usually make your life alot harder if you got to customize them to much. I love how ASP.NET MVC likes to focus on good code like design patterns such as the Repository pattern and how to do unit test using TDD.
I have not picked up a book yet in MVC where they talked about how to make good code. I am not saying you can't write good code in Webforms but in the books and classes that I seen teach ASP.NET this never seems to be a main focus.
Like for instance I hate the datasource controls I am tutoring some people in WebForms and they love to drag a datasource in and then write their SQL statements in that datasource. Then in the code behind they use these datasorces to insert their records.
So every time they need to make a new SQL query a new datsource is dragged on and made. So now you all your logic is all mixed together. It makes it so much harder to find out whats going on, switch to different things if needed then of course it is limiting.
Something that revolves around the name "controller" can only mean problems.
I tried following the Nerddinner http://www.asp.net/mVC/ tutorial this morning. I'm comfortable in webforms, but nothing in that nerddinner tutorial made sense, just an outdated, hardcoded recipe from mvc1.0 that dosent even compile with the current mvc2.0, probably Wrox made this tutorial, only they can come up with only formating and no content.
I didn't see anything in there that was good; a bunch of hardcoded conventions I didn't need.
I certainly didn't see anything in there that would make me say I'd want to move from webforms, although this seems to be all the propaganda I read.
They put this tutorial based around wizards, on http://www.asp.net/mVC/ main page, while claiming the model is lean, all of it is generated code they don't explain, the default mvc template project has something like 15 references.
This 2 page website managed to be slow to build and to load.
Was 30 minutes in it until I realized my data model didn't match the one from the tutorial and many things that had been generated using the create controller and create view wizards were now failing.
With what I was provided in the rushed tutorial, I wasn't able to recover the project. I'll just pass until I find better documentation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Is it ready for that?
I've been playing with it for a short amount of time and it seems quite reasonable. Is anyone using it for live sites?
any issues to be aware of?
Well, stackoverflow.com is.
Yes, this one.
Yes, www.jobtree.com.au is. I also have another new site coming online in the next few days www.afterkickoff.com/football that is using it.
http://weblogs.asp.net/mikebosch/archive/2008/05/05/gallery-of-live-asp-net-mvc-sites.aspx
We are using it on Birmingham Museum and Art Gallery's Pre-Raphaelite collection online and we are really happy with the results. Also using Silverlight deepzoom which we customised..
I think StackOverflow, itself, is built on ASP.NET MVC. Just read this: http://haacked.com/archive/2008/09/15/stackoverflow-at-pdc.aspx
You should take a look at how to make ASP.NET MVC work on the specific version of IIS your're planning to use. There's a whole page on the topic (Using ASP.NET MVC with Different Versions of IIS) on http://www.asp.net/learn/mvc/tutorial-08-vb.aspx
I've been using ASP.NET MVC in production on several sites since Preview 2, and it has got progressively better with each release.
One issue to be aware of with the latest release (Preview 5) is that there is a bug in the VirtualPathProviderViewEngine that can cause the wrong view to be rendered if you run in production mode (with <compilation debug="false" />). See this post on the MVC forums for more info.
Remember that asp.net MVC is built on top of a solid asp.net/.net foundation which is already well proven and you can mix the technologies if you choose. I've used it without any problems besides the learning curve.
My only note is that currently, 3rd party control vendors like Telerik, ComponentArt etc don't really work well with MVC.
Stackoverflow uses ASP.Net MVC. Seems to be doing pretty well here from my experience with the site.
I don't have any completed sites written in ASP.NET MVC, but I have one in the works and a few others in mind that would be ideal in MVC.
The product is solid and you can expect to continue to see development in the coming months. The only concern you should be aware of is that the code is likely going to change. Though I'm sure that it's starting to stabilize, you should expect to update your code to accommodate those changes.
Yeah we recently finished a site with MonoRail and have our own proprietary MVC framework for content generation too.
We just deployed www.homespothq.com using ASP.NET MVC. I am very pleased with how it is working.
I'm using ASP.NET-MVC on a high volume private site and it has performed quite well. The separation of components with this architectural approach is very appealing.