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.
Related
I'm trying to add a full framework class library as a project reference to asp.net core 2.0 MVC project and getting the below error.
Project XYZ is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0).
Project XYZ supports: net462 (.NETFramework,Version=v4.6.2)
I have updated to the most recent version of Visual studio i.e, 15.3.5.
Is it even possible to reference 4.6.2 libraries in core 2.0 projects?
The first thing that you can try is to compile the library you want to consume as netstandard2.0.
Theoretically (according to the .net standard documentation), this will make it compatible with projects using net461 and later as well as netcoreapp2.0 and later.
In practice, sometimes you will end up with a problem with one of your dependencies that don't provide the same library version across different compilation targets.
In such cases you may simply need to add the .net core 2.0 as a target framework for the XYZ library.
The xml tag listing the targets is <TargetFrameworks> in the XYZ.csproj file and is not handled by the Gui of the project's properties.
So I would give a try at editing the XYZ.csproj by hand and add or replace what's listed as <TargetFrameworks> with netcoreapp2.0.
If you are adding it as additional target you need to separate them with ';' as in
<TargetFrameworks>net462;netstandard2.0;netcoreapp2.0</TargetFrameworks>
More details about this in this Microsoft doc.
Please keep in mind that this will trigger multiple compilations and will slow your build consequently...
It should be. Microsoft announced a ".NET Framework Compatibility Mode" with the release of .NET Standard 2.0. However, they didn't go into great detail about how it works exactly, or what to troubleshoot if it doesn't. Additionally, they only specific talk about it in relationship to Nuget packages, so it's possible there's some role Nuget is playing in the process, as well. Unfortunately, I've been unable to find any additional information about this feature outside of the announcement post.
That said, Microsoft's explicit recommendation is to not rely on the fact that your .NET Framework library may just happen to work in .NET Core; instead, you should be actively porting .NET Framework libraries you control to .NET Standard. I'd say you're likely going to spend more time trying to figure out why it doesn't "just work" than you would porting your code, so that it will definitely work, and be future-proof to boot.
The following solution worked for me.
Deleted bin and obj folders from all the projects in the solution, rebuild and if it still doesn't work try changing browser from debug options. for eg. If you already have chrome as default browser in Visual studio, switch to Edge or Firefox.
I was looking for possibilities for porting some web projects from Windows .NET framework to Ubuntu linux using open source .NET core
After a lot of struggle with Mono, which I have almost gave up. I was looking at .NET core as a new hope. Have anyone of us ported from .NET to .NET core?
If yes, can the possible problems like the ones I faced with Mono be shared?
Moving from .NET to .NET Core is a huge move, especially if you're going to take advantage of Core. There is not currently a one click port, and I doubt you'll ever get a one-click migration like migrating from a VS 2013 project to a VS 2015 project. The entire startup flow is different, and to automate switching to that would be incredibly difficult. For now, the way I am looking at it is that moving to .NET Core is essentially a rewrite. As to whether that is worth it to you for your project - well that's really hard to say and also probably not well suited to that site.
That said, if you do rewrite you can probably bring along a lot of your business logic. You just will need to redo a lot of the other structure.
There's no easy way to move a project from .NET Framework to .NET Core. Possibly you'll need to rewrite or start from scratch.
There are some major differences between two
Format of configuration files (web.config vs appsettings.json)
Used libraries
Startup files (Global.asax vs Startup.cs)
Lack of static objects in .Net Core. Like Session and Application
objects - which is a good thing btw.
Many of the .Net Framework libraries are dependant on
app.config/web.config files
I've created a new ASP.NET 5 project and I faced with something that I didn't understand well about how the new ASP.NET works.
In my references there are DNX 4.5.1 and DNX Core 5.0. When I install a new package from Nu-Get, some packages install successfully in both and some tell me they aren't supported by DNX Core 5.0.
Can I use many versions of DNX for supporting my packages or I must bound the things with DNX Core 5.0 to enjoy the advantages of ASP.NET 5, like cross-platform and others?
ASP.NET 5 projects are multi-targeted, which means you can compile for multiple platforms simultaneously. In your case .NET 4.5.1 targets ASP.NET 5 on the full .NET runtime (4.5.1) and .NET Core (5.0). When you compile your project, ASP.NET 5 actually creates output for both of these targets so - assuming you get the code to compile for both platforms - the application can run on either of them. It's possible to run additional targets to your projects.
When you actually run your application though, you have to pick a specific version of the .NET runtime you want to run under. In Visual Studio there's a drop down in the project settings where you can select that runtime that actually executes. When you use command line publish you also specify which platform to publish to with a parameter (if omitted it uses the active DNX runtime I believe).
As to the differences - .NET Core is a trimmed down version of the full .NET runtime, that is cross-platform and can run on Windows and other platforms like Linux and OSX. Because it has to run on other platforms a lot of the platform specific Windows features are not supported in this runtime, and as the platform is still evolving some APIs are simply not implemented yet in .NET Core. This is the reason you are likely to see many compile errors when you target .NET Core with existing code/libraries. In order to run on .NET core existing .NET code typically needs at least some minor adjustments to account for the smaller API footprint and potentially serious redesign to work around missing functionality.
If you need to use existing code and depend on assemblies/NuGet packages that are based on previous versions of .NET you have to stick with the full .NET version. You can still take advantage of the new ASP.NET 5 features and eco-system, as well as getting the benefit of the full .NET runtime and full API surface you are used to from previous .NET versions. The downside is that the runtime is Windows only and has a bigger resource footprint.
.NET Core is a new runtime and you should treat it as such. Migrating to this platform is likely not a trivial task. The benefits of this platform is a much leaner footprint and that it can run across multiple OS platforms.
It's likely that it'll take some time for the full potential of .NET Core to come to fruition as Microsoft expands the feature set and cross-platform compatibility but we won't really know what this will look like since it is still in Beta (well RC but it's really a beta with major changes still coming in RC2).
I Was just reading this post: http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
It left me a bit confused since the first picture in the article seems to imply that .NET desktop apps and ASP.NET don't share the same framework implementation. I was always under the impression that it was. Any ideas?
They use the same .NET framework.
But they don't have to. And this is the way the .NET ecosystem is evolving right now - ways to avoid using the full (ever growing) .NET framework for everything.
As a bonus, the new .NET Framework Core is open-sourced. This is not entirely posssible with the whole .NET framework, since it includes a whole lot of licenses and proprietary technologies.
Given all that, it's now possible to deploy very light-weight web applications using ASP.NET, not even having to use IIS (thanks to OWIN). You only have to include the packages you need - instead of having a single monolithic runtime and BCL, there's hundreds of NuGet packages you choose to use (or not).
You will have to better define "the same framework implementation", as they (full .NET Framework and .NET Core) are built from the same code base with different configuration, and also host your web applications in a slightly different way.
The most important getaway of that article should be "ASP.NET 5 can run on both .NET Framework 4.6 and .NET Core 5". You get different benefits from each runtimes,
.NET 4.6 gives you best compatibility against previous .NET runtimes.
.NET Core 5 gives you flexibility on running multiple customized DNX side by side, and portability to Linux and OS X.
Unfortunately Microsoft decides to limit desktop apps to .NET 4.6, but Mono guys have demonstrated possibility to run some (such as WinForms apps) on .NET Core,
https://github.com/akoeplinger/mono-winforms-netcore
I've seen videos introducing ASP.NET vNext and been keeping up with the recent announcement blog posts, but detailed information on what's been stripped from the full framework appears slim. Here's what I think I know so far:
It's much smaller (11MB vs >200MB): http://davidzych.com/2014/05/24/getting-started-with-asp-net-vnext/
Strong naming is gone: http://jeremydmiller.com/2014/06/09/final-thoughts-on-nuget/
It's dumped System.Web
It includes a merged MVC and WebAPI (however I don't believe this is part of the framework itself but rather dependencies that can be specified)
Dependencies are completely managed through project.json, to the extent that the base
Are we basically looking at a framework that basically includes nothing more than what's in mscorlib in the full framework, with all else delivered via package management? And if this is the case, why would one need to target the framework specifically, as described here? http://blogs.msdn.com/b/webdev/archive/2014/06/17/dependency-injection-in-asp-net-vnext.aspx
The reason they specifically target NET45 in the link you supplied is because AutoFac is built for and has a dependency on .NET 4.5. Without NET45 the code wouldn't compile.
My assumption is that once vNext gets closer and closer to release the Autofac (and StructureMap, and Castle Windsor, and ...) will release a version that targets the cloud optimized framework to remove the dependency.
As far as I understand, .Net Framework is the fully framework we know and love with all the Windows implementations and lots of code we don't normally use, like they explain in some videos an XML parser.
In .NET Core they removed all the unneeded implementations/dependecies and only left the basic ones. which also enables cross platform (not yet), so in the future one could think as the only framework : CORE Framework, and run on any device. Their february community standup give a lots of information and insight on their objectives and goals.
I see this as a transition, when some features are available only on the full Framework while in the futures one might expect to see all features available for .NET Core.
From a Microsoft perspective, if they want to release lets say Entity Framework for mobile (EF7 is aiming at that) they must get rid of all the windows implementations, on EF and it's dependencies (Framework). So they created a non-windows dependency on the framework, which also helps the multiple framework install and remove some problems with updating the framework by having them mostly isolated from the system, lying in the application. New problems will come like multiple copies of the same framework on one machine per application, that's why they are working on something called Smart Sharing.
This post may help you and give you some insight specially this part :
The structure of .NET Core is comprised of two major components which
add to and extend the capabilities of the .NET Framework as follows:
Runtime:
Built on the same codebase as the .Net Framework CLR. Includes the
same GC and JIT (RyuJIT) Does not include features like Application
Domains or Code Access Security. The runtime is delivered on NuGet
(Microsoft.CoreCLR package)
Base class libraries:
Are the same code as the .Net Framework class libraries but do not
contain dependencies so have a smaller footprint. Available on NuGet
(System.* package)
and I guess you already read Introducing .NET Core from Microsoft.
Regarding your concern about specifying a specific framework is because right now, not everything works on Core CLR so you must choose which one to use, or you can target both and use different implementations.
As of right now, CORE only runs on Windows; the mono framework doesn't have a SQLLite provider for entity framework but it does on Core, so you can use an InMemory or Azure EF provider for example, and choose depending on the enviroment your application is running.
As Scott Gu says on the community standup, they envision a future where there's no mono framework or full framework, there's just Core, but that will take time if it ever happens.
I can't find an original source other than a comment by David Fowler (I believe) on a presentation from NDC, but CoreCLR used by the K Runtime is actually a reincarnation of the CLR used by Silverlight 2. It was used because it's small and designed to be cross platform. There is some additional information here: https://stackoverflow.com/a/25720160/113225