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.
Related
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'm looking at the differences between a Web Site and a Web Application on MSDN, and am drawn to the features of a Web Site because I am tasked with devising an architecture in which customers can heavily customize the application we deliver. It seems this feature of web sites would be useful:
You want to be able to update individual files in production by just
copying new versions to the production server, or by editing the files
directly on the production server.
However, I'm also drawn to the MVC architecture because it has built in features for minifying scripts that are delivered to the client. I also kind of like the idea of breaking up the architecture into clean pieces since this is a very large data model we have.
But from what I can tell, these sets of features appear to be mutually exclusive. Is that true? I can't readily figure out how to create an MVC application in which custom views could be dropped in as pure source files, and be able to run, nor can I figure out how to take advantage of any MVC framework when creating a "Web Site" project. Am I missing something or do I have to pick my poison?
Take a look at ASP.NET templates in VS2013. You can create an app with both MVC and WebForms. This will probably give you a good combination of what you need. By default, view files are not compiled, so you'll always be able to publish new files without doing a full push if you want. In fact, VS2012 even allows you to publish select files or folders.
The choice between web site and web app to be is very simple. If you are creating a mostly static app, choose "web site". If you are creating an app that has even a decent amount of dynamic capabilities, choose "web app". Web Sites are not really designed to be dynamic, so the more dynamic you do in that setting, the more of a headache it will be to properly maintain it as the architecture just isn't where it would need to be.
What I would suggest is to spin both of them up and try out some scenarios that you are interested and see what works and what doesn't. Really think about how users will actually want to customize the app. Will they want to copy and paste files to production or would they rather request features and have them built properly? Or maybe they want to work with a workflow instead?
So make realistic business requirements, prototype and then decide. But based on what I'm hearing you want a WebApp and probably one that does MVC and WebForms.
Now everything ONE ASP.Net. You will be creating a WebForm, MVC, Webpages using ASP.Net platform.
Check this video about new features in VS 2013
Not sure you can create website in ASP.Net 4.5.
From my experience, I would go with WebApplication based project, where managing namespace and other stuffs are easy. In website its hard to get the standard name for the classes(randome) generated.
Go with MVC web application.
I have a good amount of knowledge in the ASP.NET Webforms and MVC worlds. Shortly I will be tasked with implementing custom web applications with Sharepoint. I have great flexibility with this project (i.e - I can use custom web apps outside of Sharepoint if that's possible) but like most projects the most limiting factor I have to deal with is time.
Here are some questions that come to mind:
Can I easily integrate a custom MVC project into Sharepoint 2010? What are the pros and cons if I can?
Same as #1 only with Webforms.
If #1 and #2 are not viable solutions, can I easily create custom web applications within the Sharepoint world? What will the learning curve be with my background?
I understand developers can now use Windows 7 to deliver Sharepoint 2010 solutions. It looks like I can use a trial of Microsoft Sharepoint Foundations 2010. If that's correct, are there any development differences or gotchas I need to be aware of before digging into the Foundation version? I don't want to get up to speed on Foundation and then find out that the Server edition (the version that will be deployed) is vastly different.
Thanks!
SharePoint is based on webforms - it is relatively easy to add custom user controls and web parts, though if you want to use SharePoint data in a completely custom web app, especially mvc you will probably need to host it seperately - you can access everything you need through the SharePoint API, but it makes the deployment a lot more complicated.
The workarounds to get webforms mvc running in the SharePoint web app tend to involve stuff that would never get past corporate infrastructure people, but I've been getting good results with precompiled razor views set up based on http://razorengine.codeplex.com/ - my version that produces code which can be included in a SharePoint project is at https://github.com/tqc/RazorEngine
In the 2007 version there were significant architectural differences between WSS and MOSS. With 2010 there aren't as many differences, so you should be ok, but it would still be better to develop on the same version you are deploying to - download a trial of Standard or one of the demo VMs - If you do a lot of .net development, chances are you already have an appropriate dev license.
What are you trying to accomplish? Are you connecting your MVC site to SharePoint or are you building something "MVC" on top of the SharePoint server?
In any case, there is an MVC SharePoint project on Codeplex here http://sharepointmvc.codeplex.com/
Here is an article on the subject http://blogs.msdn.com/tom/archive/2009/03/17/asp-net-mvc-and-sharepoint.aspx
I havent touched it, and it seems a bit abandoned to me, but it might get you along.
Check out it outlines one method of running MVC with SharePoint
Generally, SharePoint will simplify many user-oriented requirements you may have - such as authentication, permissions control and personalised areas (with MySites).
If you go with SharePoint, you almost have to build your product for SharePoint Foundation so that you can keep your customers' total costs low (SharePoint CALs, SQL Server, hardware, etc). You'll want to build friendly user interfaces for managing permission, allowing your users to create their own pages, and other provisioning tasks -- or provide rock-solid documentation on how to do it out of the box with SharePoint. With SharePoint, you should use features and Web Parts to deploy your code either way , whether SaaS or on-premise. That will make it easier to deploy and upgrade.
Are both completely different concepts? Or is there an overlap in their meaning?
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
Are both completely different concepts? Or is their an overlap in their meaning?
A web (application) framework is a lower level, generic toolkit for the development of web applications. That could be any type of system managing and processing data while exposing it's data and services to human users(via web browsers and other interactive clients) as well as machines via the http protocol.
A CMS is one type of such applications: a system to manage content shown in websites. Usually/historically, this mainly means managing (pieces of) text of "pages" shown in a web site, and useres that have different levels of access to manage this content. That's where the C and the M come from.
With a CMS, you can manage web content. With a Web framework, you build web applications.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
No. It would be correct to say that a web framework can be used to create a CMS.
Both contain parts that work on the backend as well as on the front end.
Often, a CMS is based on a web framework - sometimes CMS developers build there own web framework, and sometimes they even expose the API of this framework, so a developer can create extensions to the CMS in a way as if he would develop an application with a web framework. Drupal really does this, so you can create real web applications based on the integrated framework - with the upside that they will also be easily to integrate into the CMS.
But that(exposing the API of a web framework) is no necessary criteria for being called a CMS.
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
It's be possible to combine two existing systems build with these two, (e.g. because you want to show some data in a web site managed by drupal, that already exists in a Rails-based system).
But as Drupal also provides you some of the genric functionality of it's underlying web framework, it might not be necessary. You would have to manage and learn two very different systems and handle all the problems with there interoperation. So, I'd try to build a Website with only one of these if possible and only combine them if theres a good reason to.
They're different concepts. A CMS can be built on top of a web-app framework, but a web-app framework has no direct relationship to a CMS. Its at a lower level, providing a platform for any type of web-app to be built on top of it, of which a CMS is an example.
Drupal runs on php and Ruby on rails runs on, well, Ruby, so they wouldn't play together.
Just to muddy the waters a bit, Drupal describes itself as a content managment framework which is essentially a content management system with hooks to extend it. Which does create an overlap. The drupal overview describes this better than I could.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
It's not "correct" but it's not wrong, either. A web framework is a general concept -- many things count. A CMS is a specific concept, often built within a web framework. Sometimes CMS's are stand-alone web applications. More often, however a CMS is a back-end things that require a customized presentation front-end.
Should the Web Framework use the same technology as the CMS?
Shouldn't matter. At the end of the API definition, the Framework and CMS can have any implementation at all.
Web App Frameworks -- generally -- must either serve HTTP requests or plug into something like Apache.
A CMS is a glorified database, and any sensible API is good. Most often, however, they're also using HTTP as their interface protocol.
Could Ruby on Rails be used in combination with Drupal?
Sure. Purists will object, but there's no technical reason why they can't cooperate.
When developing a web app, in my case a ASP.NET MVC app, but this question isn't platform specific, when you do you add the infrastructure for membership, roles and authentication?
I've actually done it both ways....
1. Start developing the app with membership/roles/authentication being one of the first milestones and
2. Wait until most of the major functionality and requirements are implemented then add in the membership/roles/authentication infrastructure.
Is there a best practices for this or it is personal preference?
I mix it up depending on what I'm working on.
ASP.Net allows you to abstract security components so much that I find it's really easy to implement them after the fact. Sometimes it's as simple as having your pages inherit from a custom page class. (Or in the case of MVC a custom controller class)
Though, I have found it's a lot easier to debug core functionality when I don't have to worry about the security measures getting in the way.
To quote from "Professional ASP.NET MVC 1.0" (which I happen to be working through),
The default Visual Studio project template for ASP.NET MVC automatically enables forms authentication
when new ASP.NET MVC applications are created. It also automatically adds a pre-built account login
implementation to the project – which makes it really easy to integrate security within a site.
At least for the tutorial, it mostly just happens, and any explicit references seem to fall in nicely toward the end - but there isn't much. It's the same level of simplicity as PHP sessions if you use it as intended.
I'm not very familiar with ASP.NET but every time that I develop an web application security is almost the first thing that I code, otherwise you might miss something in further development; either because you forgot about it or more probably because something has changed during development.
Security is part of the up-front application design. You cannot add it on later except in the most trivial cases.
Example: HR Application. The compensation manager can edit compensation, the recruiter can only view it. If you don't know about this distinction up-front, you will not build it into your user interface, and you will be in trouble. Yes, security in ASP.net is largely configurable, but the structure/granularity must be in place in the application.