I have read this, MEF (Managed Extensibility Framework) vs IoC/DI but it is dated. Since then MEF was added to Core.
When I look at MEF and the IoC in ASP.NET Core, I cannot tell a lot of differences for a plugin architecture. Both "wire-up" dependencies. If I wanted to create a plugin in a Core application using IoC (the built in IoC), why not just change my ConfigureService methods? Is that the same as decorating imports and exports in MEF? How is composition different here, in 2017 (close enough)?
Related
We have an old .NET Framework nuget package built with .NET Framework that reads settings from Web.configs files on .NET Framework projects using the ConfigurationManager.AppSettings class. Now, we need to migrate it to .NET Standard to be able to use it on .NET Core projects also.
Is there an elegant way to try to find and read settings from both Web.config files when running in .NET Framework, and from appsetting.json when running on a .NET Core project? Does it make sense?
Also, it makes sense to have 2 different nuget packages, one for use only on .NET Framework projects and another to use only in .NET Core projects?
The main goal is to read setting independent of the .NET version it is running on.
I'm making the switch from frontend/Angular to backend/.NETCore. The biggest hurdle I've had is understanding what goes into scaffolding, especially when it comes to integration testing a WebAPI project and Entity Framework migrations.
Are there scaffolding tools similar to Angular Cli that promote good practices around things like setting up new projects or adding new classes in an organized, easily maintainable way?
Currently there is dotnet new which gives you both project templates (dotnet new razor, dotnet new mvc) as well as item templates (dotnet new page).
For entity framework, there is dotnet ef to help creating database contexts for existing databases (dotnet ef dbcontext scaffold) as well as managing migrations (dotnet ef migrations …).
I create new .NET Core projects using Visual Studio 2017 so the IDE automatically sets everything up in organised and maintainable way. It is certainly possible to do this in similar way to Angular CLI with .NET Core CLI. If you're creating .NET Core 2.x project you can find all the required commands here. For example; dotnet new webapi --name MyWebApiProject creates a web api project. To add Entity Framework you can use EF Core .NET Command-line Tools in similar way. Please find all EF Core commands here.
I am creating a bot using Microsoft Bot Framework and the project is using .NET Framework 4.6.1. I am also creating another project for user interface using .NET Core. Since both projects will be using same database so I am thinking to create an another common project using Entity Framework Core. But this project will not be working with .NET Framework 4.6.1.
Could anyone suggest me how to implement this requirement ?
I recently did a portion of the MVCMusicStore tutorial using MVC3 as directed. However, being that I have Visual Studio 2012, I'm attempting to use EF in an MVC4 application. I was attempting to add the using System.Data.Entity; directive and it was not found.
I know that I can probably just add the reference to it. But I'd like to know why it's not already available for my MVC4 project. Is there a new method of creating an Entity Framework supported application using MVC4?
Entity Framework is now being distributed separately from Visual Studio through the NuGet package management system as of Visual Studio 2012. The reason for this is to decouple EF from the release of VS, so it can be released on a different time schedule. They have also recently released EF as an open source framework, so it's being removed as a project from the .net framework release.
You have to use NuGet to install Entity Framework in your project. Right click on the project and choose Manage Nuget Packages. Make sure you select the Online tab in the dialog that opens, then in the search type Entity Framework and click Install. You will then be able to add the using statement.
i' ve some web applications developed using Seam Framework 2.3 + jBoss AS 7 + Hybernate.
Since i' ve been studying OSGI for a while, i was wondering if is possible to move my applications to the osgi world for modularizing everything; i' ve read a lot of blogs and these interesting discussions as well (how-to-modularize-an-enterprise-application-with-osgi-and-ee6 and how-to-modularize-a-jsf-facelets-spring-application-with-osgi) but honestly i still don't really know where i should start from, since i' ve never used OSGI before.
According to you
Is it possible (and useful) do such things?
According to your experience, what would be a good starting point?
Thanks for help
Approach
Possibly start with a toy application as a spike, a WAB (OSGi WAR) and single service bundle.
Definitely take an iterative approach. As far as I know JBoss supports the mixing of OSGi services and Java EE stuff, via JBoss modules/msc, this will allow you to try OSGi and migrate gradually.
I think you'll find some things are incredibly easy and others very hard, so pick easy battles while you're getting familiar. In the end you may stick with a hybrid approach.
Build
What's your build tool? Mostly like Maven or Ant, in which case have a look at maven-bundle-plugin
or bnd respectively. You'll need to ensure the OSGi metadata is present in each of your bundles (Bundle-SymbolicName, Import-Package, Export-Package, etc). If you're using Maven see this answer.
It can be tricky to divide a monolithic app into modules, but as a general rule when you migrate a reasonable sized module you should have separate bundles for API and implementation (which is good design anyway but has implications for the runtime too).
Interop
You can acquire OSGi services, access bundles etc using the low level framework APIs from an injected BundleContext, which will give you a low-level programmatic hook into OSGi. It should be as simple as:
#Resource
BundleContext context;
Unless your Java EE code is packaged as JBoss modules I don't think it will be easy for you to call the other way (e.g. OSGi service looking up Java EE service) without resorting to something like JNDI.
You should be able to install the webconsole and see what Java EE bits are registered in OSGi, and similarly check JNDI to see what's available OSGi for Java EE.
Migrating Services
While OSGi is a lot of fun, using the raw framework API results in quite a bit of boilerplate code and it's unlikely you'll need the power or want the coupling. You can use a number of dependency injection frameworks on top of OSGi; blueprint (Spring-like), Peaberry (Guice) and Declarative Services for example.
I'm biased but Declarative Services has a strong affinity to the OSGi µservice model and the implementations are lightweight.
CDI
I don't know much about Seam/CDI, but Pax CDI might help (though JBoss might already have covered this).
Web
Are you planning to have a highly modular UI with hot deploy of the various components? If not then probably best just to package the UI as a WAB. A WAB is a skinny WAR (i.e. it imports rather than embeds most dependencies). Even if you're after a highly modular, dynamic frontend, I would definitely do this for the first pass.
JPA
A word of warning - JPA implementations typically don't play well in OSGi environments, you may want to look at Apache Aries or Eclipse Gemini. Another option might be to leave the JPA stuff in Java EE space and access Java EE DAOs/Repositories as OSGi services. Again though you may experience some classloading issues.
Possibly useful examples https://docs.jboss.org/author/display/JBOSGI/Provided+Examples