I have a client that currently has a shopping cart written in ASP that he wants to keep using. We are looking at upgrading the rest of the site to DotNetNuke which is based on ASP.Net.
Does anyone have any guidance on how to use asp pages in an asp.net application? IFrames? I did a little ASP just before dotnet came out, so I"m not that familiar with ASP.
You can combine them pretty easily, you will just need to have the asp have its own global.asa and session timing. As long as your authentication logic is simple, you can write it in both, or consume it as a service from the asp pages.
The main concerns are shared state amongst pages. IFrames are viable options, but hard to get to look natural.
I'm currently doing this in an application that is half converted, its 170 aspx pages, and 210 asp pages.
That said, the context switching of maintaining both parts, is painful. So try and get it rewritten, quickly. On MVC its fairly trivial to have the logic flow like asp.
You can mix the two, but I don't think you'll be able to do things like share state between them unless you cater for this with a third party provider. They'll behave more like two "seperate" sites.
One other thing worth mentioning is that if you are provisioning a new web server for the mix, and planning to pull in the old ASP code, is that ASP is not enabled default on the more recent versions of IIS.
You can't use ASP pages in an ASP.NET application.
You can have an ASP application and an ASP.NET application in the same web site, but they are still two different applications. They work side by side, basically unaware of each other.
You can have the pages communicating with each other, and even use iframes to seamingly mix them in the same page, but communication is not trivial as the web applications can't communicate directly. You can communicate between them on the client side, or through a common backend database (or any other indirect way that you can think of...).
You would be much better off using a single ASP.NET solution.
There is a DNN shopping cart module available from here. There is supposed to be a community edition. [I haven't used it, so can't say how good it is]
Most asp is going to valid as asp.net. You may be able to rename your .asp pages to .aspx and get 80-90% of the old code working under asp.net. Then fix anything that's broken and slowly migrate more and more of the old code to proper asp.net.
Related
I want to reuse a project developed in vb.net in c# webform project. The login form should be same for both the projects. How can I achieve this? Can I add vb.net and C# forms in single project.
If created as separate projects in single solution, can I share the session variable between two projects?
I want a common login form for c# and vb.net project. Need to share user credentials between two apps
Well, you can intermix pages of vb and c# only if the web site is NOT a web site application.
So, it kind of depends.
If your web site is setup as a website application? Then no, you can't do this.
You can certainly take any of the code modules, classes, and business logic from the vb.net applcation, and refreence such assemblies in the new c# project.
And its not really recommended to do this anyway (ie: mix both types of pages in one project - but, you can do this for a web site, but not for web site applications).
I see VERY but VERY little advantage to simple re-writing all that code. It not like your going to get more features, or anything of value here.
If you looking to migrate to .net core, MVC etc? Then again, those pages could not be used anyway - even if they were written in C#.
So, either you consider this a migration project out of webforms (and .net 4.8), or you don't. Anything in-between is really a waste of time and resouces. If that site is to continue running as webforms, then I can't really make the case to migrate the code to c# - I just don't see any benefits here.
So, this can work for a asp.net web site, but not for a asp.net website "application".
And, I always hands down preferred the "application" choice, since then things like including other projects and code (often written in c#) can be used and is supported.
But, a page with code behind in vb.net, mixed in with pages and code behind in c#? No, you can't do this with a web site application, and giving up the application choice (vs that of a web site) I think is too high of a price to pay in that you lose out of the benefits of a asp.net application choice in the first place.
This sounds like good money after bad. Unless you going to migrate to a newer framework? It makes VERY little sense to spend time + money to migrate to JUST c#, and I can't see any real benefits of doing so.
if the developers in question know well asp.net + webforms, then the learning curve to maintain the site "as is" with vb.net? I can't see more then a day or so for any good c# developer to get up to speed with vb.net.
c# or vb.net is really moot - what matters is a good solid skill set in the .net framework, and unless you jumping over to .net core, then as noted, I can't see how the cost of this work can be justified. it in effect amounts to stealing money from those paying for this conversion, and that means someone is being mislead, or miss informed here.
This is an odd question, and it just occurred to me today. I've been trying to convert an ASP Classic application for a couple of years now into .NET Webforms, which I knew way back when.
The ASP Classic app in question is pretty much a CRUD app, but I've added over the years a lot of jQuery and Ajax, so it's pretty responsive and behaves the way I'd like, so it's not a fill form, post to page type of app. I'm still developing that one in parallel with the .NET one as new features are required.
In any case, the WebForms that I go back and look at is cluttered with ViewState and controls named weird and total crap.
I don't have a lot of time coming up - tight dev schedules - so I was thinking about using the WebForms without ViewState so I can essentially pull over the Ajax and jQuery code from the ASP pages and use .NET almost like ASP with the benefit being the debugging and the extensive libraries of data access and business logic components I've written in .NET for standalone console apps.
Again, tight schedule. I've got an isolated portion of the app in ASP.NET (Administrator Pages), so I could dump ViewState and be able to start reusing front-end code.
Is this an ok approach in transition? I'm not sure yet what my ultimate platform will be (MVC or WebForms)
Is there anything else I must do besides disable ViewState to make my code behave and for page elements to not do anything "funky" like rename controls or insert code?
I have inherited a Classic ASP application with a Delphi COM layer. I am tasked with migrating the app to ASP.NET MVC2 and C# with web services replacing the Delphi. Due to the amount of users of the application and the fact that I'm the third developer this company has hired to do this, the company would like to migrate sections at a time. That leaves us with a mixed hybrid of Classic ASP and ASP.NET MVC2 sections. My guys and I have built the first section of the app and are ready for integrating the apples and oranges. My question is, has anyone done this? If so, how? The first attempt is creating a sub-folder in the classic app and inserting the MVC stuff into there. Doing it this way, I cannot get any urls to work. It's probably some ignorance in the MVC pathing but if anyone has any tips at all on this, combining ASP and MVC2 I would love some help.
Thanks and I apologize if this is a bit vague, I'd really just like to start a conversation or connect with someone that's done this before.
First, you need to make the subfolder in the classic app a Virtual Directory or Wep Application for MVC to work, it wont work simply dropped in a subfolder of an IIS website.
Second, if the app is authenticated, you need to figure out a way to share the authuthentication so users don't have to login every time they switch sections of the app. (Unless thats an acceptable situation, which I doubt). Sharing this authentication may involve making some changes to the existing application, or possibly not.
I wonder what is the scope of this project and why it cannot be done in one felswoop? I'm not saying doing it in phases is bad, but if that is a requirement, you'll need to address the above issues.
I think that much better way is rewrite app to MVC from scratch. No step-by-step, no mixing. It will save you a lot of pain and also it will take much less time to do, even it doesn't seem so at first sight.
I will apprecaite your help in this topic.
I need to build a site with friendly urls using url rewriting in order to improve SEO positioning.
I've been searching torought web and finally pointing to this two main options :
asp .NET with isapi extension
asp .NET mvc
however, I got no experience on both items so I need you to help me to kwow further about this two technologies and to take the right decision for my needs.
Thanks
There are much bigger concerns than just URL setup when making this choice. You're talking about two completely different architectures for building your web pages.
You should make the decision on how you want to build your application, what skillsets you have available in your developers, etc. Both approaches will be able to handle the URLs that you need to generate for SEO considerations.
For public facing websites, I would personally choose ASP.Net MVC, because I find the development cycle shorter, more productive, more flexible and more maintainable than an ASP.Net webforms application.
Assuming you have a host/server that can run ASP.NET MVC (i.e. one that has the .NET Framework 3.5 Service Pack 1 installed on it), you can use the Routing Engine (System.Web.Routing) from ASP.NET MVC in a web forms environment, Phil Haack has a good updated walkthough at "Using Routing With WebForms".
There's also "How to: Use Routing with Web Forms" on MSDN.
Unlike an ISAPI filter, this enables you to use the routing engine to generate your internal links as well as responding to well formed links from outside.
I agree with womp. But there is one advantage i see in Asp.Net webforms that Asp.Net Mvc doesn't have: Rich Client Iteraction controls. Everything in Mvc in View layer is simple and functionality need to be build from scratch.
alexserver - at the same time of course, the fit between mvc and jquery is an overwhelming reason to abandon the rich clinet controls. that way, you can literally get your designer and/or a jquery UI expert to work on the view portions in isolation whilst you craft the model and controllers.
I'm thinking about trying out MVC later today for a new app we're starting up, but I'm curious if it's an all or nothing thing or if I can still party like it's 2006 with viewstate and other crutches at the same time...
Yes you can have your webforms pages and MVC views mixed in a single web application project. This could be useful if you have an application that is already built and you want to migrate your app from webforms to mvc.
You need to make sure that none of your webforms pages go in the 'Views' directory in a standard ASP.NET MVC application though. Pages (or views) in the 'Views' directory can't be requested directly through the url.
If you are starting an application from scratch, there would be very little benefit to mixing the two.
Yes. MVC is just a different implementation of the IHttpHandler interface so both classic ASP.NET and ASP.NET MVC pages can coexist in the same app.
As you've probably noticed with the above answers, yes this is very possible to do.
I've actually had to do this on my current project. I was able to get approval to add MVC to our application, but only in the administration section (to limit the risk of affecting current members coming to our site).
The biggest problem I had was converting my Web Site to a Web Application, but once that was done, things were pretty straight forward adding MVC side-by-side our classic code-behind web pages.
The trick for me was to make my MVC pages look as similar as possible to my code-behind pages so the transition looked as seamless as possible.
I am currently working on a new project. While I would like to go down the MVC route all the way, some of the project requirements don't allow me.
One of those requirements is to have a grouping grid from the client-side. Personally have chosen the Telerik Rad-Grid. While they may be in the process of supporting MVC they are not there as yet.
So this means that I have to have a hybrid solution. for the time being until RadGrid fully supports MVC.
While we are in this transition period I think that there will be may more hybrid projects out there until the support of the Third Party Controls catches up.
Regards
Nathan
You'll need to make sure your MVC routes don't conflict with your Web Forms pages so that requests for a .aspx page don't get routed to a controller action as a parameter etc.
See this blog post by Phil Haack for details on how to avoid this.
Yes, it is very much possible for MVC pages to coexist with asp.net web forms. I implemented that in my existing asp.net application for adding new features. We need to make sure of referring the MVC DLLs, registering routing tables for URL routing and configuring the assemblies and namespaces in Web.config file.
If you're mixing MVC with other methodologies you're not really getting the benefit out of it. The point of MVC is to allow you to decrease coupling and increase cohesion, and if only half of your code is doing that, then the other half is inevitably going to restrain your development cycle.
So, I guess while it's possible, I don't think it's worth it. Go all the way or don't go at all.