I have our legacy ASP.NET web forms application. I need to create new pages and I want to use the APS.NET Core MVC project for those new pages. Is this possible? How It can be done?
Just to add, I don't need to keep the state b/w pages from both projects.
I tried to create a separate MVC core project (under the same solution) but can't figure out how to do the routing between them.
Edit: I know this is possible by using MVC .NET Framework. My question is specific to MVC Core.
No, you can not. While the objects used by the request pipeline seem very similar between the Asp.Net and Asp.Net Core, they are in fact totally different objects which come from totally different namespaces. The two are totally different pipelines that don't interact in any way. So at the end of the day it's either going to be one pipeline listening for incoming web requests or it's gonna be the other. You can't have both trying to process the web request for your web application.
By way of contrast, in the Asp.Net when using the Full framework you can have Web Forms and MVC both coexist no problem. This is because both use the same request pipeline that lives in the System.Web namespace. So while the way they respond to the request might be a bit different, they both use the same HttpContext object. This is not true of Asp.Net Core. It uses a totally different HttpContext object located in the Microsoft.AspNetCore.Http namespace.
You may also find my answer for this question informative: Is it at all possible to migrate ASP.NET ASPX solution to ASP.NET Core 2.0?
I have created 2 separate projects a Web API and MVC as a Web Client. I wanted to add an external login for my web client, and now I'm confused on which project I should put the Identity stores.
By the way I am using .Net Core 3.1 with VS Code as my editor.
This question is not complete (there is not enough information on how You going to use API).
In most cases, the .Net Core Identity system should be used in an API, since often APIs contain the main logic of the application being implemented, and clients are just interaction interfaces (of which there can be several, for example, a mobile application and a web interface).
You also mentioned that You are using VS Code as code editor. It doesn't have built-in code generation capabilities like VS does, but you can still use dotnet CLI codegenerators (e.g. ASP Identity scaffolding).
What is the major difference between Asp.Net Core SPA and separate them into Asp.Net Core WebAPI + independent web app. Here is my 2cent that separated solution looks no diff with using SPA template but the former makes backend code and folder structure more clear. Does it have any advantage to use Asp.Net Core SPA template?
WebAPI + independent web app benefits
Hosting : You can host your web app on low cost hosting solutions e.g. AWS S3/Azure blob storage.
Cloud native : Depending on your solution you can use cloud native technologies very easily . e.g. if you are using Serverless APIs , this kind of architecture works best in that case.
Flexibility : Your solution is hosting agnostic. Which means you publish apps on-prem or anywhere , as long as API contract is the same it will work.
Separate UI Team : UI team can focus solely on web app with out knowing anything about backend.
ASP.NET CORE SPA benefits
Better integration : Like someone mentioned you don't have worry about CORS.
Out of box Authentication/Authorization : If you are using ASP.NET CORE you can use out of box authentication solution. In the case above you have to write and implement your own authentication/Authorization logic. Also If you are deploying your solution to Azure. You can use Identity-tokens instead of Access-token to access your APIs which is handy.
SPA
Using SPA template I can use built in Angular or React with ASP.Net
Core without worry about CORS error, I can publish Angular app into
production mode if I want by just clicking publish website in Visual
Studio. Using SPA you can provide rich experiences for user. Using
Angular SPA template is also support Server Side Render which is lead
to performance improvement and build in Angular CLI support.
WebAPI + independent web app
You can easily seperate everything into smaller piece so that you can
manage and scale up easily but it come with a cost maybe you have to
host different kind of service in different domain and let them work
together
So depend on what you need you can choose between thoose 2
I have an application developed in ASP.NET MVC 5 using EF6. My client needs some forms of that web app and reports on an android app. I just learnt that using ASP.NET 5, one can develop cross platform apps. How can I use my existing MVC 5 controllers,views and models with Web API to make an android app?
I have no experience with asp.net 5 and android development. I have studied a bit on internet that if I expose my data via RESTful API then I can make an Android app.
Regards.
Any web application or service can make functionality available via REST API. This basically means that you can control it and get data via GET, POST and other requests.
This means that it will be very difficult for you to expose anything but data, like controllers or views.
Since with the REST web service your app would need to be online anyway, you could just wrap your website inside an android app, similar to what BNK said or using other technologies, like a native view - should not make much of a difference.
Then basically, you have your web site (or a modified version thereof) hosted inside an android app.
I am creating a new MVC4 project, and research has lead me to believe that communicating from javascript to the server side is better achieved now through web API framework rather than controller actions. Is my understanding correct on this?
I am presuming that I can share all my attributes etc between web API and MVC controllers so on the face it, it does not seem a massive change for me.
When I am setting up applications, I like to split components out in to projects. My plan was to have a MVC project and a web API project. But I have ran in to issues. For example I have ended up with 2 apps as such, separate routing set up etc etc.
So my question is, in a MVC application should the web API framework sit within the same project, or should the web API be separated into a project of its own and work around the issues?
Unfortunately you are wrong about that - I am presuming that I can share all my attributes etc between web api and mvc controllers so on the face it, it does not seem a massive change for me.
Many of the concepts used by Web API and MVC, even though similar at first glance, are actually not compatible. For example, Web API attributes are System.Web.Http.Filters.Filter and MVC attributes are System.Web.Mvc.Filter - and they are not interchangeable.
Same applies to many other concepts - model binding (completely different mechanisms), routes (Web API uses HTTPRoutes not Routes, even though they both operate on the same underlying RouteTable), dependency resolver (not compatible) and more - even though similar on the surface, are very different in practice. Moreover, Web API does not have a concept of areas.
Ultimately, if all you are trying to do achieve is to have a "new, trendy" way of serving up JSON content - think twice before going down that path. I certainly wouldn't recommend refactoring any existing code unless you are really looking into embracing HTTP and building your app in a RESTful way.
It all really depends on what you are building. If you are starting a new project, and all you need is to serve up some JSON to facilitate your web app - provided you willing to live with some potentially duplicate code (like the stuff I mentioned above), Web API could easily be hosted within the same project as ASP.NET MVC.
I would only separate Web API into a separate project if you are going to build a proper API for your online service - perhaps to be consumed by external customers, or by various devices - such as fueling your mobile apps.
IMO, security and deployment should drive your decision. E.g., if your MVC app uses Forms authentication but you're interested in using Basic authentication (with SSL) for your API, separate projects are going to make your life easier. If you want to host yout site at www.example.com but host your API as api.example.com (vs. www.example.com/api), separate projects will make your life easier. If you separate your projects and subdomain them accordingly and you intend to leverage your own API from your MVC app, you will have to figure out how to deal with the Same Origin Policy issue for client-side calls to your API. Common solutions to this are to leverage jsonp or CORS (preferably if you can).
Update (3/26/2013): Official CORS support is coming: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API
After some degree of experience (creating API for apps and for mvc). I mostly do both.
I create a separate project for api calls that come from other clients or other devices (Android/IOS apps). One of the reasons is because the authentication is different, it is token based (to keep it stateless). I do not want to mix this within my MVC application.
For my javascript/jquery api calls to my mvc application, I like to keep things simple so I include a web api inside my MVC application. I do not intend to have token based authentication with my javascript api calls, because hey, it's in the same application. I can just use [authorize] attribute on a API endpoint, when a user is not logged in, he will not get the data.
Furthermore, when dealing with shopping carts and you want to store a users shopping cart in a session (while not logged in), you need to have this in your API as well if you add/delete products via your javascript code. This will make your API stateful for sure, but will also reduce the complexity in your MVC-API.
Steven from SimpleInjector (IoC framework) advises two separate projects: What is the difference between DependencyResolver.SetResolver and HttpConfiguration.DependencyResolver in WebAPI
I have recently done almost the same thing: I started with a new MVC 4 web application project choosing the Web API template in VS2012.
This will create a Web API hosted in the same application as MVC.
I wanted to move the ApiControllers into a separate class library project. This was fairly easy but the solution was a bit hidden.
In AssemblyInfo.cs of the MVC 4 project add similar line of code
[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]
Now you need the class LibraryRegistrator (feel free to name it whatever)
public class LibraryRegistrator
{
public static void Register()
{
BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
}
}
In the MVC 4 project also add reference to the Api library.
Now you can add Api controllers to your own separate class library (yourown.dll).
Even if your project is so complex as to warrant two "front ends" then I would still only consider splitting out webapi into a separate project as a last resort. You will have deployment headaches and it would be difficult for a newbie to understand the structure of your solution. Not to mention routing issues.
I would aim to keep the system.web namespace isolated in the one "presentation layer". Despite the webapi not being presentational it is still part of the interface of your application. As long as you keep the logic in your domain and not your controllers you should not run into too many problems. Also, don't forget to make use of Areas.
In addition to setup the separate DLL for the Web.Api.
Just a Suggestion:
Create the Project
Nugget WebActivatorEx
Create a a class Method to be called upon app_start
[assembly: WebActivatorEx.PostApplicationStartMethod(typeof(API.AppWebActivator),"Start")]
[assembly:WebActivatorEx.ApplicationShutdownMethod(typeof(API.AppWebActivator), "Shutdown")]
Register a web.api routes inside the Start Method
public static void Start() {
GlobalConfiguration.Configure(WebApiConfig.Register);
}
Reference the Project to the Web Project. to activate the Start Method.
Hope this helps.
I tried to split the API controllers into a new project. All I've done is to create a new library project, moved the controllers inside folder named API.
Then added the reference of the library project to the MVC project.
The webAPI configuration is left in the MVC project itself. It works fine.