efcore: Scaffold error "Value cannot be null. (Parameter 'args')"

I am using command, “dotnet ef dbcontext scaffold “Database=sheshefcoredb1; server=lo_informix1410;UID=informix; PWD=IFMX4xxxx” Informix.EntityFramework.Core -o Models --project MyApp.csproj” to create models from tables of database sheshefcoredb1. However it reports error “Value cannot be null. (Parameter ‘args’)”, what am I missing? Below is stack trace, I tried to debug the “dotnet” by passing the argument “ef dbcontext scaffold “Database=sheshefcoredb1; server=lo_informix1410;UID=informix; PWD=IFMX4xxxx” Informix.EntityFramework.Core -o Models --project MyApp.csproj” and putting breakpoints in the file mentioned in the below stack, however the debugger doesn’t stop in any of the files/lines mentioned! Any help is highly appreciated.

D:\shesh\EntityFrameworkCore\scaffold>dotnet ef dbcontext scaffold “Database=sheshefcoredb1; server=lo_informix1410;UID=informix; PWD=IFMX4xxxx” Informix.EntityFramework.Core -o Models --project MyApp.csproj Build started… Build succeeded. System.ArgumentNullException: Value cannot be null. (Parameter ‘args’) at Microsoft.EntityFrameworkCore.Utilities.Check.NotNull[T](T value, String parameterName) in D:\shesh\EntityFrameworkCore\efcore-master-Informix\src\Shared\Check.cs:line 28 at Microsoft.EntityFrameworkCore.Design.Internal.DatabaseOperations…ctor(IOperationReporter reporter, Assembly assembly, Assembly startupAssembly, String projectDir, String rootNamespace, String language, String[] args) in D:\shesh\EntityFrameworkCore\efcore-master-Informix\src\EFCore.Design\Design\Internal\DatabaseOperations.cs:line 49 at Microsoft.EntityFrameworkCore.Design.OperationExecutor.get_DatabaseOperations() in D:\shesh\EntityFrameworkCore\efcore-master-Informix\src\EFCore.Design\Design\OperationExecutor.cs:line 123 at Microsoft.EntityFrameworkCore.Design.OperationExecutor.ScaffoldContextImpl(String provider, String connectionString, String outputDir, String outputDbContextDir, String dbContextClassName, IEnumerable1 schemaFilters, IEnumerable1 tableFilters, String modelNamespace, String contextNamespace, Boolean useDataAnnotations, Boolean overwriteFiles, Boolean useDatabaseNames) in D:\shesh\EntityFrameworkCore\efcore-master-Informix\src\EFCore.Design\Design\OperationExecutor.cs:line 502 at Microsoft.EntityFrameworkCore.Design.OperationExecutor.ScaffoldContext.<>c__DisplayClass0_1.<.ctor>b__0() in D:\shesh\EntityFrameworkCore\efcore-master-Informix\src\EFCore.Design\Design\OperationExecutor.cs:line 476 at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.<>c__DisplayClass3_0`1.<Execute>b__0() in D:\shesh\EntityFrameworkCore\efcore-master-Informix\src\EFCore.Design\Design\OperationExecutor.cs:line 617 at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action) in D:\shesh\EntityFrameworkCore\efcore-master-Informix\src\EFCore.Design\Design\OperationExecutor.cs:line 600 Value cannot be null. (Parameter ‘args’)

D:\shesh\EntityFrameworkCore\scaffold>

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 22 (10 by maintainers)

Most upvoted comments

@ErikEJ - Because their client (equivalent of SqlClient) is .NET Core only.

@deokershesh - As previously mentioned few times in this thread.

  • If you are trying to build provider by forking efcore repo, it will never reach completion. 3rd party EF Core providers need to consume Microsoft.EntityFrameworkCore* packages through nuget and not via direct source. Otherwise you will run in all sorts of assembly mismatch issues. Even if you get all your tests to pass in your provider tests, no one else can use the package.
  • If your provider is special that it needs to use .netcoreapp only, then forking even 3rd party provider would be painful too. Each provider is customized for it’s own needs and yours are different than what is out there. (Like you trying to build npgsql provider has 0 value. Neither you should be building it, nor filing for issues when it does not build).
  • Unless you are experienced with all the intricacies around structure of efcore (or even efcore.pg) repo for build related tasks, my advise is not get bogged with all that. That is the issue you are seeing while building efcore.pg right now.

Just create a .netcore class library which references your informix ADO.NET provider (through source project or nuget package is your choice) & Microsoft.EntityFrameworkCore.Relational package from nuget (this must be nuget package reference). And try writing tests against it. You can look into SqlServer provider source code for understanding of what needs to be implemented in your provider. Error messages in your tests would tell you what is not implemented in your provider and give you direction.

If you are not doing in above way then you are going to run into issue and it is not recommended way from us and I feel that it would be waste of resources for us trying to solve your issues of doing things wrong way which can be better used in fixing real bugs people have with EF Core as product.

I do not understand your need to change your EF provider library to .NET Core 3.1 - any .NET Core 3.1 app can consume/use .NET Standard 2.1 libraries.

As I said before, reference these packages in your library, which should target .NET Standard 2.1:

 <PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="3.1.7" />

In your functional test projects, reference:

<PackageReference Include="Microsoft.EntityFrameworkCore.Relational.Specification.Tests" Version="3.1.7" />

Why are you building a third party provider ? - my advice was to reference the NuGet packages.

In addition to the resources listed, you can follow the commit series in this repo: https://github.com/GibraltarSoftware/VistaDB.EFCore/commits/develop (a 2.2 provider, but will be very similar to 3.x and 5)

@deokershesh as a provider writer, I can only agree with @ajcvickers

The way to write a provider is to consume the EF Core Relational package.

This is exactly what I did in the two providers I wrote.

You cannot make changes to EF Core Relational if you actually want to ship your provider, but due to the extensible architecture of EF Core, anything you need to do differently from EF Core Relational can be replaced/overridden.

I addition, consume the specification test packages, and inherit them all.