I am creating an MVC3 web application. It has an Administrator side and a Client Side. They will be hosted on SEPERATE servers. The client side will be available ONLIE via internet and the Admin will be an INTRANET application. There are certain views which will be used by both the the public and the admin areas. Where should I put them. Do I have to create 2 copies of the views in both applications or should I put it somewhere common and share it?
Thanks
This definetly can give you a good start point.
http://www.chrisvandesteeg.nl/2010/11/22/embedding-pre-compiled-razor-views-in-your-dll/
Related
I have inherited an existing ASP.Net MVC C# web application solution.
Currently, there are two separate Web Application projects.
An Admin site - used to managed the content of the public facing site.
The public facing site
Currently, the public facing site is not in production; only the Admin site is deployed on Windows Server 2012 running IIS 8.0 using the client's domain e.g. www.mysite.com
The client would like the public facing site and the admin site to be accessibile via the same domain:
Public: www.mysite.com
Admin: www.mysite.com/admin or admin.mysite.com
Is there any way to achieve this given the two sets of functionality are currently encapsulated in different Web Applications?
I'm wondering if:
Is there a way to achieve the above with sub-domains or some other feature of IIS
Or if its best to move all the Admin functionality into an MVC Area within a single Web Application
Discussions on the pros/cons of each approach (or links to resources) would be most appreciated.
I would rather move admin site and public facing site in single web app in separate area as OP said.
You can use host-header facility in IIS to adjust root domain url to admin.mysite.com (or such).
advantage of such approach is maintenance will be easier as code base is part of single vsnet solution, Assuming public facing site will have lot more content/controller/views and admin site will have less of those, there is no point in maintaining separate .SLN for admin.
I am facing one problem.
I have 1 Presentation Layer Project using ASP.NET MVC. There is another project for Database interaction for MVC Web API.
Question: Do I need two domains ? One for ASP.NET MVC Project and another for MVC Web API project ?
Two domains? No. However, given that you have two projects you will need two separate deployment locations. That means they'll either need to live at different subdomains (i.e. www.domain.com and api.domain.com) or under different virtual directories of the same domain/subdomain (i.e. domain.com/web and domain.com/api. You could put one of them in the root of the domain (i.e. domain.com for the MVC site and then domain.com/api for the Web Api, but you need to be careful at the point, as the Web.config for your MVC site will apply to any virtual directories under it, i.e. your Web Api.
I've a web site developed using MVC 4 ASP.net application. I'm new to .net platform & I want to add web service which would return me operating system name of users device based on certain input.
Assuming I've logic to capture OS information using inputted data, how do I go forward in building this web service?
Do I need to have a complete separate solution file which will have a web service or in existing MVC 4 asp.net application itself, should I create a new project which would be of type "WCF Service Application"? Again I don't know much about WCF service either, if I use it, how would the URL be accessible, etc?
Can anyone give me some insights?
Note: I've also a separate REST web service which is a completely separate solution with separate projects but deployed on same IIS.
Thanks in Advance!
You don't need to create a WebAPI project just for what you described (i'm assuming one or a few end points).
Simply use MVC controllers that return JSON for example, this way you deal with a single framework.
Reasons to move to Web API is if you need support for CORS, need content negotiation for results etc. From what you are describing it's completely fine to stay with MVC.
I currently have a ASP.NET MVC 2 web application and would like to enhance the architecture to support a SAAS model. I plan on eventually building a number of web applications so would like to design the system accordingly.
The goal would be that when a client would hit the following url clientxyz.domain.com they would see an image of all their subscribed applications. This would essentially be a web page with a bunch of application icons. Once a client would click on a icon it would navigate to that actual web app at the following example url clientxyz.domain.com/application_name.
We currently use GoDaddy to host our domain and plan on using a Cloud based iLand server to host our application. We only plan on a few new clients a year due to the nature of our software.
I have a number of questions:
Is it possible to programmatically create subdomains on the fly using a .Net api. I'm pretty sure GoDaddy does not let you do it. So is there another provider that would let me create subdomains via C#. This may be the wrong approach and may not even need to physically create client subdomains. Instead I may be able to accomplish this using url rewriting in IIS/MVC?? If I use rewriting, it would have to satisfy the url requirements mentioned above. Any suggestions/links/examples?
Should I create a separate IIS website for each tenant/client? Or should I use URL rewriting and simply have a single website / application pool? Looks like you can programmatically spin up IIS websites (example: http://www.eggheadcafe.com/tutorials/csharp/d4bba585-b517-4834-8476-ff05b085d86e/iis--create-app-pools-virtual-directories-and-web-sites-c-net.aspx)
Since we are using a Virtual Server on iLand do I simply have to point GoDaddy to the nameserver at iLand.
I would like to automate the entire new client process if possible. To accomplish this, I would have to created the database (probably going to have single db per tenant), populate the global client/tenant table, create admin user account and subscription details in newly created database and create subdomain depending on approach. Am I missing anything?
thanks in advance.
I'm building a .Net MVC app, where I'm using one particular view to generate an internal report. I don't want the users of the site to gain access to this page at all.
I've a console app that fires every so often which will scrape some of the details from this page by hitting it's URL.
I don't like the idea of having the URL hanging out there but I'm not sure of another way to go about it.
Thoughts on what might be the best practice way for tackling this?
Edit:
Here's what I ended up doing, created a new WCF Service project in the solution. I also copied basically what was the MVC view page into a new standard web forms page in this project. On top of adding security via the regular .net Authentication methods (eg set only valid windows users can access the page), I can also lock down the vhost to only be accessed by certain IP's.
The best practice would be to expose a wcf service for this, and set up a security model that is different than website.
If you must use MVC the best approach use forms authentication with mvc and set
[Authorize(Roles = "SecureUser")]
On the View.
If the view never needs to be rendered at all except to provide data for the console app, then why not have the console app simply connect to your database to get the data directly instead of going through the web app? You could still do this for the console app even if the view does need to be available for some users, then control access to the view using the Authorization attribute, which could suitably restricted now that an external app need not have access to it.