Activities of "strix20"

Db first does not exist any more. It was not included in EF core.

There is a huge misunderstanding in the community, in the assumption that Code First refers to how the database is created. This is not the case at all. Code First refers to EF configuration using attributes, pattern matching, and the fluent API, as opposed to Database First which used an XML based (edmx) configuration for EF.

There is no reason you cannot use a SQL first approach. In fact, that is what we do in our project, using the alpha3 version of DbUp for .net core (we have a small team, and lack a DBA, so database operations are managed by our developers, and it's easier to have scripts included in our deployment process than to keep them isolated.)

If you want to take a SQL first approach, nothing really changes, except that you cease to create new migrations using the add-migration tool. You write the entity classes, and you configure the relationships in OnModelCreating. Assuming the database has had the proper SQL scripts run to generated the tables and procedures you are mapping to, then your code will work just fine.

SignalR has not been released for .Net core, as it is part of the Asp.Net Core 2.1 roadmap.

It's not even in a RC status yet, as it's still in aplha 2.

If you target full framework, (4.6.1) then SignalR 2 is used, but websockets does not work with .net core so it will fall back to long polling.

I personally think that Volosoft should not be including a broken, abandoned library in their .net product. We are dealing with the Microsoft stack, and while the project is now written in .net Core, I'm sure the majority of developers using the product are still working in Windows environments.

And when you have people like Scott Hanselman celebrating your product, I'd think you would want to make sure new users are not encountering embarrassing issues like this.

Isn't there an alternative that can be used that's actually in active development, and currently supported?

You shouldn't be running npm install at all, yarn replaces that step.

Here is an example of our build process (note that we use teamcity + octopus):

Run Yarn Run Gulp Restore packages (Nuget) Build project (dotnet build) Run unit tests (MSTest on our own library (we don't test the x-unit tests included in the project in our CI)) Publish MVC Project (dotnet publish) Publish Migrator Project (dotnet publish) OctopusDeploy Push packages

Then in our environment builds configurations, we add: OctopusDeploy Create Release OctopusDeploy Deploy Release

Our octopus is configured to deploy to an Azure Web App, and the migrator is deployed with the web project to azure. A step in octopus executes the migrator directly from the azure web app.

What version of the app are you using?

If it's targeting old SignalR (SignalR 2 using full framework), this does not support web sockets, which means signalR is falling back to long polling.

I've always had issues with response times on long polling.

Now I that I have provided a solution I feel terribly unclean, so I'm going to go have a glass of scotch and play with my new 75192 Millennium Falcon UCS lego set to drink the embarrassment away :ugeek:

Also, I would note that since most of the application layer has authorization configured, then you're either going to want to test the domain layer directly, or you're going to need to disable authorization and the permission checker in your test module as follows:

var auth = IocManager.Resolve<IAuthorizationConfiguration>();
auth.IsEnabled = false;
Configuration.ReplaceService<IPermissionChecker, NullPermissionChecker>();

If you've built your own project to test in, by copying the existing test project, then you can also use the existing EF initialization process by removing the following from the module constructor:

abpZeroTemplateEntityFrameworkCoreModule.SkipDbContextRegistration = true;

You will need to add a connection string setting to the appconfig.json in your test project. You will also need to add the following so that it picks the correct connection string from your app config:

var configuration = GetConfiguration();
Configuration.DefaultNameOrConnectionString = configuration.GetConnectionString(
    MyConsts.ConnectionStringName
);

Also, I'm not sure how compatible the tests will be with the LoginAs methods provided in AbpTestBase, since those are designed to be used with the seeded in memory database, but you can effectively log in as follows:

AbpSession.TenantId = 3;
AbpSession.UserId = 4

Remember that this will not actually log you in, and if you want to test actual permissions, you will have to write your own much more complex solution, and implement your own session and signin manager, since you do not have access to an HttpContext.

public class ConnectionString_Tests : AppTestBase, IDisposable
    {
        private readonly MyContext _db;
        private readonly IEditionAppService _editions;

        public ConnectionString_Tests()
        {
            _db = Resolve<MyDbContext>();
            _editions = Resolve<IEditionAppService>();
        }
        

        [Fact]
        public void SqlConnectionStringBuilder_Test()
        {
            var csb = new SqlConnectionStringBuilder("Server=localhost; Database=Customs; Trusted_Connection=True;");
            csb["Database"].ShouldBe("Customs");
        }


        [Fact]
        public async Task TalksToDatabase()
        {
            LoginAsHostAdmin();
            var t = await _editions.GetEditions();
            t.ShouldNotBeNull();
        }

        public void Dispose()
        {
            _db?.Dispose();
        }
    }

<cite>BobIngham: </cite> I'll try that later. In the meantime grow your arms or shorten your pockets so you can buy a beer. And stop taking life so seriously.

I just picked up a bottle of Corryvreckan this week. I'll cheers with a finger or two :mrgreen:

<cite>BBakerMMC: </cite> Strix can you do this for me?

If you create a new test project, make the appropriate EF core DI calls to setup your db context, there is nothing stopping you from hitting live data out of the box. The issue is with test startup and teardown and ensuring that you're not mucking up a good database with your tests.

Apparently Its not that simple or I missed something :) Then you can submit it to be included for those of use who want it.

I literally copied and pasted the code from the blog post, and it worked. I don't get what is so hard. The solution has repeatedly been posted.

I just duplicated it on my own. Here is the test class I used in a new project using MSTest, that connects to my local development db. I simply added a reference the the Core.EntityFramework project, and instantiated my db context class.

[TestClass]
    public class DemoTest
    {
        private MyDbContext _db;

        [TestInitialize]
        public void Init()
        {
            var serviceProvider = new ServiceCollection()
                .AddEntityFrameworkSqlServer()
                .BuildServiceProvider();

            var builder = new DbContextOptionsBuilder<MyDbContext>();

            builder.UseSqlServer("Data Source=.\\SQLEXPRESS;Initial Catalog=MyDb;Integrated Security=True;MultipleActiveResultSets=True")
                .UseInternalServiceProvider(serviceProvider);

            _db = new MyDbContext(builder.Options);
        }

        [TestMethod]
        public async Task PassingTest()
        {
            var t = await _db.Addresses.FirstAsync();

            t.ShouldNotBeNull();
        }
}

The test passes, which it could not if it was not connected to my database.