We want to develop a new ASP.NET Web-Application and if its somehow possible we want to take ASP.NET Core. One of the reasons for this wish is, that we fell in love with ASP.NET Core Identity.. But one problem is, that Identity depends on Entity Framework and Entity Framework Core still has some unimplemented features that we´ll need (https://github.com/aspnet/EntityFramework/wiki/Roadmap).
I´ve found an article in which the author provides possibilities to use Entity Framework 6 with ASP.NET Core (https://learn.microsoft.com/en-us/aspnet/core/data/entity-framework-6). The recommended way of using EF 6 and ASP.NET Core is, creating a new dll targeting .NET Framework 4.6.something and put all the EF-stuff in it. Since this approach is our plan for data-handling in general, the Identity-Data need to be accessed too in some way. And there are many specialized EF-functions for Identity (e.g. AspNetCore.Identiy.EntityFrameworkCore), making authorization/authentication stuff better, easier, faster, handier - what ever.
But using different Frameworks (or even worse different versions of one Framework) for accessing the same database, or accessing the same data twice at two different places with different technologies is not the kind of wiping the slate clean, that we thought of.
May be I am completely stumped and this is pretty clear but I don´t really have a clean way or acceptable approach for this problem right now.
Any ideas?
I would look at Brock Allen's IdentityServer4 if I were you. Here https://github.com/IdentityServer/IdentityServer4 and here http://docs.identityserver.io/en/release/ for documentation.
You will even find some blogs on the msdn site recommending it.
https://blogs.msdn.microsoft.com/webdev/2016/09/19/introducing-identityserver4-for-authentication-and-access-control-in-asp-net-core/
I think you will find its a much more complete solution.
To quote from the MSDN blog;
IdentityServer4 allows building the following features into your
applications:
Authentication as a Service Centralized login logic and workflow for
all of your applications (web, native, mobile, services and SPAs).
Single Sign-on / Sign-out Single sign-on (and out) over multiple
application types.
Access Control for APIs Issue access tokens for APIs for various types
of clients, e.g. server to server, web applications, SPAs and
native/mobile apps.
Federation Gateway Support for external identity providers like Azure
Active Directory, Google, Facebook etc. This shields your applications
from the details of how to connect to these external providers.
Focus on Customization The most important part – many aspects of
IdentityServer can be customized to fit your needs. Since
IdentityServer is a framework and not a boxed product or a SaaS, you
can write code to adapt the system the way it makes sense for your
scenarios.
Related
I'm using ASP.NET Core 6. I have multiple apps:
uri
user
tech
www.example.com
visitors (landing pages, products, about us, contacts, etc.)
razor pages
api.example.com
-
webapi (to support blazor apps)
app.example.com
customers
blazor wasm
staff.example.com
staff
blazor wasm
I wanted everything in one server app - which is possible, but complicated; I managed to get some of it working. There are many questions (here and in the aspnet repo) for this approach - its popular because deployment seems simple and self-contained (but many people struggle with this, and many questions don't even have working answers).
I realised that even if I succeed, there are many moving parts (the config is a nightmare!), many things that could break in production, and someone else might have to maintain it.
So maybe it's better to have separate (dockerised) apps.
Pros:
simpler implementation
simpler maintenance
easier to scale (especially read-heavy apps, e.g. www and blazor apps, which could even be moved to a CDN)
better division of labour (different team members responsible for different apps)
from personal experience the "www" public website changes more often (sometimes daily) than the "api" web app, so pushing changes to production requires updating everything - whereas if separate then one only pushes changes to individual apps
easier to isolate faults: if something fails or must be taken down for maintenance, the problem is localised and other parts of the system continue to function
Cons:
complicated deployment
more monitoring and health checks
...?
If you've dealt with this, in production, please share your experience. I've no idea what to expect.
I'm interested in the core problem: is serving everything from one server app asking for trouble, or is it a worthy (and maintainable) goal? Thanks!
The answer is yes. While the core web server config is more complicated, you only really have one site.
The razor pages and API are standard server side code that can co-exist on the same site. You can apply whatever authentication schemes to them you wish.
The two WASM sites only need a web server to serve up their startup files. After that I assume it's all API calls back to the server.
There's an answer I wrote a few months ago with a Repo that explains how to set up a server to serve two WASM sites. Create a multiple WebAssembly projects in a single solution
There's also a couple of articles on Codeproject describing how to do it - search "CodeProject HYDRA".
I am having an existing ASP.NET MVC application running in production. Now my customer came up with a new requirement/enhancement, and he wants to develop it with ASP.NET Core MVC. New enhancement will be a new standalone module. And after development completion, he wants to integrate it with existing ASP.NET MVC application.
I wanted to know that, is it possible to integrate these two applications, because ASP.NET Core is completely different framework rewritten from scratch, and old application uses .NET Framework 4.6.x.
Any help or any kind of link that guides me on this will be very much appreciated.
Thanks in advance.
Anand Neema
Your question is actually quite broad, because "integration" is a broad topic. It covers many different aspects of the application and the exactly methodology depends on the an intimate knowledge of those applications.
That said, generally speaking, ASP.NET MVC and ASP.NET Core are completely separate platforms. You cannot "integrate" them in the sense of how you use to be able to simultaneously run Web Forms and MVC code in the same ASP.NET MVC project. They will be two separate applications that will need to be deployed independently.
You can "share" the connection string, which is to say you can share the database, but you will need to make a number of decisions in that regard. For example, if the current MVC project uses EF6, you will need to also use EF6 in the Core project in order to share the same entity classes. That means, for the moment, targeting .NET Framework, rather than .NET Core. However, .NET Core 3.0 promises to run EF6 natively. Alternatively, you can use EF Core and treat the database as existing, scaffolding in the entities. This will result in some code duplication, but may be an acceptable compromise, depending on the circumstances.
Things like sessions, cookies, and auth can be shared, but it may require fundamental changes to the ASP.NET MVC project. Namely, ASP.NET Core uses data protection providers for encryption and decryption, rather than the machine key approach of ASP.NET. However, via its support of OWIN, ASP.NET MVC5 can also support data protection providers for encryption/decryption. As such, if you switch over to using data protection there, and share the key ring between the two apps, then each will be able to decrypt things encrypted by the other. However, if you aren't already using data protection in your MVC app, then the change could be somewhat painful.
If you only care about sharing auth, that can be achieved alternatively via a centralized auth provider such as Identity Server. That would allow the two apps to operate independently of each other but still share a common user/role store and support SSO. However, that too, may require some substantial changes to the existing MVC app. It's all trade-offs.
I'm relatively new to programming and I have some questions. I'm currently simultaneously trying to learn ASP.NET MVC from the official Microsoft book because I'm looking to get the certification in a few months and at the same time working on a small project for a colleague. Instead of doing things with .net framework i decided to just do everything in .net core and there are some discrepancies between what I learned in the book and what seems to be available in EF Core.
I'm using Sqlite for my database and I've already plugged that in for the most part but I'm running into some issues where various people on the internet are providing me with conflicting information.
So in the .net framework version of ASP.NET, the way Microsoft said you should do things is, You have a Model PersonModel and a context PersonContext that goes in the Model file and inherits DbContext. This PersonContext contains various DbSet<T> objects depending on which tables you want to make etc. This has remained the same for me in .net core. However after this Microsoft tells me to make a PersonInitializer which is supposed to inherit DropCreateDatabaseAlways<PersonContext> and then override the Seed method (conveniently thats also where a getFileBytes method is placed for images etc).
Now, in core, there is no DropCreateDatabaseAlways class to inherit, leading me to believe this structure is actually not intended at all by .net core. I've heard various things on here about using various CLI commands but in the end I'm basically just very confused about what the "proper" thing to do is here?
It think your largest problem at this point is just sourcing information properly. Admittedly, it's a bit confusing, especially for someone completely new on the scene.
A little background to start: there's ASP.NET, ASP.NET MVC, and ASP.NET Core. ASP.NET is really nothing, although it became short hand for ASP.NET Web Forms, as that was the only thing you had to work with at the time. Then, Microsoft introduced ASP.NET MVC, which took the foundation of ASP.NET and layered on an attempt at a modern web application framework modeled after the MVC (model-view-controller) pattern. It was a vast improvement over Web Forms, but did not fundamentally break away from the older system enough to make it a truly great application development framework. Because of it's reliance on System.Web (a monolithic family of DLLs) and the full .NET Framework, it was slow, hard to deploy and completely incompatible with things like containerization. Enter ASP.NET Core, which was a complete rewrite from the ground up.
ASP.NET MVC had a sister framework in ASP.NET Web Api, and technically you could still employ ASP.NET Web Forms in the same project. In fact, a single project could utilize all three frameworks at once, which is as convoluted as it sounds. ASP.NET Core, at least initially, did away with this confusion by just having a single system for both traditional web applications and APIs. As such, if you're looking for information about Core, it's just "Core". Looking for ASP.NET Core MVC is just going to lead you to outdated information.
That said, frustratingly, Microsoft decided in their infinite wisdom that Web Forms, though reviled by most every developer who had ever used a real web application framework, were actually so awesome that they should be resurrected, at least in spirit. Thus was born Razor Pages, and ever since it's been necessary to make a distinction between ASP.NET Core Razor Pages and ASP.NET Core Proper, which has now been relabeled as ASP.NET Core MVC, making it that much more difficult for people to filter out information on one framework versus another. At least for the time being, Razor Pages are still not as prominent as the MVC-style, and thankfully, they at least don't change much in the core functionality of Core to warrant differing discussions on most things. Long and short, you should pretty much just prefix every search with "asp.net core" (in quotes, so it's done as a phrase search). That will generally always give you relevant information - for the most part.
The next set of issues is that ASP.NET Core was developed with high visibility, fully out in the open and with many, many previews, alphas, betas, and even full releases. On the one hand, that's great and is a large part of why it's as good as it is. Developers were able to provide input and steer the development, making it the first web application framework developed by Microsoft actually designed by and for the people actually in the trenches, building web applications.
The downside, though, is that things changed - a lot - and still do. Though, it now seems to be leveling off pretty well after 2.1, which I consider to be pretty much the first truly feature complete release. However, before we got here, we had ASP.NET vNext, ASP.NET MVC 6, DNX, and then ASP.NET Core 1.0, 1.1, 2.0, and finally 2.1 - all of which fundamentally changed at least how some things work. In other words, even if you confine your searches to ASP.NET Core, there's still a lot of outdated and incorrect information out there, simply because it was written about a previous version and things have changed since. To better your odds, you should consider confining your search to things published within the last year (2018+, 2017 if you can't find anything newer). Any older than that, and you're going to have to take the article with a big, huge grain of salt.
And then that brings us to Entity Framework. Oh my. EF has had a storied history, most of it steeped in failure. The original EF wasn't even viable until version 3. The previous versions were so bad they were literally unusable for any serious production work. Even then, it wasn't until EF 4 that it could really even be consider truly ready for prime time, and finally began having some significant uptake among developers as a result. It was also the release where Code First was finally introduced (technically in 4.1).
Before that time there was what the EF team referred to as Database First or Model First. The only meaningful difference was that one would generate your models from an existing database, while the other would let you design your models and then generate a database from that. In either case, you ended up with a monstrosity called EDMX, an XML beast that attempted to keep up with your database state and all the translation of VB/C# classes to that entails. It was an absolutely nightmare to maintain, almost never worked correctly, and a constant source of frustration.
Code First provided an alternative - a shining light in the darkened pit of EDMX hell. You could use POCOs (plain old class objects) and EF would be able to generate migrations from changes you made to those to update your database accordingly. It could even be used to work with existing databases, though it's name prevented it from being used as much as it should have been in that area (many people wrongly believe that if you had an existing database, you had to continue using the old horrible Database First methodology). In truth, Code First was a complete alternative approach to managing databases, both new and existing. EF 5 and EF 6 continued to refine this new approach, and when it came time to work on EF 7, Microsoft decided it was high time EDMX went to its well-deserved grave.
However, work on EF 7 coincided with the development of ASP.NET Core, which itself spawned off .NET Core and eventually .NET Standard. EF was firmly rooted on the full .NET Framework, so it became apparent that a rewrite was in order. As such, development of EF 7 was cancelled, and EF Core was born. EF Core, though, had a rough ride. ASP.NET Core was moving along like a freight-train, but had no native way to interact with databases. You could use old EF, but then you were forced to target the full .NET Framework, instead of .NET Core. As such, EF Core was rushed to release way too soon, and 1.0 was a train-wreck of epic proportions. There was so much basic functionality missing and the workarounds were so obtuse that virtually no one in their right mind actually would take anything into production with it. Then, 1.1 was release and things improved somewhat but still not enough. Then came 2.0, and finally, it was workable ORM, you could actually feel comfortable using in production. The release of 2.1 has brought even more improvements and refinements.
Now that you've had your history lesson, all I can say is that finding good documentation is still unfortunately a bit of a crap-shoot. You need to be very specific with your searches, using the right terms (which is part of why I wanted to give you the history). You also need to pay close attention to dates. Consider suspect anything that existed before 2017 and treat even stuff from that year with a grain of salt. The official docs are your best friend. Microsoft has actually done a pretty fantastic job with their documentation and keeping it up to date and accurate. It covers the largest majority of things is the ultimate source of truth.
Official ASP.NET Core Docs
Official EF Core Docs
Books are not going to be your friend here. The publication process takes far too long and ASP.NET Core has moved far too fast. Any book on Core is outdated the minute it hits the streets. However, if you have a subscription to Safari Books, you might have luck due to their prelease and alpha offerings there. You have to deal with more technical mistakes, grammatical errors, etc., but at least the information will be closer to the actual truth.
Pluralsight has some truly excellent videos that can help you. Unfortunately, video production has a similar problem as book publication, and there's more than few courses that are now so outdated as to be useless.
Hope this at least gives you some better context and helps improve your ability to source good and accurate information. Honestly, I still struggle myself with that a lot of times, and I think most developers working in this space has the same issue. It's fun and exciting, but it's not without its cons. Having to wade through a sea of information to find some pearls is one of them. Good luck.
I have a very large asp.net MVC 4.0 application that I'd like to start migrating to Web API with asp.net 5.0 and Angular 2.0.
The main reason is to start future proofing and setting up some new components into a more modern SPA architecture.
My plan is to have a small section of the existing site which when routed to displays an Angular SPA app calling Web API for data, instead of the MVC controller and functions. For this section, I'm not planning on using ASP.NET MVC features such as the shared layout page, bundling, routing etc, preferring to instead leave this to angular.
Both my existing MVC and new Web api projects will be using the data layer project/repository which uses EF.
My questions are:
How does this sound? I couldn't find much literature on how to introduce angular into an existing app
Should I use separate projects, or a whole separate solution on a new domain which accesses the same db? Ie, rather than migrate, start a new solution on ASP.NET 5.0
How to I handles authentication and authorisation? I'm using Identity v2.0, can I mix that so that users accessing pages on the MVC site use standard forms based authentication, but when accessing the Angular/ API portion they use tokens?
Thanks for your time.
We've been in this process for last 6 months (the only difference is Angular, rather than Angular 2). And here is my opinion...
a small section of the existing site which when routed to displays an Angular SPA app calling Web API for data, instead of the MVC controller and functions
Extremely difficult, if not impossible, since ASP.NET Core is fundamentally very different from MVC 4. I would suggest to have a separate site (on a different port) that runs Core and Angular.
I'm not planning on using ASP.NET MVC features such as the shared layout page, bundling, routing etc, preferring to instead leave this to angular.
That was our first approach, but in order to accomplish it, we would need to pre-load a lot of Javascript libraries, or do smart things for dynamic loading. It is easier in Angular2 (SystemJS that allows dynamic loading is built into the infrastructure). Instead, we split the application into about half-dozen features. Each feature has a .NET controller and a single view (Index.cshtml). Within the feature we use Angular capabilities for routing, views, etc. This approach also helped us to have strongly typed views.
Should I use separate projects, or a whole separate solution on a new domain which accesses the same db?
Entity Framework is also quite different. In our old (very old) solution we didn't use EF at all, so it was an easier decision. But even if you do use EF in current solution, EF Core is also a different animal, including the way it does migrations. It was much easier for us to have a clean cut.
How to I handles authentication and authorisation?
Our old system was using membership framework, and we didn't have anybody on the team familiar with OAuth. So, while waiting for IdentityServer 4 (that currently has almost no documentation), I suggest you consider SaaS solutions like StormPath or Auth0 (we love StormPath). If you have experience with IdentityServer, you may jump into IdentityServer 4. Since we are using MVC, our authentication is very straightforward; but I think AJAX-based authentication wouldn't be that much more difficult.
Hope that helps. SO doesn't like "opinion-based" questions - but I think there are a lot of teams struggling with this type of transition, and hopefully, this question and answer are appropriate :)
Is it possible to self-host an ASP.NET MVC application and/or OData service in a stand-alone workstation app? Are there any successful examples of doing this?
I would like to create a suite of data-centric applications using .NET that are targeted to EITHER a solo/home user OR a team. Unfortunately, I am the only developer. Comparing front-end technologies of WinForms, WPF, and ASP.NET MVC, I am most proficient with ASP.NET MVC. I would also not like to write multiple implementations of my data service.
(Commenting in lieu of voting down as my profile cannot yet vote down.)
You really need to do some research here. Almost any service-oriented .NET technology can be self-hosted... WCF web services, OData, etc. Your bigger concern should be performance. The more layers you add to your app, and the more times you transform or "serve" your data, the more cycles will be spent processing your data. What you may find is that you users become less happy with the performance compared to a snappy compiled UI hitting a simple business or data layer.
In short, yes, this is possible. However, I would save this type of app for one-off / in-a-pinch apps with either a short life expectancy or very minimal client usage (settings panel, etc.).