Hi,

That's going to be a tough sled. Just started to migrate a complete solution 
from c# to netstandard and had about 5 problems in 10 minutes. And that's 
just the beginning, I'm far from being through yet.

We really should think about how we can make migration easier for folks 
trying the same. We absolutely have to when we going to cut off C#, 
otherwise the sh*t storm we will get will be of biblical proportions.

Have fun,
JensG


-----Ursprüngliche Nachricht----- 
From: James E. King III
Sent: Thursday, January 3, 2019 9:10 PM
To: dev@thrift.apache.org
Subject: Re: Support for lib/csharp .NET Framework before 4.5?

The nuget package I published for 0.12.0 contains a build for net35, net45,
and netstandard2.0.
This means .NET Framework for Windows Desktop v3.5 and v4.5 as well as .NET
Standard 2.0.

There are some optimizations that we use in net45 (they came in net40
actually) that are not
available in net35, hence to two targets.  Then the lib/netcore stuff was
made and has separated
from lib/csharp and there have been some changes, but it doesn't look like
a ton.  I assume some
of the changes take advantage of new things in netstandard.

All I am suggesting is that net35 is long in the tooth, and folks can use
0.12.0 to work with it,
and that we consider having only net45 or netstandard*.* (version to be
decided; we're on 2.0
at the moment and we likely don't require 2.0).  I'm not as convinced
someone could use netstandard
with a windows desktop app - that's .NET Framework and quite different and
that's what lib/csharp provides.

Ideally we'll get to a point where there's only one C# implementation
again, but I'm not sure
how quickly that will happen.  In the meantime we have to be careful that
changes made
in one that are applicable to the other get done.  It would be a good idea
to analyze what's been
changed to make sure nothing has been missed.

- Jim

On Thu, Jan 3, 2019 at 2:07 PM Randy Abernethy <randy.aberne...@rx-m.com>
wrote:

> Ya, I think that is a prereq for sure.
>
> On Thu, Jan 3, 2019 at 11:01 AM Jens Geyer <jensge...@hotmail.com> wrote:
> >
> >
> > Can we make sure all fixes to the C# bindings made in the meantime are
> also
> > in netcore? Otherwise I'm against it.
> >
> >
> > -----Ursprüngliche Nachricht-----
> > From: Randy Abernethy
> > Sent: Thursday, January 3, 2019 2:34 AM
> > To: dev@thrift.apache.org
> > Subject: Re: Support for lib/csharp .NET Framework before 4.5?
> >
> > @jking  yes /lib/netcore is the .Net Core impl, I am suggesting we
> > ultimately remove /lib/csharp, which is the .Net Framework impl. I am
> > _not_ suggesting we just del it, I am suggesting we direct all new
> > contrib to netcore and stop taking pulls for csharp and create an
> > incentive to port everything in C# missing from netcore (simple in
> > most cases I've looked at).
> >
> > On Wed, Jan 2, 2019 at 1:11 PM Allen George <allen.geo...@gmail.com>
> wrote:
> > >
> > > So, just to be clear, proposed language removals are:
> > >
> > > Approved:
> > >
> > > Cocoa
> > > C++03 or less
> > >
> > > Open:
> > >
> > > JavaME (potential; I’ll look at setting up an Android CI environment
> and
> > > using the standard Java lib there to see if it’s feasible)
> > > .net 4.5 or less (no vote yet)
> > > Silverlight
> > > One of nodets/ts (can we end up only with one, or are there legitimate
> > > differences between the two was the question)
> > >
> > > Allen
> > >
> > >
> > > On January 2, 2019 at 15:55:41, Jens Geyer (jensge...@hotmail.com)
> wrote:
> > > Hi,
> > >
> > > start a vote. A while ago some people claimed that 4.5+ was not
> available
> > > on
> > > their particular subset of Mono. I tend to think that this is no 
> > > longer
> > > the
> > > case anymore, so we should drop anything below 4.5.
> > >
> > > And since wer'e at it: Same for Silverlight, if you ask me. It is 
> > > still
> > > supported until 2012 by Microsoft, but I doubt if anyone really uses 
> > > it
> > > except for maintaining legacy projects. Maybe we should have a vote
> about
> > > that too.
> > >
> > > Have fun,
> > > JensG
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > From: James E. King III
> > > Sent: Wednesday, January 2, 2019 9:08 PM
> > > To: dev@thrift.apache.org
> > > Subject: Re: Support for lib/csharp .NET Framework before 4.5?
> > >
> > > We already support netstandard2.0 (.NET Core SDK 2.0) and build
> > > lib/netcore and run cross tests with that. The docker build image
> > > (build/docker/ubuntu-bionic/Dockerfile) defines the version we build
> > > against. I was wondering about the .NET 3.5 in lib/csharp and
> > > whether we really need a 3.5 and a 4.5 csproj. It's not a big deal
> > > really, just a small simplification, but if a lot of people are still
> on
> > > .NET 3.5 then we may decide not to remove support for it yet.
> > >
> > > - Jim
> > >
> > > On Wed, Jan 2, 2019 at 12:55 PM Randy Abernethy <
> randy.aberne...@rx-m.com>
> > > wrote:
> > >
> > > > While we're in the process of dropping old lang vers, I think we
> > > > should consider only tracking the latest version of .Net Core (2.2).
> > > > Core is CLI build friendly and cross platform. The .Net Framework 
> > > > can
> > > > run all Core apps AFAIK so no loss in dropping the Framework for
> > > > forward looking stuff.
> > > >
> > > > On Wed, Jan 2, 2019 at 6:24 AM James E. King III <jk...@apache.org>
> > > wrote:
> > > > >
> > > > > We currently have two projects to support.NET 3.5 and .NET 4.5. 
> > > > > The
> > > > > differences are minor but it causes us to have to build two
> projects.
> > > > > Do
> > > > > we need to continue to maintain support for .NET < 4.5 ?
> > > > >
> > > > > - Jim
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > --
> > > > Randy Abernethy
> > > > Managing Partner
> > > > RX-M, LLC
> > > > randy.aberne...@rx-m.com
> > > > o 415-800-2922
> > > > c 415-624-6447
> > > >
> >
> >
> >
> > --
> >
> > --
> > Randy Abernethy
> > Managing Partner
> > RX-M, LLC
> > randy.aberne...@rx-m.com
> > o 415-800-2922
> > c 415-624-6447
> >
>
>
> --
>
> --
> Randy Abernethy
> Managing Partner
> RX-M, LLC
> randy.aberne...@rx-m.com
> o 415-800-2922
> c 415-624-6447
> 

Reply via email to