.Net Core Compatibility?

[brentarias]

Are there any plans to refactor/port for .Net Core compatibility?

[timmus]

I would contribute towards a .net core project if there is any interest. Thanks for the great library!

[neumann1990]

@timmus ditto. I would love to get FileHelpers to .net core.

[neumann1990]

The result of running the ApiPort utility on the FileHelpers assemblies (0 means not easily portable, 100 means it's basically already ported):

It looks like the core FileHelpers assembly would be easy to port to .NET Standard. The wizard, progress bar, and old examples would be pretty rough.

[timmus]

It would be great to get a priority list from the group. Maybe those difficult items can be excluded. I am new to this library and have no insight into what most folks use. I currently am using it for generating fixed length files in the NACHA format. I intend to use NPOI for another project but the file formats are so dynamic that I suspect FileHelpers strongly typed approach wont help. I look forward to continuing the discussion!

[timmus]

BTW that is a REALLY cool report!

[MarcosMeli]

Hi Folks !! Thanks a ton for join in !!

I already tried to port the library and if we deprecate the DataLink feature and part of the runtime support (for example for datatables) so the library can work seamless with little changes (most of them are Reflection Related, because the .Net Core as a lightweigth TypeInfo class but provides a extension method to get same info we need.

I just see that the new .Net Core 1.1 added some missing apis that most libs uses

What do you think of create a new branch and just make the FileHelpers Core to build in .net Core ?

Thanks Again Marcos

[timmus]

I am happy to follow your lead. How can I help?

[MarcosMeli]

Great !!

I will create the branch and change to .net Core 1 the main project.

I will do some sample commits with the changes required so you can see what we need, at first there are hundred of errors and we need to fix one by one at first to get a pattern

To avoid conflicts we can do some small changes and push them to github, I will give u write access if you want or we can use Pull Request

Best Regards Marcos

[MarcosMeli]

The API Changes in .NET Core 1.1 not are helping us anyway: https://github.com/dotnet/core/blob/master/release-notes/1.1/1.0-1.1-api-diff/1.0-1.1-api-diff.md

[MarcosMeli]

Branch dotnet-core Created :)

First Commit: https://github.com/MarcosMeli/FileHelpers/commit/bf246fed4a07dd9b918aab3eaa07092445e18a8b

[neumann1990]

This is great news! I'm glad everyone's on board with the port. I'll try to follow your lead @MarcosMeli :)

Here's the .NET Core team's suggested approach for porting over to .NET Core:

Here's the blog post the advice comes from: https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

[MarcosMeli]

Great !!

I just make a lot of advantage changing some code and removing some features (at least for now)

https://github.com/MarcosMeli/FileHelpers/commits/dotnet-core

You can see there the commit history of the dotnet-core branch

Pull Requests welcome 👍 Best Regards

[timmus]

Fantastic!

[neumann1990]

Sorry, the holiday's are a little busy for me. But I'm back and ready to help out. Where did you leave off @MarcosMeli?

[dwdickens]

Asp.net core is the future! Great idea to support it :)

[silkfire]

What's the status on the . NET Core 1.1 port?

[mcavigelli]

I wrote a proposal for a roadmap #231 that I would like to have reviewed by @MarcosMeli. In brief:

1. Marcos wrote to me that it is a long way to go (maybe with .NET Standard 1.6 not doable)
2. The last release is two years ago.
3. .NET Standard 2.0 is scheduled for Q3 2017

My proposal therefore is

1. Focus on a Release 3.2
2. Narrowing gap from current code base to .NET Standard 1.6 or 2.0 and still keep the API of Release 3.2
   1. Replacing Interfaces with only need internally and not present in .NET Standard, like IClonable
   2. Replacing Types that are only used internally and not present in .NET Standard, like ArrayList, HashTable, some Xml types I think

[mcavigelli]

I've watched the movie on channel 9 where the .NET API Portability tool is shown (the tool that does the nice report shown by @neumann1990 earlier in this thread).

In order to know how far the FileHelpers assembly (.NET Framework) is from .NET Standard 1.6, and how we are progressing, we should start by setting up the measurement as part of the appveyor build:

• [ ] The appveyor build should
  • download the nuget package from the project feed https://dotnet.myget.org/gallery/dotnet-apiport
    • run the console tool with a small powershell skript
    • publish the html report (maybe as artefact of the build)

