I have an application that I want to (eventually) convert to ASP.NET MVC. I want to do an all out service upgrade (to ASP.NET) but want to use current asp stuff to run the current functionality so I can upgrade small pieces while making incremental upgrades to the new framework. This site is heavily dependent on a VB6 DLL that is not very mature, so we will also want to upgrade this eventually too, potentially replacing the current functionality with web services. Is there a quick fix or is this task a 3 month + task? Also, I am sure it has been thought of before, the beauty of the MVC is that I would think there is a way to tackle this, though I am unsure of where to start. What would be the quickest way to convert this application (in 40 or so hours), where I can just make small configuration changes and have this working in ASP.NET MVC?
The short answer is... You can't. The differences between classic asp and asp.net are fairly drastic not just in syntax but in overall design. MVC is not just a similar implementation to classic asp although it may look that way. Any conversion will take time, thought and effort to get it completely working.
The good news though, is that you can run them SxS so you can actually have classic asp code running under a site that is setup as an ASP.NET or ASP.NET MVC site. So with some duct tape you can peice together your upgraded solution part by part.
Rewrite your VB6 DLL as a COM callable .NET assembly. Then, you can reference it both from ASP and ASP.NET.
Hopefully, most of the heavy lifting is in the VB6 DLLs. If so, you can then start migrating pages over to ASP.NET MVC as you want. You have to watch out for page-to-page communication - things like Session and Cookies. Cookies will pretty much work as is, but you'll need to move Session to something shareable between MVC and ASP like Sql Server. Unfortunately, that requires rewriting your Session calls in ASP to something else (possibly a COM wrapper around a .NET component again). Search and replace should do the trick, though.
As for the timeline and amount of work this entails - that's pretty context dependent on the amount of spaghetti in your existing app, how much logic is in the DLL vs. ASP, and how many pages you're migrating.
I don't think 40 hours is a reasonable amount of time to get up to speed with .NET, MVC, and rewrite - though I think 2-3 months could be.
I have been working on a similar project for quite some time now; We had a classic ASP app and wanted to move it to ASP.Net (using WebForms). We do it a piece at a time, if we are adding a new page we do it in .Net and just redirect the user between the .asp files and .aspx files. Working with MVC should be no different.
The biggest issue we ran into was security; The site required a log in and the session is of course not shared between the two. We handled this by persisting the bits of session we cared about to a table in a database and passing a GUID through the query string (we only do this one time at login, then delete the record from the database to reduce security risks).
Related
We are currently considering moving from ASP.NET MVC to Angular 5, mostly because it seems like the best and latest framework. However none of us seems to be able to come up with hard reasons on why Angular is better than MVC (Razor).
SPA vs MPA seems like different approaches with neither really being better - just better at different things.
Are there any resources/comparisons with hard benefits between the two?
Update: Almost 2 years after moving to Angular 4 (currently 7) I can say that it was a great decision. Angular makes it super easy to write quite complex front-end applications and the tooling around Angular itself, TypeScript, Karma + Jasmine (unit test frameworks) is fantastic. SPA is a huge step ahead of MPA in my opinion - we can finally have fluid web experience. I never really liked Razor and the whole mess around ajax/jquery, but I can comfortably say that I am really enjoying my time now! .NET CORE 3 + Angular 7 gives us everything we need!
To anyone thinking of taking the plunge, I would strongly recommend Angular (might as well start with 8 or 9, which is current at the time of writing this).
Happy to add more details if people want them :)
6 months on from moving from ASP.NET MVC to Angular 5 (now 6) and we are extremely happy with the decision. .NET core backend and Angular frontend is a fantastic combination. It is so much cleaner and easier to create re-usable, strongly-typed, testable and easy to modify UI components!
For anyone considering if it's worth taking the plunge - I would say a resounding 'yes'!
I don't have enough points to make a comment but thought the following might help you in making a decision.
Just to note that if you use Angular CLI (The default Angular project in Visual Studio) you will lose the ability to use razor within the HTML. Something you was able to do before Angular CLI.
I do like using Angular but miss having Razor to omit certain parts of the HTML, for example, if the user didn't have the necessary roles or permissions:
#if(User.IsInRole("Admin"))
{
}
You can hide the HTML using Angular of course, but having it completely removed from the HTML itself is preferable in my opinion.
I vote for an ASP.Net MVC Web Application in the cloud [Core or whichever] , and use of razor pages as needed. That is it. Case closed.
Even if the whole world runs after Angular , Aurelia, React, Node, Strawberry, Pistachio, butterscotch JS, I will not.
After all, JavaScript is spagetti and Angular is the Flying Spagetti Monster
based on personal experience and intuitive take.
Now please don't get started about mouse hover over page areas,
What I did found out about Angular vs MVC (Razor), I can work with both :-)
Authorization: One thing to make sure is that you don't have complex authorization schemes. On the backend its easy to do your authorization on pages with Razor (even more with Core). Its more difficult to handle authorization with Angular because you will have to do it (and keep in sync) on both sides: client and server. Example: One thing you want is hide everything a user is not allowed to do. If you have a simple webapp and use a Masterpage: show only the menu items a user is allowed to see. Thats a very easy task to do in Razor. It takes more time/effort to implement this in Angular.
Templates: Razor is extremely easy to use with templates. If you develop a website that must be used a number of times but with different layouts that can be done very easily with Razor.
Maintenance: With MVC you have one application. The frontend and backend are one. For maintenance you will have a Angular frontend and X Backend, so two. That seems more costly from installation, maintenance, etc. point. If you have a simple application I would say KISS: Keep It Simple Suckers.
One: In MVC the frontend and backend belong together. That can be good or bad. If you have one application with no dependencies on other things I think MVC is a good choice.
Future proof: Angular is NO W3C and NOT baked in the browser. Because of Future proof solutions there is a strong interest in Vanilla Javascript together with Web Components. With MVC you can use this technology. Read about Microsoft FAST Design. It works great with MVC.
SPA/MPA: Thats not a point anymore. An MPA can also be flicker-free with libraries like PJAX etc.
Speed: With MVC no wait time because Shit has to be loaded. Enough bad Angular websites already exists because loading takes ages.
...: After working with Angular 9 I don't get the point of Angular. I don't know why you should go from MVC to Angular. Visual Studio has great support for MVC and is much better as VS Code. From productivity point I can produce much faster code with MVC as with Angular. If you have multiple front ends that must connect to the same backend may be then I can see the point. But even then MVC can be moduled and even can dynamically load them.
htmx Wow, now we are talking! Yes this is what we want. Let Html take back control how pages are loaded. Think this is the way to go. Worked a sample with NodeJS and are very exited about it.
Update: I just did a nodejs/express/mongodb project and it beats it all. I am an expert mvc developer, but developing faster, better on a chromebook of 220e with vs code. now I know why it's so popular. and guess what? it's free. and guess what else? part of dotnet Core is based on nodejs. the console app is the same as a nodejs server. both you will have to put behind a proxy of IIS, Apache or NGINX.
One thing that I learnt during the comparison of MVC and Angular, among various factors, is that hosting MVC application requires a compute power container like Azure Web App, docker etc, while an Angular App can be deployed in any storage like Blob, CDN etc. When Angular is built, it gives a collection of javascript files, which are perfect candidate for storage container. They do not need compute power at all, which are the most costly resource in cloud world. CDN or Blob exposes Rest API endpoint to any of its underlying resource. So, the Angular will also be exposed as an API, which is all we want.
However, angular alone will not generate dynamic web pages. We need Web-Api at back-end to give the data. This can be achieved by a server-less solution (Function Apps, Logic Apps etc) or by containerization (Docker).
One downside that I personally found that the first time load of the Page in Angular is bit slow. After that it is really smooth.
All in all, I will vote for Angular/React and .Net Core in my future Web projects.
I have a coursework which requires me to do the following :
Make a website which can retrieve data from application db
Create three data repositories (two as application db and one as data warehouse)
Ensure that the two application db can sync their data with the data warehouse
I have intermediate knowledge in Java programming but I am thinking that I would like to try developing this in another language. Here is what I was planning to use (and also my confusion)
I am planning to use IIS to host the databases on multiple computers and I decided to use ASP.NET as my programming language for website and C# as its backend but I am confused about the relationship between ASP/ASP.NET and C#. It seems to me that having ASP/ASP.NET/ASP.NET-MVC is sufficient to build the whole thing without needing C#. Can someone please explain the differences to me? I am still at lost after reading about them the whole morning.
Well,
The difference are lot. Please learn this below links.
ASP is a old version
ASP.NET is advanced version than ASP
ASP.NET MVC is more advanced version than ASP.NET
You can click the above link for a difference.
also see this below discussion for
Relationship between C#, .NET, ASP, ASP.NET etc
the answer have:
I understand your confusion, believe me I have the same perspective when it comes to the Java world! Anyway I'll attempt to break your questions down and tackle them one by one... as well as add some other points in that will hopefully help clarify what's going on:
C# and C#.NET are the same thing... C#
.NET is, as you say, a library of code that .NET languages can talk to.
.NET languages come in different flavours such as: C#.NET, VB.NET, Managed C++, F#.
.NET languages compile to CIL (Common Intermediate Language) which means they all start "talking" the same language and can therefore interoperate.
ASP.NET is the portion of the .NET library used for making web sites. There are other subsections of ASP.NET like WebForms (the old way of making web pages) or the rapidly maturing MVC library that are worth looking at too.
Forms (old tech) or the new WPF (Windows Presentation Foundation) are the technologies you'd typically use in .NET to create what you know as traditional desktop applications.
One final thing I'd like to finish on is the difference between library and framework. In recent years these two terms have been used as those synonymous, however that is not the case. The easiest way I can think to differentiate the two is:
A library contains many pieces of functionality that you may pick and choose from i.e. using one piece of technology doesn't mean you're locked into the rest. This means freedom, however you will have more work cut out for you.
A framework however very much sets out how you will be working be providing a workflow that for better or worse is hard to change. This means rapid development/prototyping, but if significant changes are made in the future it may be impossible (or very time consuming) to implement them.
The project you're working on will depend on which choice you make.
I have a current site written in classic ASP VB and I would like to upgrade it and I have been working heavily in ASP.NET MVC 3.
I would like to find a solution to get a system that works with both CLASSIC and ASP.NET.
Is there a way to develop a new system in MVC and navigate in and out of CLASSIC and back into MVC workflow?
If so, whats the best way to achieve this?
Your biggest issue is state. In ASP, chances are you threw a lot of crap into the Session object. ASP.NET (MVC or web forms) and ASP do not share the same session (state), so you end up having to store state somewhere to have it continue to work.
As long as you can get a place to store the state that both ASP and ASP.NET MVC can both consult, you can start migrating the pages piecemeal. If you cannot figure that out, you will have to scrap the ASP after you completely rebuild the site in ASP.NET MVC.
NOTE: I have been leading migrations (ASP >> ASP.NET (both flavors) and VB >> VB.NET). Unless you absolutely have to use a mixed mode, you are better to rebuild and then migrate the site over rather than rely on a mixed site. The worst thing that can happen is somebody stored something stupid in session or application, that you did not envision, and you are now in a place where you are not keeping something important. And you probably find it after a user complains about some transaction they did that did not migrate and now you no longer have any information about it.
NOTE 2: Sometimes clients want to migrate piecemeal and refuse to listen to you stating it is a bad idea. Your option, at this time, is move on to another client (or job) or do it. If "do it" is the option, make sure you have your butt covered, as this is a minefield.
Based on my experience, the answer is no.
The problem between ASP and ASP.NET are that their Core are completely different. For example, there is no way to share their Session values because they work completely differently.
The only workaround I could see would be to put the shared information between the two technologies in the database for the other to consume, but that's dirty since that information is only temporary.
If you don't need the identification or any other information shared between the two other than persistent information, you can include an ASP file anywhere is a ASP.NET MVC solution. Visual Studio will try as hard as possible to give you IntelliSense (but it won't work between ASP and ASP.NET modules) and IIS should be able to execute the VB code in the ASP file. When you switch from a technology to another, you include a certain ID in the address.
If it's not your case, the best way at that point is either to keep the project as legacy in a ASP project which may work very well for many years if some standards are well implemented or to switch entirely the project to a ASP.NET project and start from scratch.
I'm done some WinForms work in C# but now moving to have to develop a web application front end in .NET (C#). I have experience developing web apps in Ruby on Rails (& a little with Java with JSP pages & struts mvc).
Should I jump straight to MVC framework? (as opposed to going ASP.net) That is from the point of view of future direction for Microsoft & as well ease in ramping up from myself.
Or if you like, given my experience to date, what would the pros/cons for me re MVC versus ASP.net?
thanks
Have look here it will help you Choosing the Right Programming Model
If you need to work really close to the wire then MVC is a great choice. By this I mean, if you need to have very tight controls over markup then; while acheivable with WebForms; it is much easier with MVC. This would be common for applications that are targeting a public (e.g. internet) audience which might have a richer graphical experience. In contrast, if you're developing an internal (e.g. intranet) business application where graphical presentation is not as critical, then WebForms has a lot of really nice enabling capabilities that will allow you to move more quickly.
Don't get me wrong, you can make WebForm applications look really really nice, but you give up some control over the markup.
Very often ViewState comes into this kind of discussion. MVC will not have any ViewState so the on-the-wire footprint will be much smaller which translates to speed and bandwidth cost savings at some point. On the downside, making stateful applications with MVC can be more painful. In contrast, WebForms will carry ViewState by default and are inherently more stateful. This is typically fine for internal applications. Keep in mind that ViewState does not have to be sent over the wire... there are extensions that allow you to offload that to a local cache. I'm not favoring one over the other, but you should be aware of what each can do in this regard.
If unit testing is important to you then MVC is also a much better choice, as this is easier as well. This is totally acheivable in WebForms but requires you pattern your code behind correctly.
Security is not a major factor since much of setting up the IPrinciple and IIdentity occure in the HTTP pipeline via HttpModules, so either will do in that regard.
Another major factor in making your choice relates to your skills relative to the time you have to deliver... If you're not used to working in a stateless manner or coding standard web technologies (e.g. html, css, jquery, etc...) MVC will take you longer to do very basic things. With that said, once in place it will likely be cleaner, smaller, more testable, and faster. If you need to move very quickly there is a lot you can do faster in WebForms. WebForms also does a lot of heavy lifting with respect to markup so there are a number of details you can leave to ASP.NET.
I actually use both for a variety of reasons, and MS has stated they plan to continue support and development for both.
MVC is part of ASP.NET. You must mean MVC vs Webform to which the answer would be: coming from a Winform background, you will find webform easier to use. For the future, go MVC.
I used to work on desktop applications too, and never really got into web stuff. I didnt even (gasp!) knew HTML (yeah, that was my programmers shame). In my new job we were going to start a new application using ASP.NET MVC and I gotta tell you, I love it. HOWEVER I think you should only go with MVC if you are or you count with someone with good html/css design skills.
Html is easy I know (I've learned it know!) but I think its kind of hard to make nice designs with html and css, specially if you suck at designing and you could probably do prettier stuff using webforms, which is a little bit easier/similar to winforms.
Also, if you go the MVC way make sure you have enough time to learn it, since you are going to go a little bit more low level, gonna have to learn more of the little details, like the actual difference between post/get and all that stuff that is pretty much completely hidden in webforms. I would really recommend getting a book, I used this one Pro Asp.net MVC and really liked it.
Finally, if your page is gonna have interactive bits, or ajax-y things, if you go the MVC way you are more likely gonna have to learn javascript/jQuery too. If you go the webforms you can use the included drag'n drop ajax controls.
Coming from Ruby on Rails or other MVC based frameworks ASP.NET MVC is almost the best choice. (ASP.NET MVC is actually only the "VC" part, so you have to add an ORM of your choice. EF and Linq to Sql is the Microsoft way, NHibernate or other ORM's are the other way. One good quick start project is S#arp Architecture which uses NHibernate as the "M" part, or you can check out WHCM, which is a project built on S#arp Architecture and other good frameworks (it is considered an ASP.NET MVC best-practices demo project) ). ASP.NET MVC uses almost nothing from the WebForms package (the only exception I found is the AntiForgeryToken), so you'll loose nothing if you're unfamiliar with ASP.NET WebForms.
But as you said you have also made console applications, which ASP.NET WebForms resemble more.
If your project is new, I advise you to use ASP.NET MVC. If your project clearly separates the M-V-C part (like in S#arp Architecture, where they reside in different assemblies), creating a console application that uses the same business logic shouldn't be too hard. If your current project is to port a WinForms application to the web, then it might be easier to use WebForms.
I should get familiar with the language before using "fancy" stuff like MVC, because it's just way easier to learn when you could almost think in the language (but it's not necessary).
Horses for courses. If you're slapping together a quick app for someone, web forms is probably quicker and easier.
If you're building a long running enterprise app MVC gives you better testability a SoC.
I'm currently working on a project that has a sizable amount of both client and web code. The client code is written in C# and the web piece is written in PHP. Maintaining consistency between the two worlds is becoming cumbersome, and I want to consolidate the web code to .Net.
The issue is that I hate web development in ASP.Net Web Forms. I want something as raw as PHP, just using C# instead. I've read a little about ASP.Net MVC, but it looks like it abstracts too much of the request logic for my liking.
Does anyone know of a lightweight way to allow C# + .Net to handle web requests? Should I be looking more closely at MVC?
Update: I went with ASP.Net MVC and I've been very pleased so far.
If you're looking to get away from ASP.NET Web Forms, the I recommend ASP.NET MVC with a custom view engine (like Spark, or NHaml). This will give you the consolidation your looking for and allow you to avoid most of the Web Forms that your not happy with.
AFAIK, to do .NET web development, you are going to have to interact with ASP.NET in some form or another, but the custom view engines in MVC could be exactly the abstraction your looking for.
It is now possible to use a software stack completely separate to IIS and ASP.Net using Kyak, Nancy and Gate.
http://bvanderveen.com/a/gate-0.1.0/
You might want to check out Kayak, which is, to my knowledge, the only standalone .NET web development framework that's not ASP.NET.
Caveat: Kayak's request handling implementation is not the best, so there may be performance or scaling issues. I can't say for sure -- I've only read it, not run it.
Edit: I've taken another look at the source code, and it looks like they've rewritten a significant portion of their server code, and in doing so fixed the major issues. Performance probably won't be a problem.
MVC.NET is open source, so you can make it do what you want. It is a framework that is overrideable, extensible, etc. I'd look closer at it. It works great for me and I've come from a background of CGI, Struts and Webwork. I love it.
In my opinion nothing is more lightweight than the combination of NancyFX (http://nancyfx.org/) with Dapper (https://github.com/SamSaffron/dapper-dot-net) for data access.
NancyFX can be hosted within ASP.NET, WCF, Azure, OWIN-compatible environments, Umbraco or you can write your own host.
Read also these articles:
http://theothersideofcode.com/lightweight-development-in-dot-net-nancy
http://theothersideofcode.com/lightweight-data-access-in-dot-net-massive
I also suggest you to TinyIoC (https://github.com/grumpydev/TinyIoC) for decouple your application layers.
Regards,
Giacomo
You should look into the IHttpHandler and IHttpModule interfaces. These are the foundations for ASP.NET WebForms. Brad Wilson has a good intro to the former.
In the bad days when WebForms was the way to do ASP.NET development I was writing my own simple MVC framework with these interfaces. The bit I struggled with at the time was the View engine but now there are a number of these.
You take a closer look at ASP.NET MVC since the source is available and decide for yourself. It may be that you want to change some of the conventions used rather than the whole framework.