Well, launchSettings.json is a Visual Studio-only configuration file. It is only used when you are running or debugging the app from Visual Studio. At least that is how I understand it from Microsoft's documentation and my experience.
I don't believe that a web.config file is required at all for an Asp.Net Core API project. I don't understand why this one is in this project in the first place.
From my experience a web.config is only needed in a Core project (either API or MVC) when the project is published to an IIS web server. If the project will never be published to an IIS server, a web.config will likely never be needed.
Furthermore, during the publishing process, if not present, Visual Studio will automatically create the web.config file in the project's output directory and copy it to the IIS server. In this scenario the project will run on IIS but will never have a web.config in the project root. The publishing process just creates it in the output directory on the fly.
If there IS already a web.config file in the root of the project, then the Visual Studio publish will take it and make a copy and put in the output folder and then make some changes to the output copy that are required for the application to run on the target IIS server. But, the version in the root of the project will stay the same.
This is where the problem comes in with the current starting point of the AspNetZero project. The web.config that is already in the project root has ASPNETCORE_ENVIRONMENT=Development in it. So, that web.config is copied by the publish and that value is left as is when it gets sent to the IIS server. So, we end up with the application thinking it is running in development on the IIS Server and therefore uses the wrong appsettings.json file.
I believe the real solution is to remove the existing web.config file altogether from the root of the project. I think it is unnecessary and just causes a problem during publishing.
Anyway, that is the solution I am planning to test tomorrow.
Actually, I am not sure why that web.config file is needed in the API project in the first place. Can you please explain that to me?
I just create a plain ASP.NET Core 3.1 Web API project using the out-of-the-box VS 2019 template. It does not generate or require a web.config file to run using IIS Express on the dev machine:
Yes, it is an environment variable problem.
The fact that this web.config file ships with AspNetZero causes a System-wide ASPNETCORE_ENVIRONMENT=Production environment variable to be ignored on the IIS server when the web application runs:
I assume you ship the code this way because for debugging locally on IIS Express the web.config is needed and needs to be configured this way?
Anyway, it seems to me that for publishing the project to IIS one more piece of work needs to be done which is to set up a web.config transformation file per this page of Microsoft's documentation:
With an environment (or configuration) specific web.config transformation, the correct environment variable value would be used in each environment.
If you agree with my analysis, I think you should add this to your documentation on this page, because its a pretty big "gotcha" in my opinion:
https://docs.aspnetzero.com/en/aspnet-core-angular/latest/Deployment-Angular-Publish-IIS
Jeff
Well, now I have found a discrepency between Microsofts ASP.NET Core 3.1 CORS documentation and ASP.NET Zero's implementation - in the 8.5.0 code at least.
Here is what Microsoft shows for Core 3.1:
Here is what is in the downloaded 8.5.0 code:
That string variable is set to this value:
So, according to the 3.1 documentation it would instead need to be: options.AddPolicy(name: DefaultCorsPolicyName, builder =>
I am going to implement this tomorrow and see what results I get. I already implemented it in a small test application I built and IT DID solve the problem in that application.
I have been trying different experiments today and am starting to wonder if IIS (I'm using v10 with Server 2019) really works with native ASP.NET Core CORS infrastucture in the scenario that is required in order to publish and run a multi-tenant AspNetZero API + Angular application.
When I say "native ASP.NET Core CORS infrastructure" I am talking about just using the built-in ASP.NET Core CORS functionality of the application and WITHOUT having to also use the IIS CORS Module extension.
I'm referring to this extension:
https://www.iis.net/downloads/microsoft/iis-cors-module
I've never used that extension before, but I guess I am going to have to try it because I am not getting anywhere at this point, even though I believe I have followed Volosoft's documentation to the letter.
I guess the other option is to try to push the application up to Azure to see if it will run there, and that is our ultimate goal for production, but we also need an internal server that the system testing team can do pre-production testing on and that's why I need to get this to run on IIS as well.
Jeff
I had already tried that, but just tried it again. It doesn't seem to make any difference. The error is still "No 'Access-Control-Allow-Origin' header is present on the requested resource".
Here is the appsettings.production.json:
On the host logs this is still the same error message:
I'm using AspNetZero 8.5.0 and Angular. Also am using multi-tenant.
Everything woks fine in Dev environments. Now, I am trying to deploy to and run from an internal IIS server (not exposed yet to the Internet) that has ASPNETCORE_Environment=Production. No problems getting the Host website to load swagger and connect to the DB.
I have two static IPs on the IIS server - 1 bound to the Host website, 1 bound to the Angular website. Wildcard DNS is setup correctly. Certificates are set up correctly.
I've been trying to carefully follow all of the AspNetZero documentation. If I've missed something (or have a typo I am overlooking), I would certainly like to know.
On the Angular client from a workstation on the network I am getting a CORS error returned:
<br>
Here is the log entry from the Host log:
<br>
Here are my current configurations:
HOST appsettings.production.json:
Angular appconfig.production.json:
<br> I also have this code in my WebHostModule.cs PreInitialize:
Jeff
I meant to say, RAD Tool v2.2.1.1 - which is the new version released today.
Seems to work with RAD Tool 2.1.1.1.
Here is my TestEntity1:
This time the RAD tool changed\added 39 files.
Thanks for getting this fixed - at least for me. I know others will need to retry as well.
Yes, I will start working on it now and report back as soon as I know.
