Add support for .NET Core

[rianjs]

• Get rid of Hashtable usage in ANTLR parser
• Get rid of ArrayList usage in ANTLR parser

[rianjs]

Normally I wouldn't merge half-completed work back into master, but there was too much value unrealized due to back-porting changes as I prepped the library for .NET Core. It looks like unit test runtimes will be down below 2 seconds after this work.

[khalidabuhakmeh]

Any thoughts to migrating to xunit?

[rianjs]

To xUnit from nUnit? I haven't thought about it.

[kdaveid]

Hi Rian
Great work and thanks for taking over the project. I have the source running for a while.

I'd like to contribute on ASP.NET Core branch. Is there one? How far are you in porting it?

Thanks and have a great day,
David

[rianjs]

@kdaveid - I'd be thrilled for someone else to also work on this. I don't love managing build configurations and pipelines. This PR has some information on where the .NET Core port stands now: #28

The non-Core code has diverged a little bit, as I've been on a deleting/simplification spree, but I haven't written any new code that will be incompatible with .NET Core, AFAIK. I see several possibilities:

Option 1: delete all the directories underneath net-core/..whatever../src except for the xproj files. Copy and paste the directories containing the unit tests, ical, and ical collections .cs files. That'd get you most of the way there. After restoring the required nuget packages, it should build. I'm not wild about this possibility because Microsoft is going to back to XML-based project files rather than project.json and (presumably) global.json, so I don't have much interest in learning that way of building .NET code.

Option 2: Add another build configuration to the csproj files that already exist. According to the blog post linked, targeting PCL profile 259 will create a binary that runs on CoreCLR, which is effectively a port, skipping the bad tooling support and build/configuration management flux that's happening now. I'm assuming ReSharper's test runner and nunit will play nicely, because I assume that it's just a "normal" csproj-based solution. https://oren.codes/2015/07/29/targeting-net-core/

When I got up the energy, I was going to give option 2 a go. My guiding thoughts are these:

