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
Related
I've done a reasonable amount of reading around on .NET Standard v .NET Core, watched a course on PluralSight regarding EF Core and done further reading on EF 6 v EF Core, and done some reading up in ASP.NET Core v ASP.NET.
What I still can't decide is what the recommendation is if I'm about to embark on a new project with a web interface. It's against SQL Server, and will be hosted on Windows and users will be connecting from Windows desktop machines.
As it's all Windows .NET Standard would suffice - though I could use .NET Core, I know that EF Core works against .NET Standard, I assume ASP.NET Core will as well.
At a later date there could be an extension for mobile functionality, but that could be written as an extension/module using Core or similar.
It's vary hard to find a clear answer on this as even on Microsoft's Docs site, the EF initial pages haven't been updated since the release of EF Core 2 and prior to that they seem to suggest that unless you need it, stick with EF 6.
Thanks
Tom
Looks like I was lead astray by some articles I read on .NET Standard.
However, I now have an answer from a post on the MSDN site see here
Im doing a project with .net Framework , but to run on the linux i need .net Core..
I heard that it is possible to change .net Core to .net Framework only with changes on the project.csproj with this:
<TargetFramework>netcoreapp1.1</TargetFramework>
to
<TargetFramework>v4.5.2</TargetFramework>
and i tried to do the opposite , but i got some erros on the project...
There's a way to do that?
Thanks!
You can not switch a .NET Framework project to .NET Core that easy.
You might change an empty project but not one you already started coding.
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)
See this post on providing backward compatibility for App.config, appSettings.config and Web.config XML-based configuration providers
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 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.
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 know we are really behind the times here, but we are just about to upgrade from .NET 1.1 to .NET 2.0.
Thank you for your sympathy.
Anyhow, are there any gotchas we should look out for?
Do you have any general advice before we jump in?
Please do not post telling me to go straight to 3.5: 2.0 is all we're allowed!
We're using mostly C#.
Yes. The most important thing for you to know is to use a Web Application Project, not a Web Site. Web Sites use a totally different compilation model and migration is pretty much a disaster. Web Application Projects are much more similar to how things worked in 1.1.
We also had an intermittent problem with redirecting from the login screen, but according to Google, we were basically the only ones who had that problem - we've since resolved it.
Most of the other problems we ran into were small and easy to navigate, and the overall experience was a net improvement.
Here is my recommendation before upgrading:
If you are used to use Visual Studio 2003, you will need to go for VS2005. You will have to convert the old solutions and projects so that it will be compatible with VS2005. Make sure to have a backup of the project you're going to convert so that you can roll back or even use it as source for any modification you may need to the converted projects.
If you're developing web applications using .NET 1.1, make sure that all the virtual directories and applications in the IIS is configured to work with ASP.NET 2.0. You may need also to configure a new Application Pool for your .NET 2.0 applications.
If you're using any third party libraries in your .NET 1.1 projects, you may need to confirm its compatibility with .NET 2.0 projects. Some old libraries used in .NET 1.1 are not compatible with 2.0.
One gotcha is home-grown 1.1 implementations of .NET 2.0 stuff (that was missing in 1.1) like RegistryHandler and so forth. Sometimes your newly-ported 2.0 code will look like it's properly using a 2.0 class when it's really using the home-grown version.
Deployment is another gotcha, if you're upgrading an already-deployed app. You have to switch the .NET version in IIS from 1.1 to 2.0.
I remember we had to change some client scripts, because the way ClientIDs are generated for server controls changed from ASP.NET 1.1 to 2.0.
I don't remember the exact circumstances, but some IDs which previously wer prefixed ctl0_ became ctl00_...