I downloaded the latest aspboilerplate. In documentation
it lists 3 tenant resolvers.
document ask to add;
Configuration.Modules.AbpWebCommon().MultiTenancy.DomainFormat = "{0}.mydomain.com";
to get domain based tenant resolving.
I am using hosts file to simulate actual URLs. So, I feel the app config should be something like below (apart from above code change to Abp module);
"App": {
"ServerRootAddress": "http://server.mydomain.com",
"ClientRootAddress": "http://{0}.mydomain.com",
"CorsOrigins": "...."
},
But the documentation doesn't mention anything related to that. So, I don't think the documentation is complete.
Then in IIS, I have two sites.
API site : server.mydomain.com. Bindings set to server.mydomain.com
Client site : mydomain.com. A new binding will be added such as subdomain.mydomain.com for new tenant(s). So basically in IIS for client site there can be many bindings with different subdomains portion, but pointing to the same site.
Then I ran the api site xxxx.web.host.exe. I assume it should pick the correct urls to listen to from appsettings. But it doesn't. it shows;
Now listening on: http://localhost:5000
And I am not sure where its coming from since there is no reference to that in code.
How can I get this properly configured to run on IIS with subdomain based tenant resolver?
Actual issue(s) were outside of what I have thought. In brief;
https://edi.wang/post/2018/12/27/path-caveat-with-aspnet-core-22-iis-hosting is one issue which crashed the app at the very beginning. Reason is it was loading log4net config file at Startup() and because of the way asp.net core 2.2 works, in IIS inproc mode it can't find the file.
https://weblog.west-wind.com/posts/2019/Mar/16/ASPNET-Core-Hosting-on-IIS-with-ASPNET-Core-22 this helped a lot to understand and tackle the issue.
Make sure you don't mix 32bit 64bit when hosting in IIS.
Related
So we've run into this really weird issue with the URLs on which we want to host our APIs.
We are currently using ASP.NET Core (.NET7) and Kestrel on Windows for self-hosting. We have a certificate and usually everything works as expected.
We typically use the URLs:
"http://abc.ourdomain.com"
"https://abc.ourdomain.com"
this works very well.
If we switch to only use a single:
"https://abc.ourdomain.com"
it works as well.
However, if we switch to only multiple https URLs:
"https://abc.ourdomain.com"
"https://def.ourdomain.com"
none of them works!
Unless we also add a http for either of them:
"http://abc.ourdomain.com"
"https://abc.ourdomain.com"
"https://def.ourdomain.com"
Then they all work!
Which URLs we use are set using:
app.Urls.Add(url)
And we use:
builder.WebHost.ConfigureKestrel(serverOptions =>
{
serverOptions.ConfigureEndpointDefaults(listenOptions =>
{
listenOptions.UseHttps(/*cert info*/);
});
});
to configure Kestrel.
We've tried with https redirection on and off. No difference.
So basically, to sum up it seems like we need at least one http endpoint OR only one single https endpoint. This this makes no sense.
Can someone explain what is going on?
It turns out that this was just the tip of the iceberg of issues we ran into. Coming from .NET Framework 4.8 using OWIN and migrating to .NET7 and ASP.NET Core.
I don't consider this a solution to the problem stated above, we simply never solved it. However when having expectations such as:
those above
being able to host multiple servers on the same port (different URLs)
make it work on older windows servers (Kestrel only worked on 2022 for us)
use registered certs automatically
etc
then Kestrel simply isn't the way to go. Once we switched to HTTP.sys it all worked like a charm. Sure this makes us bound to Windows, but that is the case for us anyway.
There are some good information on how to set it up and what HTTP.sys provides that Kestrel don't here:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/httpsys?view=aspnetcore-7.0
Please note that I am not suggesting HTTP.sys over Kestrel in general. But it solved our scenario and I hope this info helps others trying to do the same upgrade and are stuck!
I am creating a web app in Zend Framework 2. Deployed it to a Zend Server 6 gear in OpenShift using Zend Studio 12, to my surprise when I tried the url: http://myapp-mydomain.rhcloud.com I got a page with info on the Zend Server itself, then I logged in to the server at http://myapp-mydomain.rhcloud.com/ZendServer/Login to realize that the app was created to run in this url: http://myapp-mydomain.rhcloud.com/MyAppName.
This is definitely not what I wanted, since the users won't like (I bet) having to write the address plus the app name as a subfolder (/MyAppName). I know that when adding the DNS config the name will be shorter, but still will look like "http://myApp.com/MyApp", it doesn't make sense to me, it is like having to type the Google Url like "http://google.com/app" that is not nice (for saying the least).
Is there any way I can configure Zend Server, OpenShift Gear, maybe .htaccess or something like that in order to avoid having to use the subfolder part of the url and having this app as the default for my Zend Server Cartdrige?
This may sound simple but I have been researching this for hours. Probably I am too much into the problem so that I can't find the solution (even with lots of coffee), I'll appreciate any help/comments.
Thanks.
I have deployed an ASP.NET MVC 4 application to a new site I have created in IIS 7.5, which I have bound to port 8080. I can reach it by navigating to http://localhost:8080, but I want to reach it via http://localhost/MyWebsite.
I have added a Virtual Directory under my website, which points to "C:\inetput\wwwroot\MyWebsite\". However, when I navigate to http://localhost/MyWebsite, I am presented with a configuration error:
"It is an error to use a section registered as
allowDefinition='MachineToApplication' beyond application level. This
error can be caused by a virtual directory not being configured as an
application in IIS."
Here is what my IIS hierarchy looks like (this is a demo since I have no internet access on the server I am working on).
I have two questions:
Why am I getting this error?
Is this the best way to go about achieving what I want? It seems messy to have the list of files and folders underneath the website and then again underneath the Virtual Directory. If there is better practice then please tell!
Virtual Directories cannot execute scripts, reason why you are getting that error. You need to make your MyWebsite folder an Application. Also, you don't necessarily have to create a separate website for your website, you can use the Default Web Site and create an application MyWebsite in there (it might be less confusing maybe?).
I'm trying to set up one of my Drupal sites to push a node to another Drupal site in a multi-site configuration. It looks like I need to do this with services somehow, but I can't find any tutorials out there and I need at least to be pointed in the right direction.
What I believe I need is set up Services on the receiving site to accept a call from the sending site which will be sending the node object via Json or serialized PHP using a Key that was set up on the receiving site. Can anyone show me an example of this working or give me some insight?
thanks
have you checked out the deploy module on d.o (drupal.org)? It's a great tool to push changes (also nodes) from one installation to another. It uses the services module for the communication.
I have not tested it with a multisite installation, but I guess it should work if at least the domain names are different for each site.
Regards
Mike
I am setting up a 3rd party website which makes heavy use of httpHandlers. When configured as a virtual directory under Default Site on a 2003/IIS6 machine, everything works as expected. When configured as a standalone site on the same machine, pointing to the same directory and web.config however, httpHandlers do not work (404).
I have tried various changes to the path values of the handler's tags with no results. The pages themselves, and the application's code, all seem to execute find within the standalone site.
Any obvious things I might be missing?
Found my own answer, was a very simple thing.
An installer package had installed the virtual directory version of the site, and it had taken care of adding the file extension mappings. The standalone was manually configured and as such, I missed adding the mappings.
Resolved.