• No duplicate code bases. (What's underneath the net-core is (and always was) meant to be temporary. Whether it gets hoisted up, and overwrites the non-Core source, or something else... it was always temporary, meant as a "what will this take" experiment.
• Emitting binaries should be a single "command". Right now, that's the Batch Build option in Visual Studio. I'm also happy with a CLI process. Either way, I don't want to have to move the .NET Core binary output to directory A, the non-Core output to directories B..D. I.e. no hand-manicuring of binary output. It's too error-prone.
• Nuget should just work. Today that's a 1) Increment the version number in the nuspec file and run nuget pack and we're ready to upload a new version. I don't really want to deviate too far from that relatively straightforward process.

[khalidabuhakmeh]

Option #1 is the one me and my team have been doing. It is better to bite the bullet on migrating to the new project structure, rather than trying to shoehorn stuff into csproj. I believe the .NET team is working on tooling to make this migration automatic.

[rianjs]

I don't think so, @khalidabuhakmeh. project.json and global.json are going away in favor of csprojs:

We had two choices. One was to move all .NET projects to use project.json. This would require us doing tooling work that touches all of the project types in Visual Studio, Xamarin and our partners like Unity. We would have to expand project.json to support all the build scenarios required by each of these project types and provide a migration story. Another choice was to build bridges so an .xproj project can reference a .csproj project and a .csproj project can reference an .xproj project in Visual Studio and Xamarin Studio. The bridge has challenges as well, for example when a customer creates a project they would now have to choose an .xproj or a .csproj, which just adds more choices and complexity.

After looking at our choices, it was apparent that it would be easier to move .NET Core projects to .csproj/MSBuild so all .NET projects use the same tooling and build system.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

[rianjs]

objectType.GetTypeInfo().IsEnum in SerializerFactory works in .NET 4.5+, but not in .NET 4.0. Maybe we need an ifdef. Ugh.

Maybe:
http://stackoverflow.com/questions/3436526/detect-target-framework-version-at-compile-time

[maitredede]

Hi,

Beside the fact that NUnit does not work (yet) is your code ready for dotnet core ?

[rianjs]

Yup. I'm about to push up a branch, or replace the v3 project, I haven't decided which.

I wish nunit would hurry up and get their act together.

[rianjs]

I swapped the .NET Core version for the v3 version. .NET Core was based on v3 (line for line). I view .NET Core as the next major revision of ical.net. When VS2017 drops for real, and nunit is working, I'll publish a real v3 on nuget.

In the meantime, you can clone the repo, and compile the binaries yourself if you need a .NET Core version.

[rianjs]

Hmm, weird. I created the stuff under the net-core directory using VS2017RC from scratch, and it worked for me without needing to fiddle with anything. Be aware that that's the v3 API, so Event is now CalendarEvent, for example. And a bunch of IValueObject-y interfaces are gone, so you'll get real objects back in many cases without needing to cast.

That directive basically says "find and compile all .cs files under the directory trees". I wonder if there were duplicates or something? If you have your Output log still (or can re-create the error), I'd love to see it.

--

Anyway, there are two steps left to incoporating it into the nuget package:

• Figuring out how to package TFM and Core assemblies together, and
• nunit tests working

I could get away with nunit not working so long as all fixes are back-ported to v2 where I can still run the test suite.

[rianjs]

No, my VS2017 is from 3-4 weeks ago. This is why I don't usually mess with pre-release stuff: it's a moving target and a complete time-waster.

[jtillman]

Bumping now that VS17 Finally was released

[mixerp]

What is the current status?

[rianjs]

Waiting for nunit + ReSharper support.

[felschr]

@rianjs Would you be ok with migrating to xunit? I could probably spare some time to help you with it.
I recently migrated a project of mine from nunit to xunit, it shouldn't be too hard.

Also could you publish a prerelease on NuGet of the current version?

[rianjs]

Would you be ok with migrating to xunit? I could probably spare some time to help you with it.
I recently migrated a project of mine from nunit to xunit, it shouldn't be too hard.

I'm not convinced it's worth the time. The nunit people are working on real .NET Core support, and R# is (apparently) right around the corner.

If we get to June-July and there's still no real .Net core nunit, I'll be more interested switching to xUnit. In the meantime, doing the work (there's about 350 unit tests) just to move a shipping date closer doesn't seem worth it.

Also could you publish a prerelease on NuGet of the current version?

Sure, I'll see if I can do that.

[rianjs]

netstandard1.6 nuget package:
https://www.nuget.org/packages/Ical.Net/3.0.1-alpha

The API is slightly different. Off the top of my head, all the interface version of calendar components are gone:

• IEvent -> CalendarEvent
• IAlarm -> Alarm

That sort of thing. It should be fairly intuitive.

[rianjs]

I probably should have named it 3.0.1-net-core-alpha instead. Oh well.

[felschr]

@rianjs I'm fine with that. Let me know if/once you would like my help.
Thank's for putting up the alpha!

[rianjs]

If you try it out, let me know if it doesn't behave as expected.

Ideally I'd like to retire the Framework versions, and just have .NET Core versions, as I believe Framework versions will use .NET Core libraries, assuming the API surface area (netstandard version) overlaps.

[felschr]

Yeah, .NET Standard is really awesome for creating libraries. I was to impatient and got the tests running with xunit in my local dev env.^^ For some strange reason the dotnet process crashes during some of the tests. Also a few of the other tests generally fail. I'll probably push the changes to my fork tomorrow and will let you know if I find some actual errors.

…

On Wed, Mar 22, 2017, 21:54 Rian Stockbower ***@***.***> wrote: If you try it out, let me know if it doesn't behave as expected. Ideally I'd like to retire the Framework versions, and just have .NET Core versions, as I believe Framework versions will use .NET Core libraries, assuming the API surface area (netstandard version) overlaps. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADKSk31x3hYNRceekYj4sp0aKa1B1KCQks5roYqLgaJpZM4JD5hd> .

[remyjette]

Hey, thanks for pushing the net-core version to NuGet!

I'm giving it a try in a sample .NET Core console app. I made a quick pull request to the .nuspec to add the NodaTime dependency, but I have one other issue. EDIT: See #253

[rianjs]

Let's fork off separate issues, using this as a master ticket:

• Stick a reference to Add support for .NET Core #23 somewhere in the text of the new ticket
• Prefix the issue title with [.NET Core], and label it v3 and whatever other labels apply.

[rianjs]

This has been done for a while now.

[jasoncoding]

Could you update where things are with respect to .net core support? Does version 4.x have core support or is it still back in the 3.x.beta releases?

[remyjette]

I'm using 4.x in a .NET Core project right now.