Converting Existing Dnn Application to .Net core
I have a application of dnn having ado which I need to convert to .net core with ado web application.
In this I have to move only two modules from the application.
what i have already tried so far.
cleaned the database from the dnn tables.
changed the ascx pages to partial views.
changing the ascx.cs pages to the controller.
Need Recommendations for fast conversion and if I can follow any pattern.
Given the nature of the way that the DNN Platform works, there is not a fast transition to a stand-alone installation.
There is no Microsoft documented "Fast" transition plan from Web-Forms to .NET Core as well, so nothing that you can try to mimic from other installations either.
Since you will need to extract dependencies on DNN as well as dependencies on System.Web that are no longer available, it is best to treat such a transition as a re-write, rather than trying to "simply translate" as there isn't any method to do so.
Related
OrchardCMS, Umbraco and DotNetNuke are CMSes in .Net galaxy. They work as stand alone applications well. Suppose I have a requirement that need CMS features in an another ASP.NET MVC application. I do not like to implement CMS again in the application. Rather I like to use current CMSes as a component of application.
Is it possible at all to use for example OrhcardCMS as a component of my MVC application? It is ideal to have relations between CMS and application itself, for example I can load entities from CMS, update them etc.
I know there are integration techniques in .Net. For example ASP.NET Identity integrates with ASP.NET applications in core level, but view (CSHTMLs) must be copied and customized in most cases. Or Hangfire and ELMAH that integrates with an application without need to copy view (cshtml, html, css) to the target application. Indeed it is good to know that integration methods are available regarding plugging CMSes into ASP.NET applications.
I can tell you more about Umbraco as I don't know other CMS as much as this one. There is a whole course / training for those who want to integrate their apps with Umbraco: https://umbraco.com/products-and-support/training/umbraco-application-integration/. So yes, it's possible and it's even suggested way from my perspective to use already done piece of software rather than building the wheel once again.
Umbraco is an ASP.NET MVC application. You can use Umbraco components, backoffice, membership and everything else CMSish delivered out of box and still you're able to write and use your business logic, controllers and everything else what you've created inside your ASP.NET MVC / C# app. Still, it's an ASP.NET app, so you can use anything what you want from the .NET world. We're using ELMAH.io for example to take care of logging and keeping the errors in the cloud. We're also using a ton of 3rd party, both open-source and commercial tools and softwares to do multiple things around our web components. Umbraco is not blocking us from using them or anything else. I like to consider Umbraco as a framework or library helping us to deal with content editing and giving us a massive number of opportunities to offer for our clients or editors.
Speaking for OrchardCMS, there are some questions touching this subject already, see
Reusing Orchard's Core to build another extensibility framework
Extracting a Module from Orchard
If it's possible for you then try to setup Orchard as the base system and move your MVC application in a module. This will be much easier than trying to cut out peaces of Orchard. In return you get amazing possibilites when running Orchard as the underlying framework, e.g. Localization, Modules, Themes, the whole user / role management etc.
OrchardCMS 2 is currently developed towards single components that can be reused in any application but it's far from finished yet.
I am trying to migrate a project from classic ASP.Net Web Forms to ASP.NET MVC.
While I have read through http://www.codeproject.com/Articles/38778/ASP-NET-WebForms-and-ASP-NET-MVC-in-Harmony. I have a basic idea on how the code structure, libraries and routing should be done.
For your information, the scope of my existing project is around 400 pages and 300 tables.
On top of my head I have two approaches:
Start from stretch, rewriting the whole system - Obviously this would require intensive work and take a long time. Any change made on existing system would need a duplicate change made to the new system.
Migrate the page one each - I still have a rebuild the entire core library (for accessing db), and get the page migrated one by one. For this I would assume to have two core libraries (new and old) running simultaneously with different pages connect to one of those.
Would anyone have similar experience and advise a proper way to start?
For this complete revamp I may also target at the latest technology - .NET Core and MVC6, by taking these would I have extra advantage, or some blockages I would have to take care of?
Any suggestion and opinions are appreciated. Cheers.
Microsoft is a bit hush hush on the subject but the WebForms engine is probably never going to make its way to ASP.NET Core. One might think that MS is waiting to see if the community is calling for a port, but I think they're trying to kill it discretely (not like Silverlight).
Why? Because it proved to be a bad good idea on the long run, easy to use at first, but extremely complex to master (because of viewstate and page lifecycle), with a tendency to allow average developers to build very tedious application (in french we say steam factories). Also it was very poorly adapted to modern web development (Ajax, unit testing, IoC). They tried to fix it with a couple of tweaks, but the overall architecture is just not adapted to this kind of things. MVC is a treat in comparison!
To answer your question, it's not really possible to migrate WebForms to MVC, because those are quite different architectures, and of course the architecture is what an application sits on top on, so if you change it, you might as well rewrite it from scratch.
What can help you a lot is if your app is divided in tiers (business, data access, UI). If it's not the case, you could start by doing this, properly separating the UI project from the rest. Then you would just have to rewrite the ASP.NET project and not the rest.
There are some useful resources I'd like to share with the StackOverflow community just in case you are having troubles to decide what to do:
modernization of your existing Web Forms app
migration to MVC or Core
or whether to start a new project on Web Forms, MVC and Core.
Here you go:
https://www.telerik.com/blogs/review-of-telerik-toolsets-for-aspnet-web-forms-core
Modernizing ASP.NET Web Forms Applications by Tomáš Herceg (Microsoft MVP ) - https://tomasherceg.com/blog/post/modernizing-asp-net-web-forms-applications-part-1
Migrating Old ASP.NET Applications to .NET Core by Edi Wang (Microsoft MVP) - https://edi.wang/post/2018/10/31/migrating-old-aspnet-applications-to-net-core
Choose between ASP.NET and ASP.NET Core (Microsoft docs) - https://learn.microsoft.com/en-us/aspnet/core/fundamentals/choose-aspnet-framework?view=aspnetcore-3.1
Migrate from ASP.NET to ASP.NET Core (Microsoft docs) - https://learn.microsoft.com/en-us/aspnet/core/migration/proper-to-2x/?view=aspnetcore-3.1
i have come across below links
https://www.youtube.com/watch?v=CZuqMrWSano
https://www.dotvvm.com/blog/59/Modernizing-ASP-NET-Web-Forms-applications-with-DotVVM
DotVVM package helps us to migrate ASP.Net Web Forms migration to ASP.NET Core without re-writting completely.
i have not tried any production application. still have tried some sample pages. you can try this out.
I can agree that for many cases a re-write of an ASP.NET application where WebForms is used widely may do not provide any business value.
Therefore we decided to use our experience with ASP NET WebForms to develop a highly compatible port of WebForms for ASP NET Core / .NET 6.0.
We use the solution in our own ASP NET WebForms-based products and projects as well as a licensable component library.
So the Forms can still be used and you can focus on the .NET CORE/6 migration.
I have an ASP.NET MVC5 application which was created in the times of MVC3. During the times I've upgraded over and over until the current state which uses MVC5 and Ninject.
I use Ninject with the Nuget packages Ninject.Web.Common and Ninject.MVC5. To tell the truth I'm not even sure the latter is needed because MVC5 seems to use its built-in IDependencyResolver interface whenever it's needed.
The applicaion is run inside IIS, and all the setup and configuration is done in Global.asax file and Web.config.
Now we reached a point where we would like to use SignalR for a submodule, and so there is time to migrate the whole application to Owin as SignalR uses that too. I wouldn't like to make a mess with mixing several technologies.
I couldn't actually find any good guides about the required steps and what issues can occur, what with should take care of.
Has anybody done a similar migration?
I've recently just attempted to deploy a site (it's a web api project) I worked on a Win 2K8 server with IIS installed and the .NET 4.5 framework installed. i was surprised when it didn't work. It basically acted as if it had never heard of the MVC-style routing notion; because it was issuing a controller/action/id type request it didn't know to invoke the routing engine and map this to controller actions.
I eventually took the fairly extreme and silly approach of setting copylocal = true for all assemblies in the project, even the ones that I know must be in the GAC. Bin-deploying it this way works.
So....my question is this - how do I know which need to be copied local and which don't? I mean, I installed the .NET framework 4.5 on the server, and ultimately it seems as if the libraries involved should have been resolved because the .NET framework was installed? Of course the nuget packages all need to be copylocal=true, but within the set of MS standard libraries it seems as if the web site still doesn't find all of them.
Is there a rule I can follow that helps me understand which ones I need to copy locally?
If ASP.NET MVC 4 is the first version you use, and you don't learn every aspects of the framework from a good enough book, I hope you spend some time to review related articles on the Internet to get better understanding,
http://www.hanselman.com/blog/BINDeployingASPNETMVC3WithRazorToAWindowsServerWithoutMVCInstalled.aspx
http://haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx/
ASP.NET MVC is not bundled in .NET Framework, so most of the binaries you refer to must be set as copylocal=true. This must be painful for beginners, but experienced users are already familiar with that.
I have been tasked with a project where I am to add a new application and have it within an older application (web applications). This is an internal application and management decided that they want it wrapped in this older app. The older application is a ASP.net web app using the 3.5 framework.
My original plan was to use jQuery and Web Services (using JSON and AJAX). My team-mate on the project really wants to use Entity Framework (4.0). As we may be sharing the same look and feel the data is a different database altogether.
After several attempts yesterday, we found some issues. We created a project inside the original solution that targets the 4.0 framework. I created a WebService on the project, but when I tried to call the webservice from the 3.5 project I didn't get an error but I didn't get the return string. I was watching on Firebug and did not see the GET call either.
My team-mate did a little more research and found out about the cross-domain issue and jQuery, so it seems that we are limited with the Entity Framework (3.5) and remaining on the .net Framework (3.5). We did try changing the dataType to jsonp but calling the WebService still didn't work.
However, I was wondering, really management wants the project wrapped inside this other project for consistency sake (navigation, design and so forth). Is there a way to have the 3.5 project display our code that is being generated from the 4.0 project (a totally different solution and probably a different server)? I'm thinking the way the iFrame used to work but I don't want to use an iFrame at all.
One way to solve this problem would be to stand up a WCF webservice to handle the database calls. You could develop your "data layer" with .NET 4 and EF4, then call that layer from your .NET 3.5 ASP.NET application. It's not the absolute cleanest solution, but it would allow you to get the benefits of the newer version of EF.