Reading Environment Variable Issue

[Urgen-Dorjee]

Why all of console app only read Hosting environment to Production, even though you are running these apps on debug environment, which should be running on Development environment i supposed. Even though when you set aspnetcore_environment value to development on command line by running following command but that does not make any different either. Therefore how would i tell these console app that we are running on development environment, so runs on this environment.

Command Prompt: SETX ASPNETCORE_ENVIRONMENT "Development" (specific project folder)
Result : SUCCESS: Specified value was saved.  

Console display

Application started. Press Ctrl+C to shut down.
Hosting environment: Production

HostBuilder configuration

var hostBuilder = new HostBuilder()
                .ConfigureHostConfiguration(configHost =>
                {
                    configHost.SetBasePath(Directory.GetCurrentDirectory());
                    configHost.AddJsonFile("hostsettings.json", optional: true);
                    configHost.AddJsonFile($"appsettings.json", optional: false);
                    configHost.AddEnvironmentVariables();
                    configHost.AddEnvironmentVariables("DOTNET_");
                    configHost.AddCommandLine(args);
                })
                .ConfigureAppConfiguration((hostContext, config) =>
                {
                    config.AddJsonFile($"appsettings.{hostContext.HostingEnvironment.EnvironmentName}.json", optional: false);
                })

Launch settings

{
  "profiles": {
    "WorkShopEventHandler": {
      "commandName": "Project",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

Projects are not configured in docker orchestrator support right now.

[EdwinVW]

Try pulling in the latest version of the master branch. I've changed the environment-variable prefix from "DOTNET" to "PITSTOP". This is also used in the launchSettings.json file. Set a global PITSTOP_ENVIRONMENT variable to Development to make sure all console apps run in dev mode.

[Urgen-Dorjee]

@EdwinVW Thanks for your quick help. I learnt a lot from this awesome project, and I wish if you could implement API gateway and Authentication into the project, since i have been learning micro-services and its underlying architectures design and patterns. Just one question, since your WorkshopManagement Project seems focus on DDD and particularly {WorkshopPlanning} class, which has more than one tasks to be taken care of therefore isn't it a violation of SRP or DDD would not go along with some of SOLID principles, and yes what if maintenance/scheduled job has be deleted, where does logic go.

I don't why whether you have noticed this or not, but i have faced one issue while working on it. When you configured your appsettings.json to https endpoint port where as your httpclient based url address point to http port . In this situation browser try to look for http therefore could not resolve the port and it says "awaiting on browser title" but if you look at networking under browser "protocol says pending.....". Last time when i try to register a customer and this was exactly happened as it stays there forever therefore I had to terminate the program, when I terminated the program, it came out with bunch of same customer inserted into the database, that was kind of weird, but some reasons i can't reproduce it again. How do we prevent such issue and how do we check and make sure that same customer information should not enter more than one in the database. I don't know whether these questions make sense to you or not however I really appreciate your effort on making this awesome project and hope you keep on updating it with newer technologies in future.

[EdwinVW]

Thanks @Urgen-Dorjee. Nice to hear you have learned from this sample application!

I did implement an API gateway once (using Ocelot and Consul). But I removed that when I started experimenting with Kubernetes. Adding authentication is on the backlog, but I haven't had the time or need to add it. Maybe I will later.

Regarding your question on SOLID: yes I could have split the handlers for the different commands in the WorkshopPlanning aggregate into separate classes to adhere more to the SRP. But because the logic of the different handlers is not very complicated and contains little code, I've kept them in 1 class. I usually start out like this and only refactor when things start to become "too big" (which is obviously subjective). So thanks for the tip. I will make sure I will address this if I expand the functionality in the domain in the future.

I have not experienced the connectivity issues you describe.