0
votes

When I run a REST API written in .NET Core 2.0 that uses HttpSys from within Visual Studio 2017, I get the following output:

Exe path : C:\Program Files\dotnet\dotnet.exe Directory : C:\Program Files\dotnet Connection string : Server=(localdb)\mssqllocaldb;Database=MyApp;Trusted_Connection=True;MultipleActiveResultSets=true Hosting environment: Development Content root path: C:\Users\Torsten\source\repos\MyApp\MyApp Now listening on: http://*:5000 Application started. Press Ctrl+C to shut down.

When I run the same application from the command line with

dotnet myapp

I get this output:

dotnet MyApp.dll Exe path : C:\Program Files\dotnet\dotnet.exe Directory : C:\Program Files\dotnet Connection string : info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0] User profile is available. Using 'C:\Users\Torsten\AppData\Local\ASP.NET\DataProtection-Keys' as key repository and Windows DPAPI to encrypt keys at rest. System.ArgumentNullException: Value cannot be null. Parameter name: connectionString

Why is the connection string not recognized when started from the command line?

The connection string is defined in appsettings.json as:

{
  "ConnectionStrings": { "DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=MyApp;Trusted_Connection=True;MultipleActiveResultSets=true" },

And the Startup.cs reads:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        var pathToExe = Process.GetCurrentProcess().MainModule.FileName;
        Console.WriteLine("Exe path : " + pathToExe);
        Console.WriteLine("Directory : " + Path.GetDirectoryName(pathToExe));
        Console.WriteLine("Command line arguments :" + String.Join(", ",Environment.GetCommandLineArgs()));
        Console.WriteLine("Connection string : " + Configuration["ConnectionStrings:DefaultConnection"]);
        services.AddDbContext<MyAppContext>(options =>
            options.UseSqlServer(Configuration["ConnectionStrings:DefaultConnection"]));
        services.AddMvc();
    }
2
You'd have to ask whatever is creating Configuration, because that's the one that's not initializing properly. Dependency injection is fun!Jeroen Mostert
Are you running the command from the application's directory? configuration loading defaults to the current working directory..Martin Ullrich
Yes. I am running it from the application directory.tobre
I also tried with Start-process -FilePath dotnet.exe MyApp.dll -workingdirectory . Same result.tobre
That looks like PowerShell, though. The current location in PowerShell is not the same as the current directory in Windows. Try an [Environment]::CurrentDirectory = pwd first.Jeroen Mostert

2 Answers

2
votes

The reason why the ConnectionString could not be read, is, that the appsettings.json does not get copied to the output directory by default. Only if you configure Copy to Output Directory as Copy if newer or Copy always does it get copied to the output directory. You can tell the difference by looking at the env.ContentRootPath in the Configure method.

When started from within Visual Studio, ContentRootPath is the project directory.

C:\Users\Somebody\source\repos\MyApp\MyApp

When started from the command line, ContentRootPath is the output directory.

C:\Users\Somebody\source\repos\MyApp\MyApp\bin\debug\netcoreapp2.0

0
votes

Rerun, from the project folder, the dotnet command with -v switch to see results. If you are seeing references to ...\microsoft.entityframeworkcore.tools.dotnet\1.0.0.. the problem is with CLIToolReference which must be updated.

I had the same issue when I was migrating a project from an older version of asp.net core. After migration the DotNetCliToolReference is not automatically updated. Update the yourproject.csproj file to use the 2.0.0 version of the CLI as shown in the snippet bellow:

<ItemGroup>

        ...
          <DotNetCliToolReference 
               Include="Microsoft.EntityFrameworkCore.Tools.DotNet" 
               Version="2.0.0" />
</ItemGroup>