This answer suggests that one should create a new project for Umbraco content management alongside the existing MVC application. I have created the new project as suggested, and installed Umbraco into it through NuGet.
So now I have 2 projects, one for my MVC application and one for CMS. Both are working as expected, meaning that I can add contents through the Umbraco UI after building the newly created Umbraco project.
My question is, how can I query the content from inside the MVC application in order to show the manageable content on my views? It seems that it can be done through the Umbraco REST API, but as both databases (for the MVC application and the CMS application) will reside on the same server this seems unefficient.
Traditionally one of the problems with Umbraco is that it is not a pure MVC architecture. This means that people are sometimes led to believe they will be able to implement a 100% MVC solution and then just manage their content through Umbraco.
The bad news is that you've found out the main issue with Umbraco so far. Namely that it doesn't render things using the standard MVC rendering engine. It has to use custom controllers to retrieve view-models, such as SurfaceControllers or UmbracoApiControllers (as mentioned by your example of using REST services to return the page data).
The good news is that things are getting better. Version 7.3.0 will be the first version to be bundled with MVC 5 as standard. Check out the beta version here to see if it is more suitable for your needs. Of course you may need to upgrade your MVC project to MVC 5 too.
Hopefully with 7.3.0 you'll be good.
Related
Let me start off by saying I've seen a StackOverflow question related to this but there's no question like this I want to ask!
In my learning journey of the framework ASP.NET, I find a little problem. When I create any new ASP.NET project using the dotnetCLI. by standard the projects are missing two files that i'm looking for the _AppStart and _PageStart. Where can i find them or how can i add them?
Thanks
The _AppStart and _PageStart files belong to the old ASP.NET Web Pages framework. They are not supported in the new Razor Pages framework, which is what you are using when you create applications using the CLI.
The equivalent to _AppStart in Razor Pages is the Program.cs file (.NET 6 onwards) or the Configure method in Startup (ASP.NET Core 2 - 5). The replacement for the _PageStart file is _ViewStart.
The Web Pages framework is more or less dead. Two of its four pillars have been deprecated (SQL CE and WebMatrix) and the recommendation these days is that you use Razor Pages instead.
https://www.learnrazorpages.com
https://learn.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-6.0&tabs=visual-studio
I am running a project with ASP.NET Core (2.1) MVC. In our company we do have a lot of work done with SQL Report Builder (rdlc and rdl files). Therefore we wanted to use a "one the fly" mechanism to generate PDF Files with the ReportBuilder technology in the asp.net core mvc webapp.
I tried the same nuget packages we are using in .net Framework (asp.net API and desktop app) but they are not working. The packages I tried are:
Microsoft.ReportingServices.ReportViewerControl.Winforms
Microsoft.ReportingServices.ReportViewerControl.Webforms
The problem there is that they are using System.Web which I cannot include in .net Core apps, do I?
I googled for any solution but did not find a lot of helpfull material. I am also ware of that Microsoft purchased a product to get the work done:
https://blogs.msdn.microsoft.com/sqlrsteamblog/2018/04/02/microsoft-acquires-report-rendering-technology-from-forerunner-software/
And I already read this article about a similar problem:
RDLC Local report viewer for ASP.NET Core and Angular(>2.0)
Do we have the wrong technology setup in mind or is this even not support at all. I found some other package (https://www.nuget.org/packages/AlanJuden.MvcReportViewer.NetCore/) which are working with html to render a report. But we really want to use the rdl files
Any informations and suggestions are greatly appreciated.
In the end we came up with a totally other approach.
We just created a new Application called "DocumentService" on .NET Framework running as a Service on a Windows Server. The service was checking a database if there are new jobs in the database queue and if so, it generates the pdf result and stores it in the database.
So the web application was not longer responsible for creating the pdf, it only added a new line in the database so mark that a new document should be created. The DocumentService app then generated the document and the web app could access the data in the database.
We can use this "DocumentService" in other part of our application landscape and therefore the effor was worth it. It app is also multithreaded and working pretty fast and well.
No you can't include System.Web. I had same problem and solved it with AspNetCore.Reporting. You can download this from NuGet. This can be useful: https://www.dotnetcurry.com/aspnet/844/aspnet-ssrs-reports-programmatically-html
Well, depends. If you want it inside your application, and don't mind generating the report in iframe it's possible. Or you can always open it in a new tab. Only problem is that you have to know the link to the report. I did it like that in my company's program. If you want to know more, just ask me, but officially ASP.NET Core doesn't support reporting
We have a corporate website with a large amount of dynamic business application pages (e.g. Shopping Cart, Helpdesk, Product/Service management, Reporting, etc.) The site was built as an ASP.Net Web Application Project (WAP). Our systems have evolved over the years to use .NET 4.5 and various custom business logic DLLs (written in a mix of C# and VB.NET). However, the site itself is still using VB.NET Web Forms. We now have done a few side projects in MVC 4 using Razor/C#, and we want to use this framework for new pages on the main corporate site going forward. What would be the easiest way to achieve this?
I found this nice list of steps to integrate MVC 4 into an existing Web Forms app. The problem is that because our existing app is a VB.NET WAP, it compiles into a single DLL, and .NET allows only one language per DLL. The site is way too big for us to contemplate converting it to C# all at once (yes, I've looked at the conversion tools, and they're good, but even 99% accuracy would leave us a huge amount of cleanup work.)
I thought about converting the existing WAP into a Web Site Project (WSP) which does allow mixing languages and then following the steps above, but after a few pages of Google results, I couldn't find any steps for converting a WAP to WSP. (Plenty of sites offer the reverse steps: converting a WSP to a WAP.)
Another idea I had was to create a completely separate MVC project, and then somehow squish them together into the same folder structure, where they would share the bin folder but compile to separate DLL's. I have no idea if this is possible, because certain files would collide (e.g. Global.asax, web.config, etc.)
Finally, I can imagine a compromise solution where we keep all the MVC stuff in its own separate application under a subfolder of the main solution. We already use our own custom session state solution, so it wouldn't be difficult to pass data between the old site to the new pages.
Which of the ideas above do you think makes the most sense for us? Is there another solution that I'm missing?
After some more research and experimentation (and thanks to a suggestion from T.S.) I have narrowed it down to either the 2nd or 4th option from my initial question:
Convert our WAP to a WSP, and then follow the steps to integrate MVC into the site. I don't see moving from a WAP to a WSP as a complete step backward. As the MSDN link explains, performance does not suffer, and it's mainly a question of how to adjust our build/deployment process. The major advantage with this technique is that it allows multiple languages to coexist in the same project and root folder. Certain files, such as Global.aspx.vb, would have to remain in VB.NET. But specific folders and web pages could be designated as C#. The disadvantage for us is that our site has a lot of legacy pages that use old-style server-side-includes of ASPX page fragmets, and these cause build errors in a WSP. These would have to be changed into User Controls, or perhaps renamed to an unrecognized extension, such as .aspxinclude, so that they are not included in builds.
Create an MVC child application as a new .NET project (see http://support.microsoft.com/kb/307467). The parent web.config needs its <system.web> section wrapped with <location path="." inheritInChildApplications="false">, and the new app's subfolder needs to be converted to an Application via IIS Manager. The child app can be a WAP using a different default language (C# vs VB.NET). This makes it is easier to isolate from our existing project. But this is also a disadvantage because the MVC routing only works on URL's in the subfolder of the child application. So if we wanted multiple parts of our site to use MVC routing, it would require separate child projects, e.g. (/cart, /myaccount, etc.)
We are probably going to go down the path of option #1, converting to a WSP, and only resort to #2 if we encounter a big obstacle.
UPDATE: I was able to do the conversion using technique #1. It's been working for several months now, so I published a blog post with the procedure I followed.
Came up with a very simple solution.
Create new MVC C# project
Add the old vb project to the solution.
Move the VB aspx pages to the new C# project
REMOVE THE CODE BEHIND ATTRIBUTE FROM THE FIRST LINE OF THE VB PAGES eg...Codebehind="ProductDetails.aspx.vb" (this is the magic)
Add a reference to the VB project in the C# project
This will work for master pages as well
Strangely the VB aspx pages 'just find' the codebehind from the reference and the C# project does not seem to care about the aspx pages being VB.
Go figure!
Hope I saved someone some time. I spent many hours on this.
You have 3 options here:
Convert the ASP.NET Web forms from VB to C#
Convert your MVC 4 written in C# to VB.
Develop all old apps in ASP.NET Web forms again to MVC 4 (ugly but better for future changes)
My advise is keep them diferent projects only share your business logic. And in the same solution file.
I have an ASP.NET application that provides both front-end services (visualizations) and back-end services (data transformations and outputting some data from back-end SQL databases). I would like the following:
Extensible Back-end
Enable someone else to upload a "plugin" to enable additional REST API to be added
Extensible Front-end: I have the front-end currently with a top URL bar like this:
Category-1 Category-2 Category-3
--App11 ---App21 ---App31
--App12
I am looking for something like this: Assuming that my app has a simple admin panel, when someone uploads a compatible "module" with a manifest file, the app should add that into the main application and add a link to one of the categories based on what the plugin manifest says. Optionally, add a description of this plugin to the main application web page.
Specifically, I am looking for suggestions on the following:
How should the main application be structured?
What should the architecture of the plugin be like?
How do I enable a dashboard like design and let the plugin support it?
I have seen this in Joomla, a content management system but am not sure what is the design paradigm to be followed to enable this. I did a dumb thing and designed my currently (huge) application as separate aspx files linked from a main app. I don't mind rewriting parts of it but without a major rewrite, is it possible to achieve what I desire? Any suggestions on how to achieve this?
A basic solution:
Pretty close to bare-metal, but for back-end, you can create a dll, that contains the logic, and an HttpModule that registers new GenericHandlers to handle requests. Either use web.config to register plugin modules, or use Microsoft.Web.Infrastructure.DynamicModuleHelper to register your http modules at runtime just by copying into your bin without modifying web.config.
PortableAreas:
MVCContrib has a feature called "PortableAreas" that can be used to package UI and backend code into a dll like a plugin. MVC controllers can easily return HTML content for UI, and JSON or XML, to act like a REST web service. Also MVCContrib defines a "Bus" that can be used by plugins to communicate with the host app. Like "Hey, add a new link to categoryXY that points to me!".
Take a look at these blog posts about portable areas: asp net mvc portable areas via mvccontrib (talks about MVC2, but works in MVC3 as well). The latest version can be downloaded via nuget: MvcContrib.Mvc3-ci.
ASP.NET MVC is just "ASP.NET"
Therefore webforms and MVC can live in the same application.
Take a look at this article about "consuming a portable area with a web forms application". Basically it's just adding MVC related dlls and configuration to your existing application, and setting up communication.
Or really take a look at a real CMS,
maybe using one that has a working, documented plugin system is the real solution. Depends on what percent of the features would be part of the "core app", and what percent would be developed as plugins and your needs.
I don't use the ready made MVC template by VS10, I create an empty web application then create folders: Models, Views, Controllers and would like to create a simple MVC web application from scratch, I don't find any tutorial about this online, I have created the DB for my application, I need what next steps I should do to make a login/logout sessioned web application runnable on the browser.
Phil Haack has a really empty MVC project template http://haacked.com/archive/2012/01/11/a-really-empty-asp-net-mvc-3-project-template.aspx. The bare minimum.
As for authentication why can't you use the default project template which has a working example. If you really don't want to use it, search online. Lots of examples of how to implement authentication. If you have a specific problem with authentication, ask another question here.
The really empty MVC project template is a good start. I'd nuget the jquery, jquery.validation also.
About authentication , I'll give you some hints to research: FormsAuthenticationTicket, FormsAuthentication.Encrypt/Decrypt, Response.Cookies, FormsAuthentication.SignOut (sic), asp.net pipeline events