Is anyone interested in this first task?

Later we can split up tasks by type not being present (IClonable, ArrayList, ...) and / or FileHelper area (Exceptions, Events, Converters, Engine, etc.).

It is important for me to keep the build green and to keep the source compatible with release 3.2 (no branches for porting to .NET Standard, but integrating small changes by change in the master branch) as long as possible, or hopefully until the end:-).

To keep the work focused, we should focus solely on FileHelpers (not FileHelpers.NPOIStorage).

Does that make sense to you?

[mcavigelli]

I've installed the api-port Visual Studio extension and ran the analysis for the FileHelpers.dll to see how compatible it is with .NET Standard 1.6.

When running from within Visual Studio, one gets 490 messages (each message corresponds to one usage). I've grouped them by API we are using.

Usages (roughly)	.NET Framework Namespace / Type	FileHelper Type	Problem	Fix / Remark
19	CodeDom and AppDomain	ClassBuilder and DynamicCompilationException	Not present	Skip Classbuilder in a first version?
60	System.Collections.*	various types	Collections not present	Should be replacable with generic collections
2	ComponentModel TypeCoverter and TypeDescription	FieldNullValueAttribute	Not present	?
100	System.Data. *	various types	Several problems	Exclude parts of it in a fist version?
2	System.DateTime	ErrorManager	Two particular methods not present	Should be replacable
1	System.Exception	FieldBase	Report says: false positive, object.GetType is sufficient	?
3	System.Globalization	ConverterHelper	Accessing CultureInfo to get information about number formats	?
1	IClonable	RecordInfo	Not present	old Interface, should be droppable
59	System.IO	various types	Closing and creating of Read and Write Streams, probably other problems too	?, Split problem
58	System.Reflection	ClassBuilder, ReflectionHelper	Emit * not present	?
4	System.Security.Crypthography	ClassBuilder	Type not present, some methods obsolete in .NET Framework	Other implementations might be present
14	System.Text.Encoding	various types	Trying to get default Encoding	Encoding.GetEncoding(0) should do the job
49	System.Type	various types	Used for queries of types	?
120	System.Xml	various types	Reading and writing xml	Should be other ways to read / write xml

I see the following strategy

1. Fix those that seem feasible

   • Collections
   • IClonable
   • DateTime
   • TextEncoding

2. Exclude parts in .NET Standard binary (maybe with precompiler directives)

   • ClassBuilder (heavy use of CodeDom and AppDomain), seems like an isolated part
   • System.Data: widely used. Could usages be extracted into partial files that are then excluded by precompiler directives as well?

3. Medium complex problems that need more analysis. Those are big, certainly the functionality is in .NET Standard 1.6, but can we use it in a compatible (Release 3.2, .NET Framework 4.5, 4, 3.5) way?

   • System.Xml
   • System.IO

4. See how far we get and how fast, solve the complex problems later with more expertise

   • System.Type
   • System.Reflection (in ReflectionHelper, ClassBuilder will be dropped by then) Others might be excluded, ie. not compiled into .NET Standard binary.

I might write issues to split up the work if anyone is interested to help with the work.

[neumann1990]

Count me in. Are we going to branch off of the existing spike branch? Are there tests to fall back on while making these changes?

[mcavigelli]

The changes shall be made on the master:

1. There are many bugfixes and new features in the code since the last release (3.1) about two years ago.
2. There are still bugfixes and pull requests being published
3. It will probably take some time to get a decent .NET Standard (be it 1.6 or 2.0) targeted FileHelpers library. It is even unclear, if a useful FileHelpers library is doable with .NET Standard 1.6.
4. I would like to integrate the work being done for .NET Standard portablility and for features / bugs in one branch, in order to have less work and make sure that both efforts are not lost.

The build (compile / tests) on both appveyor and travis should be green all the time.

You can find issues #235, #236, #237 and #239 for step 1 (replace old .NET Framework types with types that are both in newer .NET Framework and .NET Standard 1.6 present). Please have a look at them and let me know what you think!

Hope that helps us to get started!

Have a nice week, Matthias

[MarcosMeli]

Hi everyone, I was a bit busy lately

Today Microsoft is releasing .Net Standard 2.0 Preview

I think that we must target that .Net version that will work on .net 4.6.1 and also in .Net Core 2.0

