Is possible to integrate orchard to existing Asp.Net MVC3 site like separate area?
Like this:
Web.proj
View
Controllers
Models
BackendArea
OrchardCMS files
As a result Orchard CMS will be using for storing resources (strings, images ets.) of main site and easy to manage resources.
Problems:
I don't whant to use virtual folders
on IIS.
Orchard CMS used own Global.asax,
web.config, earlier version of
NHibernate and different
IOC(Spring.net is used for main site)
Given the architecture of ASP.NET, not really or at least not cleanly. From what it sounds like, you are really just trying to use the HTTP interface of orchard in a sub-uri, which is possible by setting up a reverse proxy and forwarding requests to a different app living on a different site. See carlosag's article for a basic overview. Here are some protips:
make sure you ignore the route you are going to reverse proxy -- you don't want ASP.NET mvc kicking in and trying to route it.
Use a virtual directory on the main site where you are reverse proxying. This is where you setup the url rewrites and such.
Setup the orchard "site" running in a virtual directory under your fake site with the same name as your virtual directory -- helps fool IIS into building URLs correctly.
The other way around will be a lot more likely to succeed. What you describe was a non-goal for Orchard.
Related
I am going to need to host multiple websites in IIS, but will not have separate URLs setup in DNS for each one. Because of this, I will not be able to use the Aias/CNAME functionality in IIS to redirect traffic to individual Websites in IIS.
Would it be secure enough to publish all of my web apps to the same Website in IIS?
Example: under Default Website, there is a folder for each individual web app:
-Default Website
--[folder for webapp1]
--[folder for webapp2]
--[folder for webapp3]
URLs used to access each web app:
www.mydomain.com/webapp1
www.mydomain.com/webapp2
www.mydomain.com/webapp3
Is this sort of setup secure or a good idea (best practices)? It seems like a simple solution to the problem of not having a separate domain name in DNS for every web app (website).
What do you think?
I don't see any issue with that approach, in a way it does simplify things quite a bit actually.
Sites being secure is not going to be affected by this. Of course each application would be under it's own pool, it's always a great idea to run like this.
This being said, your main website is going to run under it's own application pool and if there is a problem with it all your applications will be affected. That's the one thing I would pay extra attention to so you might want to not actually use that top level app pool for anything.
We have this web.api-project currently residing in api.mydomain.com. It is as a backend for a mobile app and also a superadminlike javascript application. We also have this new public facing website (using Umbraco CMS, in the same VS-solution) wich currently holds just your plain information (with pages like "about us", "get the app" etc) on www.mydomain.com
We've setup a asp.net membership across theese domains and are now looking to find a way to have the public site host pages like login, edit profile, start subscription etc. The controller(s) for theese views exist in the web api-project. Views would presumably exist in the MVC-project.
I am not sure what approach to take. I would preferably be able to use the viewmodels that already exists in the solution and leverage the whole Modelstate/validation-thing, returning View() from the WebApi-project etc.
We could make our edit profile-forms just to POST to the api-project (CORS is a no-go), but then the api project would have to use the hackish Request.CreateResponse in order to redirect the user to some hardcoded place back on the public site, right?
Thanks.
When I've used web-api to talk back and forth to a front-end umbraco site I've tried to make it as dumb as possible and that seems to work well. It feels wrong to couple up you web-api project to do more than send data when requested, using web-api controllers to affect the UI/Views of a website sounds wrong.
Have you considered using Umbraco Members & then configuring them to use asp.net membership (http://our.umbraco.org/wiki/how-tos/membership-providers/how-to-integrate-aspnet-membership-control-with-umbraco) - in that way the Umbraco front-end can deliver tailored stuff to asp.net membership authenticated users without all the to-ing & fro-ing from your web-api?
I have published my asp.net MVC web application under the “Default web site” inside IIS. I actually added two versions of my web application:-
one directly under the default website and it can be accessed by typing http://servername
one under presaging path , and can be accessed by typing http://servername/prestaging
so I got confused on which approach it is recommend to add my asp.net web application, and what is the difference between adding my web application under the default web site, or creating a whole new web site ?
Thanks
This has more to do with organization within your company's IIS structure than right and wrong. If the site you built truly is the only site on the server, putting it on the Default site is not looked down upon.
But if the application is a sub application of the default site, the latter approach is the more appropriate approach if you only get to access the site from the //servername URL.
If you have a separate domain, myapp.servername.com, you can install it into the default iis site and add a binding or you could create a whole separate web site.
Has more to do with your structure than right or wrong.
Edit
To answer your comment, creating the site under the default web site will make the URL in most cases be: 'http://myservername/MyApp'. Creating your own application would require (in most cases) a separate binding address, 'http://myapp.myservername.com' It is really only affecting the URL you place in your browser and nothing else. More complicated setups are possible, but for most cases, these are your two options.
Now I'm working with ASP.NET (web forms) and Admin for this site is site itself, but located in folder inside existing site. I have some impression that it's not very good, for example if you publish external site with option "delete existing files", it deleted internal site. My question: is it okay if one site located inside another, or I should move it?
Let me paraphrase question: is it bad or good practice to have nested sites or nested projects?
I cannot give you an official answer.
Just as you don't feel right about it so do I.
Publishing websites in nested existing website folder is just not a good idea especially with admin site.
However if for some reason the Admin site has to be inside of the existing site, then it would make sense to make the admin site part of the existing site project so you just publish one project.
There is no right or wrong answer, so here is my two cents.
It is fine having another website inside a website as long as you can figure out the web.config. (Sometimes, inside web.configs collide with outside one)
It is fine as long as you are not hosting in Azure. The problem in Azure is you will have to put them in a same package.
Only draw back is as you said you cannot publish application straight from VS using delete existing files option.
Case Study
One of the popular open source shopping cart - nopcommerce have two separate Web Applications - Nop.Web and Nop.Admin.
It lets you place Admin site under Admin folder if you want Admin features.
I'm going to come out and say this is worth avoiding in general and moreover you can get the same outside effect (nested urls) without the hassles of having web configs inside of web configs.
What I would do is build separate sites and if I wanted things to appear to be nested I would use a reverse proxy (which can easily be IIS using ARR running on the same box) to front things and manage public urls.
I am making this in a proactive attempt to head off any potential problems which could arise from this. The situation is that we are developing an ASP.NET application for a client which will handle the online ordering from their customers. This application is going to be using the same database that their current WinForms application uses (no real issue here).
At the same time we are developing a new front-end website for them using DotNetNuke. The DotNetNuke app will simply be linking to the ASP.NET application for the customers to submit their orders (no need for them to communicate back and forth, etc.)
The plan is to host both applications on the same box at the client location. What I am looking for are potential problems or setup tips which would prevent possible conflict between the two apps (web.config conflicts, etc.) Is there a problem with having both hosted on the same location, how should IIS be set up, etc.?
If there are any external resources also available which could address this, please feel free to link them as well.
Option 1: Make all the apps separate virtual directories off of the root website. Then have the root document redirect you to the proper subdirectory for the default application for that website(DNN).
Option 2: (DotNetNuke in root, other site in subdirectory) There will be many issues with web.config inheritance if the new application is not built with DotNetNuke, but you can get around these by blocking inheritance of the root web.config. Basically you add the following to your root web.config(DNN) file.
<location path="." inheritInChildApplications="false">
<system.web></system.web>
</location>
Option 3: As Scott said, create seperate sites with differnt subdomains and link them together. You can setup a redirect so whatever.com/order sends a user to order.whatever.com.
Just an FYI, if you use
inheritInChildApplications in DNN 4.7-4.9.2 (haven't verified 5.0) you will run into ScriptManager errors, previous versions of DNN don't have the problem.
We host a DNN site for our corporate site on the same Windows 2003 server with a bunch of other sites (.NET 2.0, SugarCRM, and even some WordPress instances with PHP extensions in IIS). These sites are 'separate' websites, and not subwebs of the default site. It's a real melting pot, and it works well. We did create some separate app pools for the PHP, .NET 2.0, and .NET 3.0/5 sites to ensure that they did not foul each other.