I want to create a custom registration/authentication module for DNN site. In the past I made a web application with a registration form, but then I used Entity Framework and IdentityUser class, I need to use DAL2 now. Is there a similar way to do this? Thank you
For this you will want to create an AuthenticationProvider. It is a special project type and will use the DNN API for any data elements.
The documentation on this model is quite light, but you could review the core authentication provider. There are also third party ones available with source that could be used for education.
This article is old, but looks to still be correct. https://www.dnnsoftware.com/community-blog/cid/134678/dotnetnuke-tips-and-tricks-12-creating-your-own-authentication-provider
Related
I want to migrate my asp.net (UI ASPX pages WebForms) application to ASP.NET Core 2. By some search I found out aspx is not supported in .net core. If this is true(anyone has exact documentation for this?) how should anyone proceed to convert from pure asp.net aspx project to asp.net core 2.0?
I used portable analyzer tool but it is confusing to just give every .dll file and get report which is more confusing.
Please give valid Microsoft document if possible.
It all depends on what you mean by "migrate". As mentioned in the comments to your question, ASP.NET Core does not support web forms so there isn't any way to just automatically convert an a Web Forms website to an ASP.NET Core website.
That said, it is possible to make the migration. I have been working to do just that for a very large web forms based website that I want to convert to ASP.NET Core. If you are serious about making the journey, then here is some info that will probably help you.
The general architecture of ASP.NET Core is based on MVC so it's much more similar to ASP.NET MVC than ASP.NET Web Forms. So you will end up rewriting pretty much all of your UI code using some derivative of a MVC pattern. Instead of master pages you will be using layouts. Instead of server controls you will be using tag helpers. Instead of user controls you will be using partials and view components. Instead of code behinds you will be using controllers and view models. Etc.
It's worth noting that there is still an http context object, request object and response object and they are extremely similar to the analogous objects in web forms. So that helps with the conversion.
Also to make the conversion process easier, you can build an ASP.NET Core web application that targets the full framework. This means that you will have access to most everything you are use to in the full framework except anything in the System.Web namespace. Targeting the Full framework does mean that your new website will only run on windows. But if you can live with that (at least for now) it will make the conversion process easier for you.
If, in your old website, you broke out a bunch of the functionality into class libraries, that will make your life easier. You should be able to bring those class libraries over to the new website unchanged and reference them from the ASP.NET Core website and they will most likely work fine provided they don't reference System.Web. Any code that does reference System.Web will need to be modified to use the new analogous objects or UI approaches.
So in the end, you may be able to bring over your data models, data access code, business objects, and business logic without too much hassle. But you will have to do a total rewrite of your UI related code. That's the journey I'm on and it's not as hard as you might think, at least not once you get up to speed with ASP.NET Core in the first place. Go get `em!
I found an article claiming that it's possible somehow.
As you know it's not easy to migrate entire project from WebForm to .Net Core instantly. So what if I be able to have my web form pages working on production and at the same time start to convert pages one by one gradually? I mean there are the combination of two approaches at the same project.
It's the idea that an open source named DotVVM proposes. You have your ASP.Net web form pages and merely install DotVVM through Nuget. DotVVM supports both approaches. DotVVM contains similar controls like GridView, Repeater, FileUpload and more, you need to know about DotVVM syntax though.
DotVVM can run side-by-side with other ASP.NET frameworks (Web Forms, MVC, Razor Pages)
it's claimed that:
If the business layer is separated properly, rewrite on one page takes about 1 hour in average.
After a few months (if your project is large), when all the ASPX pages are rewritten in DotVVM, you will be able to create a new ASP.NET Core project, move all DotVVM pages and viewmodels into it and use them with .NET Core. The syntax of DotVVM is the same on both platforms.
Here you can see five steps needed for the migration.
You can transfer all your business logic, models and even some controller methods (You just need to adjust those ActionResult to IActionResult). If you're using Ninject (for ASP.NET Framework IOS), you just need to register them to your Startup.cs. Basically, what I'm trying to say, you need to create a new application under .NET Core. It would be changes in the actual project solution, but your actual business flow won't be different. I hope this helps you.
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.
I have a Web API project (4.5) that has all the DTO objects stored in a separate project for simplicity. I was wondering if there is anyway to link from the Web API help page to these class libraries so that my end users can not only see what they need to send but so that they can see the XML comments on those objects specifying what each property of the object does/means.
I suppose you are talking on "WCF Web API Test Client",
AFAIK it uses Microsoft.AspNet.WebApi.WebHost.dll provided by Microsoft. The sources are not available but if it is not obfuscated you can change it after ILSPY.
Beside this you can't decorate it, normally you just redirect the page from global.asax.
Another option : Maybe you should write your own. But you will have much work with attribute reading and reflection :) Maybe you should start a project in CodePlex & git.
I found one .net wrapper for google maps api v3 here.
But in that link it has not mentioned weather it supports API V3 or not.
Also can some one point me towards using this dll in asp.net mvc 2 application?
Not sure how useful this answer is but here I go.
I wouldnt choose any wrapper out there without doing some research about the same. From the url that you shared looks like there is only 1 contributor to the project, also the dwnld count on the latest api is 117 which I dont think is a great number to warrant its use, there have only been 3 issues reported so far and from the looks of it they are inquiries or feature requests (not sure if it means that there are no bugs in the project or it hasn't been used).
Anyways having said that there are commercial wrappers out there which support google maps. I can think of ThinkGeo for one. see if that is within your budget.
Now to your dll question. Just adding a reference in your web project should do the trick and then probably creating a seprate controller that serves your map. Is that what you wanted?
.NET wrapper libraries for the Google Maps API :
GoogleApi
google-maps
https://stackoverflow.com/a/61531795
Many popular applications such as Wordpress, WHMCS and the majority of PHP forums allow plugins to hook into core application events (such as registration, logging in, create post etc.) by simply specifying a function with a particular name.
I understand that these applications are not pre compiled, but is it possible to do something of the sort with C#? I've looked into event handlers, but it seems that you can only accomplish this if the plugin has the ability to instantiate the class that we want to hook into (or at least thats what searching has lead me to believe)
Ideally, these hooks would be into business layer class events/methods and can be hooked into by multiple objects, so it would function in either WinForms or ASP.NET MVC.
Given Alex's answer, this should be useful:
System.AddIn Tools and Samples
http://clraddins.codeplex.com/
If you design your application for extensibility, this is easy. The Managed Extensibility Framework is designed for exactly this sort of scenario, and makes it very easy.
It will be included as part of the core framework in .NET 4, but is downloadable now for use in 3.5.
There is an AddIn framework shipping with .NET 3.5. The framework provides very powerful mechanisms to expose interfaces by a host application and to manage, dynamically load-unload addins etc.
Why the core concept that comes up to my mind first, is Dependency Injection? I haven't ever played with a plug-in system in any app of mine. Does DI could help anyhow with that??
Specifics on our senerio would be helpful, but generally, You may want to explore the provider psttern.
There are 3 components:
- An abstraction of a piece of functionality, (Interface/baseClass)
- A Factory method that looks to config to determine what type of Class to create
- [your] Custom Class which extends/implements the abstraction. for example, a Membership provider class that hits a custom dasta source for user info.
This is very useful when switching out logic. If you want to create an app with swappble UI components, it is another story.
There is support for this in ASP.NET, starting with 2.0.
More info on the provider:
http://msdn.microsoft.com/en-us/library/ms972319.aspx