<cite>gep13: </cite> Hello,
In the generated Index.js files for the entities I have created, I am seeing lines like this:
ajaxFunction: _computersService.getAll,For querying all the records from the database. I have created a custom method in my controller that I want to call instead of the default getAll method, however, I am unable to find the _computersService defined anywhere to add that method to.
Can someone please point me in the right direction?
Thanks Gary
Hey Gary,
With Asp Zero, we don't create controller methods for javascript. ABP Framework dynamically generates proxies for all of your application services (defined in the Application project), and exposes them through dynamically created scripts.
If you want to expose a custom function, you just need to add it to the corresponding Application Service.
In your case, you want to find the computersService in your application project.
Make sure to update the interface in the application.shared project, as well.
What version are you downloading? They update nuget packages with every release.
Integration tests will always take a long time, and because of that, they aren't suited for CI.
These types of tests are generally run on nightly build servers, as opposed to per commit like you would do with unit tests.
We created a second test project (technically two test projects, one for unit tests for domain, and one for unit tests for application.)
The only tests we include in our CI configuration in team city are the unit tests. They execute very quickly, with minimal impact on our build servers.
In general, I find unit tests to be much more valuable tests, because they tell you exactly where your code is failing, whereas integration tests only really tell you if your layers are connected properly. If an integration test fails, it's not immediately clear where the failure is occurring. Add to that the greater potential for unexpected issues related to things like differences between in-memory db and sql server, and you can spend a lot of time running in circles for a non-issue.
That's not to say they aren't valuable. They absolutely are. They just shouldn't serve as a replacement for unit tests, and if you're adding your own tests to the project, I would recommend investing the time in unit tests over integration tests, if you're constrained on development time.
I would add that in EF6, you could generate code models from a database using the code first approach.
Code scaffolding from database was a stretch feature for EF core 2.1, but it did not make the cut for release, it looks like. You can track the feature here: [https://github.com/aspnet/EntityFrameworkCore/issues/831])
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: