I got lost very quickly in all the moves from .Net Framework to .Net Standard to .Net Core. Could someone please just tell me what I need to do to get my projects to work together?
Here's the situation: I've got a simple web service written in ASP.Net that contains a set of classes built by Entity Framework from an existing database using a "scaffold" command. The web service can respond to a request for a list of coils from a database. The list is delivered as a JSON-serialized string.
I have a simple mobile app developed in Xamarin. I want it to accept the JSON string and deserialize it into a list of Coil objects. To do that, I need to add a reference to the web service project. But when I try to do that, I get complaints that the targets of the two projects are not compatible.
The choices for target frameworks for the web service are .Net 5.0 and .Net Core 1.0 through 3.1. The choices for target frameworks for the Xamarin app are .Net Standard 1.0 through 2.1. I have been unable to find a combination of these choices that works. What choices should I use that would enable me to add a reference to the web service project to the Xamarin project?
Or should I split the Entity Framework-generated classes out into a separate library? That would probably be a better project structure anyway. In that case, I'd have three projects. The target framework chosen for the library would have to be compatible with frameworks chosen for the web service and the Xamarin app, but the framework for the web service would no longer have to be compatible with the Xamarin app's framework.
Or perhaps I should rebuild all of these from scratch. These are all trivial projects, done mainly for education, although the Xamarin app might be useful in the real world. Recreating them would be easy. Again, if I did this, what targets should I use?
All development has been done in Visual Studio 2019.
Related
I have followings projects:
.NET Core 2.0 Web Application
.NET Standard 2.0 Class library &
.NET Framework 4.5 Class Library.
I add reference of .net framework class library to asp.net core web api project. and it seems it works very well.
I am wondering why it's possible to add reference of .NET Framework class library project to ASP.NET Core Web API or MVC?
It's not supposed to allow adding only Standard or Core libraries references to Core projects?
Is this core Web project with .NET Framework class libraries references still cross platform?
UPDATE
According to Phiter comment:
"If you import a .net framework library to your project it'll no longer be cross platform, but you can do it freely if you want to. They allow it because you might want to use .net core and still be on windows."
So if this is a reason, if I want to bind my project to .NET Framework and remain on windows why I use Core Web Project from the first place?
I thought we use core projects for cross platform ability and if not, the .Net framework is not a better option?
UPDATE
mason comment:
"Nothing funny: ASP.NET Core project doesn't have to run on .NET Core. It can also be run on .NET Framework.
Just because it's called 'Core' doesn't mean they're related. They could have called it ASP.NET FancyPants and had it run on .NET Core and .NET Framework and you wouldn't be as confused. Microsoft just sucks at naming things."
UPDATE (November 12, 2018)
A first look at changes coming in ASP.NET Core 3.0 - Fully leveraging .NET Core
As announced on the .NET Blog earlier this month, .NET Framework will get fewer of the newer platform and language features that come to .NET Core moving forward, due to the in-place update nature of .NET Framework and the desire to limit changes there that might break existing applications. To ensure ASP.NET Core can fully leverage the improvements coming to .NET Core moving forward, ASP.NET Core will only run on .NET Core starting from 3.0. Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.
Customers utilizing ASP.NET Core on .NET Framework today can continue to do so in a fully supported fashion using the 2.1 LTS release. Support and servicing for 2.1 will continue until at least August 21, 2021 (3 years after its declaration as an LTS release) in accordance with the .NET Core support policy.
This was just added as part of .NET Standard/Core 2.0. As long as the .NET Framework dll only references things in the .NET Standard, it will use type forwarding to the .NET Core implementations.
I do not know what made Microsoft allow referencing .net framework class library into .net core project but as a programmer, I am happy with this allowance.
You see allowing .net core application to reference .net framework libraries is useful in case you want to start with windows and are planning to go cross platform in the future.
We are in a stage where many useful open source libraries do not fully support .net core till the date of this post, masstransit is an example, so when I am developing a new software I will be using .net core project that depends on such libraries and I will update them later when they support .net core.
I am trying to generate Well formatted Excel files from .Net Core and found ClosedXML library which runs only on .Net 4.61
I already tested the following libraries which work on .Net Core
OpenXML - Too many codes for a simple task and difficult for me to use
SyncFusion - Public / Government Organisation cannot use for free.
I changed the target to Net461, do the dotnet restore and all my codes are still running as usual and I could generate the Excel file with ClosedXML too.
What I would like to know is, is it a good approach? This is not a one-off small project and I am likely to maintain this website for another 3-4 years at least.
Is there any potential to lose the new functionalities and not able to use new Libraries from .Net Core in the future?
Or should I create another separate website running on Net461 and call that URL from my .Net Core app? So, I don't need to worry about losing new .Net Core functionalities in the future.
There is obviously no way to know the future, but the biggest thing you get with .Net Core over the full framework is the ability to run the app cross platform. So if cross platform isn't a concern, then going with the full framwork shouldn't be an issue. There is no question that the full framework will be fully supported for the 3-4 year time horizon you mentioned, in fact I think most developers would feel comfortable using the full framework even for a project with a much longer time horizon.
With regard to missing out on new .Net Core features, many of the features can be accessed even from libraries compiled for the full framework. For example I use the new encryption libraries found in Microsoft.AspNetCore.Cryptography (that are part of .Net Core) from my full framework class library. The net .Net Core libraries are just Nuget packages and as such can be referenced from non .Net Core projects.
So I've developed a standard .NET 4.6 CRUD app that adds / edits / deletes data in a SQL Express database and is hosted on Azure. This will only be used by a couple of people to manage data for the main project which will be a one page Angular / mobile app. The next step is to develop an api (with .NET Core) so the data can be consumed by the Angular / mobile app.
What I'm wondering is if I already have the main CRUD app created with .NET 4.6, can I create an api in the same domain using .NET Core? Something like this:
mydomain.com - .NET 4.6
mydomain.com/api - .NET Core
Sure you can do this, you can also run a node.js app on mydomain.com/api_js for that matter, it's all about how do you configure your web server.
If it's a question how to configure the web server, you need just to google about your particular web server.
If it's a question if that makes sense - in my opinion yes, MS is putting now so much effort in being multi-platform, that my bet would be on the .NET Core being more future proof.
Only you have to keep in mind, that it won't be a simple reference adding to reuse the code, as it's not possible to reference .NET 4.x assemblies from a .NET Core project.
But it's possible the other way around, so you can abstract away the code you want to reuse from your .NET 4.6 project into a shared .NET Core assembly, which than may be referenced by both projects.
I am trying to build a .net core API using MVC, but I am trying to add it to an application that was not build on ASP.NET Core. When I try and configure the interfaces to be used in the core app (Setup.cs) I am not able to reference the interface. When trying reference the solution within the core app, I get the error
"The following projects are not supported as references: [solution name] has target frameworks that are incompatible with the targets in current project.
.NETCoreApp,Version=1.0
.NETFramework,Version=v4.5
What is the best way to be able to reference a .NETFramework project within a .NETCore project?
from comment above I realized it was not possible. I was not able to use the .net standard version in my core app.
I have a Solution which contains an ASP.NET Web Application project. Web Application project types can only target the full .NET Framework 4, and Visual Studio won't let you select the Client Profile.
However, my Class Library projects in that same solution allow me to target the .NET Framework 4 Client Profile.
So, should I mix targeting the Client Profile and the full framework in the same solution? Or just target the full framework for every project type in a Solution containing a Web Application project? Or does it not matter either way?
If you plan to reuse the Class Library in a WPF or WinForms app, then Client Profile is a good choice, since you are likely going to be able to set your WPF or WinForms app to use Client Profile as well. Even if your WPF or WinForms app ends up requiring the full framework, Client Profile is a subset of the full framework so it will still work just fine.
If your reuse plans on the Class Library are WebApp only or your only using a Class Library to help segment code, then the target framework is really not important.
Applications that target the .NET
Framework 4 Client Profile typically
improve the deployment experience by
having smaller download sizes and
quicker install times. An application
that targets the .NET Framework 4
Client Profile has a smaller
redistribution package that installs
the minimum set of client assemblies
on the user's computer, without
requiring the full version of the .NET
Framework 4 to be present.
If your library is general purpose and the target equipment will be installed with Client Profile Framework then prefer client profile for your library, by doing this you will have smaller installers. Web Components are not included when installed Client Profile Framework.
See: http://msdn.microsoft.com/en-us/library/cc656912.aspx