They added a ton of missing APIs, in my trial to port to .Net Core 1.1 a lot of stream and file handling is missing and a lot of code need to be rewritten.

You can check the changes in the branch: https://github.com/MarcosMeli/FileHelpers/commits/dotnet-core

What do you think guys ? Marcos

[MarcosMeli]

Some captures from the Build2017 Conference

.Net Core 2.0 Preview https://blogs.msdn.microsoft.com/dotnet/2017/05/10/announcing-net-core-2-0-preview-1/

[mcavigelli]

Hi there

I think we should try to include .NET Standard 1.6 support into the master branch.

.NET Standard 1.6 is out for several months, it is available on many computers. .NET Standard 1.6 is a subset of .NET Standard 2.0. That means, what runs with 1.6, it will also run with 2.0. The work towards 1.6 will not be lost, no matter how far we get.

To get .NET Standard support we have two possibilities

1. Radical and quick by spinning off a branch and do the necessary steps. These changes will be out of sync with the master branch. Getting a useable library will take time, if the journey cannot be completed all work will be lost.

2. Iterative, partial support. Integrating into master branch step by step. By adding .NET Standard support iteratively, we will probably have more work. However each and every commit will go into something releasable. All current and future bug fixes and features will be included. The now targeted frameworks (.NET Framework 2.0 to 4.5) and libraries (FileHelpers.NPOIExcelStorage) are on board and will profit as well.

As written two weeks ago, I suggest an iterative way.

1. Modernize some old .NET Framework types, see issues #235, #236, #237, #239.

2. Identify parts that are not portable. Setting up a second project and including the compilable namespaces / folders. Maybe some classes need to be split up into partial classes, for instance moving dependency to System.Data into partial class, while including the main functionality in .NET Framework dll and in the .NET Standard dll.

3. Solving Xml and IO problems. I think there should be types / methods that are both in .NET Standard 1.6 and .NET Framework 4. Maybe this needs to be done before setting up a basic .NET Standard project.

4. Finally solve those problems with System.Type and System.Reflection that are left in the code.

I think it is worth to do some more work. The main benefits are that work can better split up into issues and that the .NET Framework libraries profit as well.

What do you think? I also wrote a pull request for the website to explain my idea. I did not change the website directly in order to have the idea reviewed.

Have a nice week, Matthias

[neumann1990]

I really like the idea of iterative. It's much easier to ensure correctness and debug that way. That's my vote.

It might be worth transitioning to .NET Standard 2.0, if only because I think it would be easier. They have like 3 times as many APIs methods exposed, including namespaces like reflection and serialization.

Also, it was up in the air for a while but they were talking about making .NET Standard 2.0 a requirement for .NET Core 2.0, so it might be the best option.

[guillaumejay]

I think it would be better to start with 1.6 first, since it's officially production code.

Starting from master is good too since there is quite a lot of bugfix on it.

[MarcosMeli]

I there guys, I don't have any problem with both aprroachs, but I don't have time for 1.6 support, also the API surface is so small in 1.6 that the code becomes really ugly in my perspective and needs some extra helper code to cover that.

Port the entire library to 1.6 will be a huge work, I started it in the branch I mentioned. I do a lot of work and was not even close to get anything working 👎

The problem is that 1.6 api surface is even less than the .Net Core one, is an intersection between .Net Framework and .Net Core, a bad decision by Microsoft because is hard to work with it

Here is another presentation on .Net Standard

http://www.talkingdotnet.com/whats-new-in-net-standard-2/

[MarcosMeli]

I also recommend to just port to 1.6 the basic file Handling.

Nothing of DataLink, Excel, etc Nothing of Sorting. None of the Dynamic/RunTime feature (will not be compatible with next version of the library)

Importante: A lot of performance optimization uses features that do not exist in .Net Standard 1.6 so the reflection to set or read values of fields will be very slow without dynamic IL code generation. So the users of the library will get a downside if uses this version

Best Regards Marcos

[mcavigelli]

Hi Marcos

Yes I agree, we should start with a minimum set of features. I have played with cutting out some features of FileHelpers (main library).

I noticed that by removing the Dynamic feature, one has not to rewrite any Xml handling.

Thank you for your recommendations, Matthias

[navk27]

so, what's the status of this project (filehelper compatibility with .net core)? Is it in usable stage with some features?

