I setup a Kentico CMS to host multiple sites and I'd like to know if it would be a good practice to setup multiple website in IIS using the same code base? I'm using IIS 8 on Windows 2012 R2
Chel,
I don't think having multiple IIS applications point to a single codebase is a good idea. Kentico will add/update/delete several files within your application folder as part of it's normal processing. Having multiple IIS applications performing this action on the same folder on the file system will introduce complications and errors due to file permissions and access rights.
You could set up your solution a few ways, depending on how you wanted to manage your applications.
Single IIS application / Host Headers
In this scenario, you would have a single IIS application / folder. All sites would be delivered from the same codebase. All traffic would be redirected to the same IP. In your IIS configuration, you would use host headers for each URL you wanted to send to your site. In Kentico, you would have a license / domain alias for each site you wanted to server.
PROS
This set up would give you a single codebase to manage your applications. This can simplify a good bit of your maintenance and hot fixing.
CONS
If you have to restart any of your sites for any reason, all of your sites will go down at once.
Separate codebase / IIS application for each site
In this setup, you would replicate your codebase for each site you wanted to deliver. You would create an IIS application for each codebase, configured for the appropriate URL. Each domain would be directed to the appropriate IIS application.
PROS
Can isolate your application. Can provide the ability to use different .NET frameworks / configurations for each app.
CONS
Several codebases to maintain. Updates to all sites require duplication of code across all codebases.
Personally, I would recommend option 1 if all of your sites are on the same .NET framework and it is not critical if they have to be restarted. If any of them are critical LOB applications, you may consider branching that one application off to it's own IIS application pool / codebase.
Related
lets say I have two ASP MVC applications.
ProjectXXX
ProjectYYY - this is fork of ProjectXXX.
Both projects have same structure (project/assembly name), but it differs on some functionality (it will be deployed for other countries).
For testing purposes we deploy both applications on one server.
ProjectXXX - has own IIS pool
ProjectYYY - has own IIS pool
Problem
When I removed some functionality from assembly of ProjectXXX and run ProjectYYY it throws TypeLoadException : Could not load type 'Project.Namespace.IMyInterface' from assembly 'Project.Namespace'
It looks like ProjectYYY uses DLL from ProjectXXX (IIS (asp.net?) loads dll once, because it "thinks" assemblies are the same?)
How to force IIS not to cache those assemblies and load the proper one for both apps?
EDIT / SOLUTION:
I have found, that my application uses MEF composition. As for now I have changed how it searches for assemblies and problem looks like gone :)
if you create separate IIS Site for each, it should do the trick, as for each site a separate w3wp process is run. Having said that, you can't share same ip and port for 2 sites so if you need that, you'll have to play around with redirecting, url rewriting on IIS.
I have developed a well-decoupled website using WebAPI and AngularJS as follows:
SOLUTION
|—— WEB.API Project
|—— Website pages Project
'—— Other projects related to functionalities
This setup is on my own computer.
Now I'm here wanting to deploy to my web server (iis 7.5, privately owned, WebDeploy installed). It is possible to deploy both projects on a single web site? (other projects are class libraries, so no hassle)
For what I know, I have to deploy the WebAPI part to a website, and the UI part to another website. May I put them on a single website?
You can put the Web API project in a virtual directory under the main web site. That's what we are actually doing in our current project.
You can, but you should be worried when files conflict. If both projects have a web.config for example, this could break either of them.
If not, it should be possible, but I wouldn't immediately recommend it. I would split them off in separate virtual directories so you can maintain the two separate projects easily.
You could also self-host the Web API using OWIN, so you wouldn't then need to set up a project in IIS etc and you could then have multiple clients talking to the same API.
There's a tutorial here which is more advanced.
I have a near identical project setup. Personally I picked 2 separate apps, I have a multi server setup with load balancers - the choice may have been different if I had a single server or low amount of expected traffic.
This gives the advantage:
I expected my WebAPI to have a larger amount of traffic than the web pages, due to mobile clients also consuming the WebAPI as well as the front end webpages. Because the API is in its own website, it has its own app pool - this means that each application has its own resource pool (app can grow to use more memory and CPU better), not shared like they would be on a virtual directory.
Disadvantages:
Because there is two separate app pools, I have one bound to port 80 and the other to port 8080. As I had a large server farm to roll this out on, I already had a load balancer in front of the webservers - hence to make the URL pretty (i.e. drop the port 8080 from the URL) i added a load balancer config to allow traffic to come in on a given url on port 80 and be redirected to port 8080 on the internal webservers. This isn't really a issue if you don't mind ports in your URL's.
. .
We have a growing need where web resources (files, documents, images, etc.) need to be shared between different web environments.
I'm looking into setting up symlinks to support this, but I don't know how to set it up. (Or would it be better to set up virtual directories? Part of my question is, what are current best practices to set this up?)
For example purposes, assume:
The environment is running on an IIS7 platform, and MUST be in a Windows environment.
The shared files need to be maintained using TFS.
The web sites occupy different sites on the same IIS instance and reside on the same physical server.
The sites are multple web platforms -- for example, one site is ASP.NET, while another is running classic ASP.
All sites are under the same corporate umbrella, which is why resources need to be shared.
All sites pull data from the same SQL Server database instance.
How would I set up a symlink to support this? Or, for that matter, are symlinks the best way to go about this?
Thanks in advance!
Edit: Addendum to the above example: my classic ASP environment can also include ASP.NET virtual subfolders. For example, I can have my domain www.somedomain.com running in classic ASP, but have a subdirectory (www.somedomain.com/dotnetapp) running as an ASP.NET application. The virtual directory used by the ASP.NET must be able to access the same file resources as the classic ASP environment.
On Windows virtual directories are more the standard way to do this. It also allows you to use IIS' virtual directory features and Windows/IIS rights management.
One of our clients has a Java EE application. We would like to develop a new project using ASP.NET/C# by hosting the application as a sub directory under this Java EE project.
My questions are:
Will the .NET application run smoothly?
Do I need to keep anything in mind before I make a promise to the client?
The way you strucure your projects do not affect the behavior of your applications at all.
However in the end, each of the compiled and not compiled resources need to be configured propoerly to their proper Web Server, you shouldn't have any problem at all.
IIS has its own directory and Tomcat(or whatever you are using) will have its own directory.
Just let him understand that there is no sense on sharing the projects in a single root folder if the projects are not going to be related at all.
The only way to make them interact is by means of services and queues that you can orchestrate in any of both technologies.
UPDATE
let's suppose that:
you are using default of both web servers: your IIS need your applications to be copied to c:\inetpub folder whereas tomcat uses the $CATALINA_BASE system variable to locate their own folder. That won't be a problem at all.
Now, let's suppose that your client chose the same exact folder to be the root of your websites in tomcat and iis, (very bad maintenance decision by the way)
you could also separate both environments by having two folders : JAVA and DOTNET
Now let's suppose your client won't accept any logic suggestion, and you have to merge java files and aspx files, technically there won't be any issue because each web server will handle requests for very different issues, however, if you are also using the same resources, let's say a picture used in both pages, you will have locked-files issues, your iis can only respond for its own behavior and tomcat will only respond with its own behavior.
So in summary, technically speaking it could work, performance will be hit on your hard drive, it all depends on the request loads of each app, but overall it is a bad infrastructure design.
hope it helps,
I have been struggling with the best way to make sure that the certain XML configuration files stay synchronized between multiple servers in a Web Farm. I am not necessarily concerned about the Web.Config, as much as I am concerned about some of the other configuration files that are present in the application.
For example, we store caching policies in an external XML file, where it has its own schema, and will soon have its own tool to maintain the values. Once the changes are applied, they should be migrated across the farm.
Some scenarios that I have considered so far:
RoboCopy, replication, or equivalent. This requires that work only ever be done on a particular node of the farm. (Push to application.)
Configuration Server. All external configurations and their tools are stored on a physical instance of IIS. The application will retrieve these configuration files on application start and periodically poll for changes. (Application polls.)
Team Build. We could host the tools in-house and set up a post-build process to deploy the files. (Application polls.)
Database Storage. Applications could read and poll database for configuration. (Application polls.)
All of these scenarios have their pros and cons. I am not sure what the best solution is, although I think having the application poll for changes might be the cleanest approach. Still, the question is which way would you best consider this to be accomplished?
I have web cluster running Windows Server 2008. To keep everything synchronized I'm using a DFS share that is on each of the members. Any changes made to any of the members are replicated to the others. I'm also using the IIS "Shared Configuration" feature to store my metabase within this DFS share. That way all of the IIS settings are replicated as well.
On a project that I worked on, we used a product called ServerSync to replicate files on the farm. It works pretty good and it is -fast-.