Open Closed

License check failing when running from Visual Studio #2100


User avatar
0
filipendo125 created
  • ABP Framework version: v4.4.0
  • UI type: Angular
  • DB provider: EF Core
  • Tiered (MVC) or Identity Server Separated (Angular): MVC with IS integrated
  • Exception message and stack trace:
[11:05:03 ERR] ABP-LIC-0008 - License check failed for 'Volo.Abp.LanguageManagement.HttpApi-v4.4.0.0'.

You need to log in using the command `abp login <username>`.

For more information, contact to license@abp.io.

[11:05:10 INF] Initialized all ABP modules.

[11:05:10 FTL] Unable to start Kestrel.

System.Threading.Tasks.TaskCanceledException: A task was canceled.

   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken)

   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
  • Steps to reproduce the issue:" We have developed a Dockerfile, which correctly generates a container, but we are facing issue as we are unable to get the container working with Visual Studio, as it is crashing on a license check.

I have found this ticket: https://support.abp.io/QA/Questions/69/ but upon using the suggestion with firstly setting the value to ASPNETCORE_ENVIRONMENT I still didn't manage to make it work.

I have created within HttpApi.Host, the following code:

internal static IHostBuilder CreateHostBuilder(string[] args) =>
            Microsoft.Extensions.Hosting.Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    var variables = Environment.GetEnvironmentVariables();
                    Log.Information($"Value of environment is {variables["ASPNETCORE_ENVIRONMENT"]}");
                    webBuilder.UseStartup<Startup>();
                })
                .UseAutofac()
                .UseSerilog();

Our Dockerfile looks as follows Dockerfile

FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
WORKDIR /app
EXPOSE 80
# EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src

COPY ./*.sln ./NuGet.Config  ./

# Copy the core source project files
COPY core/*/*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p core/${file%.*}/ && mv $file core/${file%.*}/; done

# Copy the main source project files
COPY src/*/*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p src/${file%.*}/ && mv $file src/${file%.*}/; done

# Copy the test project files
COPY test/*/*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p test/${file%.*}/ && mv $file test/${file%.*}/; done

RUN dotnet restore "NA.OrderManagementSystem.sln" --configfile "NuGet.Config"
COPY . .

RUN dotnet build -c Release -nowarn:msb3202,msb3277,nu1503  -o /app/build --no-restore
RUN dotnet test -c Release -nowarn:msb3202,msb3277,nu1503 --no-restore --logger:trx

WORKDIR "/src/src/NA.OrderManagementSystem.HttpApi.Host"

FROM build AS publish
RUN dotnet publish "NA.OrderManagementSystem.HttpApi.Host.csproj" -c Release -o /app/publish -nowarn:msb3202,msb3277,nu1503  --no-restore

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "NA.OrderManagementSystem.HttpApi.Host.dll"]

I then have run two experiments: One using the following Docker launchsettings.json

"Docker": {
      "commandName": "Docker",
      "launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
      "httpPort": "30321",
      "useSSL": false,
      "DockerfileRunArguments": "--network na.oms-network --name oms-backend -e \"ASPNETCORE_ENVIRONMENT=Production\""
    }

(the dockerfile argument with Production is required to overwrite the Development default flag)

and I have also ran the following command:

docker build -f "C:\dev\ordermanagementsystem\src\aspnet-core\src\NA.OrderManagementSystem.HttpApi.Host\Dockerfile" -t "test" .
docker run -dt -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -e "ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS=true" -e "ASPNETCORE_ENVIRONMENT=Development" -p 30322:80 --network na.oms-network --name oms-backend2 -e "ASPNETCORE_ENVIRONMENT=Production" test

Both of them produce Value of environment is Production, and the container inspection shows me that the value of the ASPNETCORE_ENVIRONMENT is indeed Production in both, yet the one from the VS crashes on license validation, but the one launched from PS runs just fine.

Things I have also tried:

  1. I tried to run the VS generated from the Powershell using the above command, but that doesn't seem to do the job and the container doesn't even get up. However, this is most probably due to the configuration that VS is generating as they are attaching volumes to the container to enable debugging (see docker-compose.vs.debug.partial.g.yml)

However, the question still remains: If I set the ASPNETCORE_ENVIRONMENT to Production, why is the check still being performed on the VS side, but when run from the PS it also states Production and the app builds.

Could you possibly help us with this?


4 Answer(s)
  • User Avatar
    0
    filipendo125 created

    Is there possibly any update on this?

  • User Avatar
    0
    alper created
    Support Team Director

    hi sorry for the late response, this issue has been asked a couple of times. can you check this post https://support.abp.io/QA/Questions/69/#answer-d8bebebb-b714-3c1e-7fcb-39f437bc8ba3 also this https://support.abp.io/QA/Questions/1471/containerizing-abp-application also https://support.abp.io/QA/Questions/1081/Deploy-abp-to-docker

  • User Avatar
    0
    filipendo125 created

    Hi @albert, although this is fine, the links still don't provide the clue to my issue.

    In my scenario mentioned, I am running my code in Debug mode, but I set the environment to ASPNETCORE_ENVIRONMENT=Production yet the check is still being performed, which according to the tickets should not be the case.

  • User Avatar
    0
    alper created
    Support Team Director

    the condition is DEBUG Mode or ASPNETCORE_ENVIRONMENT=Development. so you are running in debug mode, therefore you need to login via ABP CLI in the virtual computer or you can copy the authentication cookie to the target computer.

    You need to copy the following file (which has your account information inside)

    %UserProfile%\.abp\cli\access-token.bin
    
Made with ❤️ on ABP v9.1.0-preview. Updated on December 13, 2024, 06:09