[usametov]

here is the latest report from api port:

it looks like the only thing which is not supported is OleDBConnection. if that's the case then why don't we move it to separate lib, and call it 'MS platform specific plugin' ? We would need to refactor it in order to support plugins. Should we vote on this?

[Hackman-Sanchez]

Hi guys,

Absolutely love FileHelpers, it works like a charm. I'm currently migrating my project to .net core 2.0. I only use the library to parse CSV files into lists of objects for processing.

How is your migration going? when do you expect a version to be finished? From the above posts it sounds like you have basically done all the work that would be required for this library to satisfy my needs, and I imagine a lot of other people too.

If the release date is far away, would it be possible to get an alpha version of FileHelpers that only performs CSV parsing?

Thank you very much

[mcavigelli]

Hi there

Having completed #174 I will look into this next. Thank you for your nice words and your patience, Matthias

[mcavigelli]

Hi there

It seems that with .NET Standard 2.0 we can create a subset of FileHelpers

• without Dynamic and hence without CsvEngine
• without DataLink (or only SqlServerStorage) => probably easiest to exclude the whole DataLink feature

@Hackman-Sanchez How are you parsing your CSV data?

I first want to finish the work on #259 and 3.2.6.

I've run the migration analysis as well and indeed there are only few types we need, that are not in .NET Standard 2.0. Therefore I have added this issue to release 3.2.x. A subset of the FileHelpers.dll should be possible without changing the existing API.

Reading the messages in Visual Studio leads to 4 types of FileHelpers.dll that cannot be compiled:

1. ClassBuilder
2. DynamicCompilationException
3. AccessStorage
4. OleDbStorage

Matthias

[MarcosMeli]

Hi there

I agree about to leave the DataLink feature off and the Dynamic one must be rewritten anyway, because has some never implemented features and the way that it compiles the dynamic types needs a lot of permissions because it generates dynamic assemblies and is a bit hard to configure in shared hosting scenarios.

You can exclude them from the project Matthias

Best Regards Marcos

On Mon, Sep 25, 2017 at 4:04 AM Matthias Cavigelli notifications@github.com wrote:

Hi there

It seems that with .NET Standard 2.0 we can create a subset of FileHelpers

• without Dynamic and hence without CsvEngine
• without DataLink (or only SqlServerStorage) => probably easiest to exclude the whole DataLink feature

@Hackman-Sanchez https://github.com/hackman-sanchez How are you parsing your CSV data?

I first want to finish the work on #259 https://github.com/MarcosMeli/FileHelpers/issues/259 and 3.2.6 https://github.com/MarcosMeli/FileHelpers/milestone/4.

I've run the migration analysis as well and indeed there are only few types we need, that are not in .NET Standard 2.0. Therefore I have added this issue to release 3.2.x https://github.com/MarcosMeli/FileHelpers/milestone/5. A subset of the FileHelpers.dll should be possible without changing the existing API.

Reading the messages in Visual Studio leads to 4 types of FileHelpers.dll that cannot be compiled:

1. ClassBuilder
2. DynamicCompilationException
3. AccessStorage
4. OleDbStorage

Matthias

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MarcosMeli/FileHelpers/issues/213#issuecomment-331794120, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbRTBhS1lV6Nto3OL72q1gSnilYIKWwks5sl1BjgaJpZM4JpNqz .

[42degrees]

Hello All,

I had discounted using FileHelpers in the past because of the limitations of .net Core 1.0, but it looks like with .net Core 2.0 FileHelpers has real possibilities. I looked at the .net Core branch and it's been abandoned. If I wanted to use and contribute to a .net Core 2.0 subset of FileHelpers, where would I look? I thought maybe it would be done with multi-targets, but I don't see that either.

Now that AWS is supporting .net Core 2.0 for their serverless functions, this would be a really wonderful tool to have.

Thanks for all you do and a wonderful library!

Scott

[brunotourinho]

Any progress on porting?

[mcavigelli]

We have published an alpha release of FileHelpers dll, targeting directly .NET Core 2.0. See https://github.com/marcosmeli/filehelpers#current-support-for-net-core for some comments on it.

Please let us know, if that release works for you.

Matthias Cavigelli

[mcavigelli]

With pullrequest #295 we are targeting .NET Standard 2.0!