I've made a custom MembershipProvider which uses DependencyResolver from MVC3 to find it's dependencies. It works great for MVC apps, but not for the Web Site Adminstration Tool.
Is there some way that I can hook into the Web Site Adminstration Tool request handling to be able to configure a container before it handles the request?
Membership providers should be interoperable and therefore should work just by plugging into the config file of any provider based app.
Web Site Adminstration tool does exactly this, it runs in it's own web application completely decoupled from your MVC app, and just references your provider.
To make this work you need to ensure all dependencies required for the membership provider are packaged in one assembly and bootstrap your IoC container regardless of the environment it runs in. You can code this in such a way to share MVC initialisation, but not depend on it.
Related
I am building an on-premise ASP.Net application, and want other parties to be able to extend what I have built without needing to recompile the application. Is there a way that you can add models, data access layers and web api controllers after the web application is compiled and deployed?
Thus far, I have developed a solution where I can manage the actual pages via a special web form and store the page template/css/script in the database.
What I am trying to achieve:
I currently have mobile apps on top of services and would like to add a web site on top of the same services.
Services details:
ASP.NET Web API project using OAuth (bearer token) and Identity for authentication and authorisation.
Microsoft.AspNet.WebApi 5.2.3
Microsoft.Owin.Security.OAuth 3.0.1
Microsoft.AspNet.Identity.Core 2.2.1
Mobile details:
Xamarin projects.
Xamarin.Forms 2.3.3.193
What architecture should I use for the web site?
Create a new ASP.NET MVC project and call my current services from the MVC controllers? This seems bad because:
I would have 2 layers of controllers (web site MVC controllers calling services API controllers)
I would need to store bearer tokens in cookies
I would need to manage the tokens and cookies expirations
Create a new ASP.NET MVC project and call current services database directly? This seems bad because:
I would have to duplicate the models in the services project and in the web site project
Create a new ASP.NET project and call my current services using ajax? This seems bad because:
I would need to create my own register/login pages
I would need to store bearer tokens in cookies
I would need to manage the tokens and cookies expirations
I would need to say bye to future social authentication (OAUTH2) implementation because I wouldn’t be using OWIN
Thanks,
fcorbeil
If you already have the API a brand new MVC app shouldn't be such a bad choice. If you have your models stored in a different project just reference them to the MVC one. As for the services, them would work perfectly with the new application. This all can be achieved without changing almost nothing to the current implementation.
I am working on a project and using a similar architecture.
I decided to create an Angular project for the website front end and all it does is talk to the Web API. Angular handles the JWT authentication really well. If you've never worked with Angular before, it is really nice to work with.
However, a vanilla ASP.NET MVC web app would work just as well.
It depends on how comfortable you are with Angular, or how willing you are are to learning it! :)
I have several asp.net website projects for various sites.
Currently I want to add REST API's to these projects so I can start developing mobile apps (using HTML5/JavaScript/CSS3 and PhoneGap) that make use of these webservices.
Since WCF is far more powerful than regular asp.net webservices (among others with control over the service and authentication/authorization), I'd love to add these to my existing website project.
I did a Google search but cant find anywhere a step-by-step tutorial how this can be done. And also if there's any functionality I'd possibly loose when adding WCF functionality
I was also thinking of creating a new project specifically for WCF, but think I'd rather add it to an existing website project.
Can anyone help me with this?
Depending on exactly what your needs are and how your current web site is configured, there are two approaches.
If you are using a Web Site Project, then you should create your WCF service in a different application:
1) Create a new ASP.Net Web Application Project.
2) Add a new item to the project and select the type of WCF Service or WCF Data Service.
When you deploy this project, you will deploy it to your web server, but not as part of your web site since configuring the web.config will be a large manual effort.
If you are using a Web Application Project, then you could add the WCF Service directly to your existing project. However, I only recommend this approach if you are Silverlight applets within the web site that rely on the user's authenticated credentials.
WCF can be configured with a lot of bindings and it can be configured to return xml or json(.net 4.0). Try to create a wcf service configured to use basichttpbinding or wsHttpBinding and to format the response as json and use jquery to interact with the wcf service. This article might help you http://www.codeproject.com/KB/aspnet/Cross_Domain_Call.aspx
I'm building an asp.net application that will be deployed on Azure. For the moment, I'm using regular asp.net: I'm building it in VS.
I have a web service that's in an asxm file MyService.asmx with a code behind file MyService.cs that calls a different class library called MyBigClass.cs that does most of the work.
If I want to prepare for a deployment on Azure in a few months and make that web service work in its own web role that I can scale based on usage load, should I put the classes that are in the MyBigClass.cs file into the MyService.cs file? The MyBigClass.cs file contains classes that are used for other parts of the application as well; should I remove these classes and only include the ones used by the web service?
Thanks.
Difficult to give a specific answer, and to be honest - I don't think the answer to this would be Windows-Azure-specific, but rather - this is simply a design best practice question, isn't it?
It comes down to how you will go about maintaining the application, and how you are going to manage versioning, but generally speaking - code that isn't shared does not need to get deployed to both roles, so either move it back with the 'parnet' solution (web app or service), or keep in a separate assembly which you will deploy with only the relevant role.
Code that is shared between the web app and service will exist in a shared assembly which you will deploy into both roles.
So you might end up with the following projects
A web site
An assembly supporting the web site
A Web service Service
An assembly supporting the web service
A shared assembly between the web site and web service
I hope this makes sense
If you create an ASP.NET web file project you have direct access to the Profile information in the web.config file. If you convert that to a Web App and have been using ProfileCommon etc. then you have to jump through a whole bunch of hoops to get your web app to work.
Why wasn't the Profile provider built into the ASP.NET web app projects like it was with the web file projects?
Actually, Microsoft does have a solution for this known issue.
It's the "Web Profiler Builder". I used it for my Web App and it works great.
http://code.msdn.microsoft.com/WebProfileBuilder/Release/ProjectReleases.aspx?ReleaseId=980
The profile provider uses the ASP.NET Build Provider system, which doesn't work with Web Application Projects.
Adding a customized BuildProvider
class to the Web.config file works in
an ASP.NET Web site but does not work
in an ASP.NET Web application project.
In a Web application project, the code
that is generated by the BuildProvider
class cannot be included in the
application.
source: MSDN Build Provider documentation