
Lessons Learned while Converting from ASP.NET to .NET Core - beyti
http://stackify.com/15-lessons-learned-while-converting-from-asp-net-to-net-core/
======
jasonkester
Just from the examples on this list, it sounds like the only winning move is
not to play.

I have a handful of sites running ASP.NET 4.5. Migrating them would cost an
unknown amount of time and require substantial rewriting of major components
(such as all data access). It might not even be physically possible to do,
given dependencies on libraries that are still 4.5 only.

It sounds like it would also kill our build process dead (adding another major
rewrite to the tally). And of course, it would leave us reliant (correct me if
I'm wrong here) on a lighter weight version of VS.NET so we'd roll back the
clock about 10 years on ReSharper-like goodness.

As reward for this, migrating over to Core would gain me roughly $0 in
business value.

The alternate course is to stay with 4.5 for as long as possible, eventually
moving across when Microsoft decide to VB6 it.

Sounds like a plan.

~~~
Avalaxy
> it would leave us reliant (correct me if I'm wrong here) on a lighter weight
> version of VS.NET so

No, you can just use the normal Visual Studio, with ReSharper support.

~~~
jasonkester
Glad to hear. I hadn't seen them mention it anywhere, and since it was such an
obvious dealbreaker, I would have expected it to be a major talking point.

~~~
sundvor
Yep, Resharper is fine but NCrunch won't work for any projects targeting Core,
however.

~~~
dan_b
...and that is a dealbreaker.

------
colemickens
>We ended up using the JsonProperty attribute on some things to force their
casing how we needed them.

That's a weird choice. It's a one-line modification to change back to the
legacy naming scheme [1]. (Which is completely non-standard and doesn't follow
what basically the entire rest of the web accepts as the standard method of
naming js object keys. But hey, .NET people are really beholden to some
strange things.)

[1]:
[https://github.com/aspnet/Mvc/issues/4842](https://github.com/aspnet/Mvc/issues/4842)

------
ofir_geller
I recently built a web app with the new dotnet core . the changes were not so
bad, I even found that the docs were nicer than the ones you find for the
"old" asp.

After having to configure camalCase for json a couple of times I like the new
default.

But migrating an existing app at this point is out of the question, when I no
longer need to have nugget packages with rc in the version name we might do
it.

~~~
philippelh
If you're talking about project.json, it's already dead :/
[http://xoofx.com/blog/2016/05/11/goodbye-project-
json/](http://xoofx.com/blog/2016/05/11/goodbye-project-json/)

~~~
ofir_geller
No I'm talking about the version numbers themselves, things like:
1.0.0-preview2-final I will not take a working(and money-making) code base and
migrate it to a platform where that is the version I need to use.

As for project.json. I actually liked using JSON over XML, but it's a personal
preference thing, can't really make a case that it's better.

------
eksemplar
This is quite frankly an excellent list of why we won't be changing any time
soon, with key points being:

> Things like virtual hosts, logging, security, etc.

> Newtonsoft now defaults to camelCase

> Log4net doesn’t work and neither do countless other dependencies, unless you
> target .NET 4.5

I mean a lot of those things are the reason we're using .Net over more other
technologies to begin with.

~~~
dodyg
aspnet.core works fine with .NET 4.5.

For me the big attraction to aspnetcore is not the aspnetcore MVC, but the new
infrastructure that they build around it. I am working on a project right now
going down to every single little tiny details of aspnetcore capabilities
[https://github.com/dodyg/practical-
aspnetcore](https://github.com/dodyg/practical-aspnetcore)

~~~
restlessmedia
Some good work there, I'd be interested to see more examples of aspnetcore
recipes.

~~~
dodyg
If you have anything particular in mind, please create an issue and I will get
to them eventually.

------
faragon
"As part of .NET Core, Microsoft (and the community) has created a whole new
web server called Kestrel. The goal behind it has been to make it as lean,
mean, and fast as possible. IIS is awesome but comes with a very dated
pipeline model and carries a lot of bloat and weight with it. In some
benchmarks, I have seen Kestrel handle up to 20x more requests per second.
Yowzers!"

So the new Microsoft web server replacing IIS, Kestrel, is 20x faster in some
circumstances? Wasn't IIS "state of the art"?

~~~
cmdkeen
It isn't replacing IIS, and they're very clear that you almost certainly
shouldn't be exposing Kestrel to the internet without going through something
like nginx or IIS.

Kestrel does the bare basics of a web server, it goes a little bit further
than the dev servers built into plenty of other language's web frameworks.

~~~
Avalaxy
> very clear that you almost certainly shouldn't be exposing Kestrel to the
> internet without going through something like nginx or IIS.

Why is that? Will you still have the performance benefit of Kestrel if you use
IIS in front of it? How would that work?

~~~
WorldMaker
The same reasons that Python, Ruby, and Node are almost always reverse-proxied
by a "bigger" web server. The "closer to the metal" server handles things like
virtual hosts, load balancing, black lists/white lists, throttling, speaking
to the kernel-layer about low level IP port specifics, while the "closer to
the language" server deals with the realities of your business logic and
application code.

That separation of concerns between two web servers in a reverse-proxy has
become a very useful mainstay "Production best practice" in the Linux/Unix
world, so it's nice to see Kestrel follow the larger trends there. It makes it
easier to use Kestrel in most Linux/Unix deployments, but some of the reasons
that it became best practice apply back to Windows. For instance, the
principal of least privilege applies in that the application web server can
run in a much more isolated process space than the kernel-level web server and
the service boundary to secure between them in a reverse-proxy scenario is
"just HTTP".

As for performance, IIS is a rather good reverse proxy and efforts to make it
better for Kestrel have benefited Node, Python, and Ruby hosting on Windows,
as well as vice versa.

------
sklarsa
I'm surprised that there's no DataTable in .NET Core. I've found them to be
incredibly useful for ETL and other processes that involve ingesting or
outputting tabular data. Are there any alternative 3rd party libraries out
there that have similar functionality?

------
cm2187
Stupid question. How do you share IPs if all the websites on a machine are
running their own webserver? When running in IIS, IIS handles the virtual
hosts. Unless we found a massive stach of IPv4 IPs?

~~~
awestroke
You typically still use IIS but only as a reverse proxy

~~~
cm2187
So you set up the self hosted webservers on some non routable local IPs /
ports, and set up IIS to map these IPs / ports to the external IP / hostname?

Sounds complicated. You have two states to maintain and keep synced. The .net
core servers and IIS.

~~~
35bge57dtjku
Of course it's complicated, you stipulated that all websites are running their
own web server.

~~~
cm2187
I am not. This seems to be what .net core does, according to the article.

------
statictype
So deploying web apps now consists of deploying a service that uses kestrel
and having a reverse proxy in front of it (IIS or nginx or something)as the
first point of contact.

Is that correct?

That's the recommended way to deploy?

~~~
taspeotis
Yes. If you want to see how it might work, Scott Hanselman posted an example
[1] recently using nginx.

[1]
[http://www.hanselman.com/blog/PublishingAnASPNETCoreWebsiteT...](http://www.hanselman.com/blog/PublishingAnASPNETCoreWebsiteToACheapLinuxVMHost.aspx)

------
sundvor
Another "little" one: Studio tooling is still in preview, so NCrunch cannot be
used. It's been a moving target for a long time, and too hard to complete
until locked down.

------
Hondor
It's depressing to me that no talk about .Net Core even bothers to mention
desktop apps. Winforms and co aren't even on the radar. I guess I'm stuck in
the past.

~~~
WorldMaker
All of the work in .NET Core benefits ".NET Native". .NET Native is what
powers the .NET stack side for Universal Windows Platform (UWP) apps.

WinForms has been considered deprecated since WPF and WPF is essentially
deprecated for UWP. (In an interesting historical aside, in some ways the UWP
is what WPF was promised to be way back when WPF was still codenamed Avalon.)

Certainly WinForms and WPF aren't going anywhere any time soon (both in terms
of backward compatibility will be stable for a long time still, but don't
expect any new things), but UWP is clearly the way forward for new apps and it
_is_ benefiting from the work going into .NET Core.

The Desktop App Converter recently released (nee Project Centennial) can help
if you've got a big investment in WinForms and wish to slowly migrate to UWP,
so you aren't necessarily "stuck" in the past if you do want to try to move
forward.

------
cm2187
For a website, not being able to manipulate files (no System.IO.File) or
images (no System.Drawing) is a bit of a problem unless all you are doing is
serve a database.

~~~
tonyedgecombe
Using System.Drawing from ASP.Net was never supported anyway (although much of
it did work). From [https://msdn.microsoft.com/en-
us/library/system.drawing.aspx](https://msdn.microsoft.com/en-
us/library/system.drawing.aspx)

"Classes within the System.Drawing namespace are not supported for use within
a Windows or ASP.NET service. Attempting to use these classes from within one
of these application types may produce unexpected problems, such as diminished
service performance and run-time exceptions. For a supported alternative, see
Windows Imaging Components."

~~~
joneholland
System.Drawing actually wraps GDI win32 calls, so while it works, running it
on a server would be iffy, and running it on non Windows would be impossible.

Now, they could reimplement system.drawing using a different backend per
platform, but I don't think the demand is high enough.

------
blakeyrat
What the heck are you supposed to do without System.Drawing? I find it
incredible they've just plain removed it altogether.

~~~
taspeotis
System.Drawing is wed to GDI+ so not cross platform. There are third party
libraries that work just fine.

[https://github.com/imazen/Graphics-vNext](https://github.com/imazen/Graphics-
vNext)

If you don't care about .NET Core but you do care about ASP.NET Core you can
always run ASP.NET Core on Windows and use System.Drawing.

~~~
blakeyrat
It's only "wed to GDI+" because the current implementation is. Nothing's
preventing them from implementing a cross-platform System.Drawing. There's no
magic involved in what it does that requires GDI+.

I find it unbelievable that they would even consider releasing this without
System.Drawing or equivalent being available.

~~~
taspeotis
.NET Core has neither WinForms nor WPF. It's very much focused on web
applications. System.Drawing might be useful for ... one in ten? web
applications. And they have released it, and it's getting plenty of traction.

Take a quick scroll through here:
[http://referencesource.microsoft.com/#System.Drawing/commonu...](http://referencesource.microsoft.com/#System.Drawing/commonui/System/Drawing/Advanced/Gdiplus.cs)

To re-use System.Drawing Microsoft would need to re-implement all those
methods in a cross-platform, bug-compatible way. And there's a lot of code
_behind_ those methods.

In my opinion they made a reasonable decision to leave it out of v1.

~~~
cm2187
No, my understanding of .Net core is that this is also the way they want to
get back on devices. I think Xamarin will ultimately be based on .net Core.
And for a mobile app, you bet you need a way to manipulate images.

Even for websites, depends on what sort of websites you do, but I often need
to display charts, so being able to generate images on the fly.

~~~
eberkund
Why are you generating images on the fly to display a chart? Why not send the
data points and render a chart clientside using JavaScript? There are plenty
of libraries for that.

~~~
moron4hire
A lot of clients want native PDF output for their reports. None of the PDF
generating libraries I know of support running JS. So if you want the same
charts in both, you need to generate the images server side.

