public class EcommerceContext : IdentityDbContext<IdentityUser>
{
public EcommerceContext(DbContextOptions options) : base(options)
{
}
// use real database
services.AddDbContext<EcommerceContext>(c =>
c.UseSqlServer(Configuration.GetConnectionString("EcommerceConnection"),
x => x.MigrationsAssembly("Ecommerce.Web")));
PM> add-migration InitializeDb
Build started...
Build succeeded.
Unable to create an object of type 'EcommerceContext'. For the different patterns supported at design time, see https://go.microsoft.com/fwlink/?linkid=851728
In my case the solution had multiple startup projects. Anit was fixed by defining only one startup project.
Related
I followed the instructions in the Template repository to create the Resources database. But now I want to use a custom ResourceInitializer to add Resources to the ResourceGraph. (see my code below)
namespace MyApplication.Resources.MyResource
{
[ResourceInitializer(nameof(DummyInitializer))]
public class DummyInitializer : ResourceInitializerBase
{
...
}
}
But when I go into the runtime console and execute exec ResourceManager initialize, the initializer is not shown in the list:
Output in the runtime window
How do I get the runtime to show me the DummyInitializer?
The Initializers you see in the console, are the ones configured in the resource managers initializer collection. In the MaintenanceWeb you can add an entry for your initializer under: http://localhost/maintenanceweb/#/modules/ResourceManager/configuration?path=ModuleConfig/Initializers
or you can add it the underlying config file.
{
"Initializers": [
{
"PluginName": "DummyInitializer"
}
]
}
Alternatively you can execute it using the resource managers console at: http://localhost/maintenanceweb/#/modules/ResourceManager/console
I hope that helps, let me know if you need further help.
I define two objects:
data class ParserK annotated with #higherkind
interface ParserKFunctor annotated with #extension
Here is the code:
#higherkind
data class ParserK<A>(val f: (String) -> Option<A>): ParserKOf<A> {
companion object
}
#extension
interface ParserKFunctor : Functor<ForParserK> {
override fun <A, B> Kind<ForParserK, A>.map(f: (A) -> B): Kind<ForParserK, B> {
...
}
}
When I execute ./gradlew :app:kaptKotlin I get:
error: "Arrow's annotations can only be used on Kotlin classes". Not valid for error.NonExistentClass
> Task :app:kaptGenerateStubsKotlin
> Task :app:kaptKotlin FAILED
e: error: Arrow's annotations can only be used on Kotlin classes. Not valid for error.NonExistentClass
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:kaptKotlin'.
> Compilation error. See log for more details
Here is what I discovered:
If I remove the functor definition then the goal completes successfully and I can see the generated code.
If I remove #higherkind from the data class ParserK and copy the generated sources into the same file where ParserK is defined then I can see the generated code for the functor.
It seems like a bug for me, correct me if I am wrong, please
UPDATED:
Here is the link to the repository with my code: repository
The issue on the bug tracker is here
(For arrow-version 0.9.1-SNAPSHOT and prior)
The Higherkinded Processor and Extension Processors have a dependency. Correctly, the extension annotation depends on the code generated by the higherkinded annotation. Why check this link.
The brief summary is, whenever you try implementing typeclasses the compiler needs the Higherkinded Types of your datatype.
#extension
interface ListKFunctor : Functor<ForListK> {
// ^^^^^^^^
// This exists after building your module
override fun <A, B> Kind<ForListK, A>.map(f: (A) -> B): Kind<ForListK, B> {
return this.fix().map(f)
}
}
The simplest answer to this question is:
Always separate your Higherkinded Types from your typeclass definitions.
But Arrow is experimenting with other options on Codegen. Meaning in future releases this problem will be solved.
I've read https://aspnetboilerplate.com/Pages/Documents/EventBus-Domain-Events and also ABP's implementation of Entity event handlers https://github.com/aspnetboilerplate/aspnetboilerplate/tree/f10fa5205c780bcc27adfe38aaae631f412eb7df/src/Abp/Events/Bus/Entities
I have spent 8 hours at work trying to find a solution to my issue, but I failed to succeed.
I have certain entities that point to a single entity called DatumStatus, which records certain actions that generate different states, such as: approved, modified, reviewed, archived, etc.
I am trying to generate a generic EventHandler capable of modifying its status based on these actions.
An example based on a algorithm:
EventBus.Trigger(new ApproveEventData{
Repository = _certainRepository,
Ids = [1, 4, 5]
});
The handler itself would, in turn, handle this state transition
public void HandleEvent(ApproveEventData eventData)
{
eventData.Repository.Where(p => p.Id.IsIn(eventData.Ids)).ForEach(p => {
p.Approved = true;
p.ApprovalDate = DateTime.Now()
});
}
The problem is, I need to write a generic ApproveEventData and handler capable of firing the same HandleEvent for every single entities.
The "closest" I got is:
EventBus.Trigger(typeof(ApproveEventData<int>), (IEventData) new ApproveEventData<int> {
Repository = (IRepository<EntityWithStatus<int>, int>) _entityRepository,
Ids = selectedIds
});
[Serializable]
public class ApproveEventData<TPrimaryKey> : EventData
{
public IRepository<EntityWithStatus<TPrimaryKey>, TPrimaryKey> Repository;
public TPrimaryKey[] Ids;
}
The implementation above failes when casting the repository.
Could someone shed some light? Thanks!
I see two possible approaches.
Rely on covariance and contravariance. You can make the cast succeed by making an interface for EntityWithStatus an interface and making both IEntityWithStatus and IRepository covariant (add out to the generic type definition).
Rely on dynamic and leverage generic type inference. Basically have the Repository be dynamic.
I'd recommend number 1.
I am using Visual Studio 2013 with update 4 and Typescript 1.3 installed.
If I have a typescript file, like so:
MyEnums.ts:
export = MyEnumModule;
module MyEnumModule {
export enum AnEnum { RED, BLUE, GREEN }
}
And I have a definitions file like so:
MyDefinitions.d.ts:
declare module MyDefinitions {
interface ISomeInterface {
aProperty: string;
aMethod: () => void;
aColor: MyEnumModule.AnEnum;
}
}
I basically get an error of "Cannot find name 'MyEnumModule'"
This enum file works fine when referenced from typescript files. For instance:
SomeCode.ts:
export = MyCode;
import MyEnums = require('MyEnums');
module MyCode{
export class MyClass implements ISomeInterface {
public aColor: MyEnums.AnEnum = MyEnums.AnEnum.RED;
...and so on
My understanding is that adding either /// <reference ... or an import will not work for a .d.ts file (I tried just to be sure and it didn't appear to work either way).
Does anyone know how to reference an enum in a definition file like this?
Thanks in advance.
--Update:
Here is the error I see after trying Steve Fenton recommendations below (with a sample project I just made).
MyDefinitions.ts:
import MyEnumModule = require('../App/MyEnums');
declare module MyDefinitions {
interface ISomeInterface {
aProperty: string;
aMethod: () => void;
aColor: MyEnumModule.AnEnum;
}
}
MyEnums.ts:
export = MyEnumModule;
module MyEnumModule {
export enum AnEnum { RED, BLUE, GREEN }
}
MyClass.ts:
export = MyCode;
import MyImport = require('MyEnums');
module MyCode {
export class MyClass implements MyDefinitions.ISomeInterface {
public aColor: MyImport.AnEnum = MyImport.AnEnum.RED;
constructor() { }
aProperty: string = "";
aMethod: () => void = null;
}
}
Folder structure:
App
-MyClass.ts
-MyEnums.ts
Defintions
-MyDefintions.d.ts
Inside MyClass.ts MyDefinitions.ISomeInterface is underlined in red with hover warning "Cannot find name MyDefinitions".
I have AMD set for the project
Does anyone know how to reference an enum in a definition file like this?
There are workaround as Steve Fenton pointed out, but the system isn't designed for this. You should reference other definition files in your definition file and not reference an *implementation file * (MyEnum.ts) in a definition file.
I had a check on this and the following definition works for me, although I must admit I have never referenced "actual" code from "definition" code - but I can't think of any reason not to.
import MyEnumModule = require('MyEnumModule');
declare module MyDefinitions {
interface ISomeInterface {
aProperty: string;
aMethod: () => void;
aColor: MyEnumModule.AnEnum;
}
}
On mixing definitions and real implementations...
The type system in TypeScript is a design time and compile-time tool. When the type information is constructed at design time it makes no difference whether the type information is inferred from implementation code, taken from annotations that decorate implementations or come from an ambient declaration.
There are many use cases for mixing implementation code and ambient declarations - if you are migrating a million-line JavaScript program to TypeScript, you may not be able to migrate it from the bottom-most dependency upwards. Also, you can place ambient declarations inside of normal files - not just definition files - if you have a large program, you may not even know whether a type you place in an ambient declaration is "real" or "ambient".
The only difference between implementation code types and ambient declaration types is that the type information is right next to the implementation in real code files, and in a separate file for ambient declarations.
So... if you are having a problem using real implemented types in your ambient declaration, it is most likely caused by something that can be fixed. The example I supplied above works in a project I have in Visual Studio 2013, Update 4 - with TypeScript build configuration set to compile AMD modules. If you can share the exact details of the problem, I'm happy to help you get it working.
Having said this - if you are creating a type definition for trivial amounts of code, pasting them into a .ts file may even be faster than writing the definition - so you should make a case-by-case decision on where to spend the effort.
I'm getting an error when trying to run the EF 4.3.1 add-migrations command:
"The model backing the ... context has changed since the database was created".
Here's one sequence that gets the error (although I've tried probably a dozen variants which also all fail)...
1) Start with a database that was created by EF Code First (ie, already contains a _MigrationHistory table with only the InitialCreate row).
2) The app's code data model and database are in-sync at this point (the database was created by CF when the app was started).
3) Because I have four DBContexts in my "Services" project, I didn't run 'enable-migrations' command (it doesn't handle multipe contexts). Instead, I manually created the Migrations folder in the Services project and the Configuration.cs file (included at end of this post). [I think I read this in a post somewhere]
4) With the database not yet changed, and the app stopped, I use the VS EDM editor to make a trivial change to my data model (add one property to an existing entity), and have it generate the new classes (but not modify the database, obviously). I then rebuild the solution and all looks OK (but don't delete the database or restart the app, of course).
5) I run the following PMC command (where "App" is the name of one of the classes in Configuration.cs):
PM> add-migration App_AddTrivial -conf App -project Services -startup Services -verbose
... which fails with the "The model ... has changed. Consider using Code First Migrations..." error.
What am I doing wrong? And does anyone else see the irony in the tool telling me to use what I'm already trying to use ;-)
What are the correct steps for setting-up a solution starting with a database that was created by EF CF? I've seen posts saying to run an initial migration with -ignorechanges, but I've tried that and it doesn't help. Actually, I've spent all DAY testing various permutations, and nothing works!
I must be doing something really stupid, but I don't know what!
Thanks,
DadCat
Configuration.cs:
namespace mynamespace
{
internal sealed class App : DbMigrationsConfiguration
{
public App()
{
AutomaticMigrationsEnabled = false;
MigrationsNamespace = "Services.App.Repository.Migrations";
}
protected override void Seed(.Services.App.Repository.ModelContainer context)
{
}
}
internal sealed class Catalog : DbMigrationsConfiguration<Services.Catalog.Repository.ModelContainer>
{
public Catalog()
{
AutomaticMigrationsEnabled = false;
MigrationsNamespace = "Services.Catalog.Repository.Migrations";
}
protected override void Seed(Services.Catalog.Repository.ModelContainer context)
{
}
}
internal sealed class Portfolio : DbMigrationsConfiguration<Services.PortfolioManagement.Repository.ModelContainer>
{
public Portfolio()
{
AutomaticMigrationsEnabled = false;
MigrationsNamespace = "Services.PortfolioManagement.Repository.Migrations";
}
protected override void Seed(Services.PortfolioManagement.Repository.ModelContainer context)
{
}
}
internal sealed class Scheduler : DbMigrationsConfiguration<.Services.Scheduler.Repository.ModelContainer>
{
public Scheduler()
{
AutomaticMigrationsEnabled = false;
MigrationsNamespace = "Services.Scheduler.Repository.Migrations";
}
protected override void Seed(Services.Scheduler.Repository.ModelContainer context)
{
}
}
}
When using EF Migrations you should have one data context per database. I know that it can grow really large, but by trying to split it you will run into several problems. One is the migration issue that you are experiencing. Later on you will probably be facing problems when trying to make queries joining tables from the different contexts. Don't go that way, it's against how EF is designed.