Added support for .NET Core 2.0 #286
Conversation
This ports the main FileHelpers library to .NET Standard 2.0 so it can be used in cross-platform .NET Core. In this stream, DataLink no longer supports Access or OleDB. T4 templates are provided by the original project, and the output is linked at build time. Otherwise all other features are intact.
|
@mcavigelli what are the odds of getting this released? We love file helpers, but lack of netcore support is forcing us to look at other options =( |
|
Depending on your project policy/tolerance for risk, if you click on Allow
pre-release in NuGet, my version is listed with “-unofficial” suffix.
On Wed, Mar 14, 2018 at 6:01 PM Jonathan Goldman ***@***.***> wrote:
@mcavigelli <https://github.com/mcavigelli> what are the odds of getting
this released? We love file helpers, but lack of netcore support is forcing
us to look at other options =(
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#286 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAH6St4_IM8goMT1EKKOakw6D6nl6l65ks5teZNBgaJpZM4SmHoF>
.
--
Daniel Crenna
Conatus Creative Inc.
cell:613.400.4286
|
|
Hi Daniel !! Thanks a ton for the PR, I will try to get some time to merge this PR in a new branch and publish a pre-release in the oficial NuGet package so you can consume it. I will prefere to remove all datalink releated features of the library, because are old designed, so better with the core utilities. What about removing the VB dependence, and allow only C# dynamic code ? What do you think @mcavigelli to merge this version and publish it ? Thanks to all !! |
|
I can remove DataLink, as for VB, Roslyn supports it in .NET Core natively,
so it’s no sweat to keep it there, but it’s up to you. I certainly don’t
use it.
On Wed, Mar 14, 2018 at 6:30 PM Marcos Meli ***@***.***> wrote:
Hi Daniel !!
Thanks a ton for the PR, I will try to get some time to merge this PR in a
new branch and publish a pre-release in the oficial NuGet package so you
can consume it.
I will prefere to remove all datalink releated features of the library,
because are old designed, so better with the core utilities.
What about removing the VB dependence, and allow only C# dynamic code ?
What do you think @mcavigelli <https://github.com/mcavigelli> to merge
this version and publish it ?
Thanks to all !!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#286 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAH6SmpNDqQvCK5_-bdxQ_yXgXQPch69ks5teZoVgaJpZM4SmHoF>
.
--
Daniel Crenna
Conatus Creative Inc.
cell:613.400.4286
|
|
Hi Daniel and Marcos Thanks for your pull request. I did not know, that it is possible to use Reflection.Emit with .NET Standard as in the class Core/ReflectionHelper the case. Thanks for pointing that out. As for the features we want to support, I would opt for just FileHelperEngine. I think that is the feature set that we want to support over time. What do you think? I hesitate to add one or two more .sln files, referencing a new .csproj project with so many links. Matthias |
|
The reason there is another SLN is that the package system is different and won’t work together with what you have. The csproj I created has multi-targeting for .NET Standard 2.0 as well as NET 4.6. So it comes down to your build process for supporting legacy DLLs in one project system combined with those in the new system. Up to you which linked files you want to include that build, it’s working for my purposes so I’m not sure if I can be helpful integrating with your build pipe. I went for full compatibility but that’s up to your taste.
… On Mar 19, 2018, at 5:46 PM, Matthias Cavigelli ***@***.***> wrote:
Hi Daniel and Marcos
Thanks for your pull request.
I did not know, that it is possible to use Reflection.Emit with .NET Standard as in the class Core/ReflectionHelper the case. Thanks for pointing that out.
As for the features we want to support, I would opt for just FileHelperEngine. I think that is the feature set that we want to support over time. What do you think?
I hesitate to add one or two more .sln files, referencing a new .csproj project with so many links.
I had in mind to add the csproj at the same level as the main lib and just include those files we would need to build FileHelperEngine. That would simplify the maintenance of the project.
Matthias
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
- only one .NET Standard SLN for OnlyMainLib - Multi-target support for .NET 4.0+
|
Latest commit reduces to a single SLN file w/ multi-targeting that will emit .net 4.0+ assemblies, so it could replace the original OnlyMainLib SLN if the build system was changed. |
|
I recently started porting an internal framework to .netstandard and was wondering what the likelihood of getting this update released. We love filehelpers and use it heavily. |
|
Hello Daniel I have looked again at the FileHelpers.Standard project with the linked files: All the linked files are linked, with the exception of DynamicCompilationException and I think the strong name key FileHelpers.snk should not be duplicated, isn't it? The new project compiles the libraries to a different path and the .Net Framework libraries are duplicated. I suggest that we place the FileHelpers.Standard project next to the FileHelpers project. Does that make sense to you? Thank for your help, Matthias |
|
Currently struggling with System.Emit.Lightweight; it is unlisted on nuget.org: It was intentionally unlisted end of April: https://github.com/dotnet/corefx/issues/29365. Matthias |
|
It seems that this package is not returning any time soon. I think an alternative to DynamicMethod is to read/write values through System.Linq.Expressions in ReflectionHelper.cs. Expressions are available in .Net Standard and .Net Framework. Concerning support in .Net Framework, I am not sure what is available in older versions such as 3.5. I will look into the matter beginning of next week. |
|
I think it’s simply of matter targeting .NET Core and .NET Framework separately. If it were me I would not be willing to trade off the efficiency to avoid having two csproj files.
… On May 17, 2018, at 4:51 PM, Matthias Cavigelli ***@***.***> wrote:
It seems that this package is not returning any time soon.
I think an alternative to DynamicMethod is to read/write values through System.Linq.Expressions in ReflectionHelper.cs. Expressions are available in .Net Standard and .Net Framework. Concerning support in .Net Framework, I am not sure what is available in older versions such as 3.5.
I will look into the matter beginning of next week.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
nothing else needs to change, we're just no longer targetting a platform with ambiguous reflection capabilities
|
@mcavigelli after thinking about this more, not targetting .NET Standard 2.0 and targetting .NET Core 2.0 is just fine. In fact, it's more correct because Microsoft is explicitly stating that not all .NET Standard targets support the reflection emit namespace, but we're talking about a much smaller pool of devices than we need to worry about. I've updated the PR to work as it always did, except targeting .NET Core 2.0, where the dependencies we need exist. |
danielcrenna
changed the title
Yes, for some reason I never went back to clean that up, but I have now.
(It's now NETCOREAPP2_0), this is an "intrinsic" conditional compilation that VS2017 is branching off on its own for multi-targetting support (TargetFrameworks in csproj), because the csproj I prepared is outputting every target under the sun from .NET 4 to .NET Core 2.0, with the idea being that you wouldn't need the old one, though if you want to upgrade code analysis to 2.8.0 you will have to remove .NET 4.0 as a target and keep yours around anyway.
True, this is fixed.
I've done the work of "inlining" the core project with the main project, it makes sense. I'd leave the nuget packaging work up to you. |
|
Is this good to go? Can we get it merged? |
|
Yes I am merging... |
|
Here are the tasks:
|
|
The alpha release of FileHelpers dll for .NET Core is available at https://ci.appveyor.com/nuget/filehelpers, Let me know, if you can use the dll on your .NET Core projects! Thanks you for your testing of the alpha release, Matthias Cavigelli |
|
Hi Daniel I think I never wrote thank you! Thank you for your valuable help and for the code that made the current release possible! Thanks a lot, Matthias |
|
@mcavigelli I don't think there's any harm in pushing the alpha package to nuget proper - it's much easier to consume from there for those of us using proxies etc... |
6 participants
This ports the main FileHelpers library to .NET Standard 2.0 so it can be used in cross-platform .NET Core. In this stream, DataLink no longer supports Access or OleDB. T4 templates are provided by the original project, and the output is linked at build time. Otherwise all other features are intact.