Support .NET Core

[tpluscode]

No description provided.

[colin-young]

Let me know how I can help out with this. I'm playing with HALight at the moment, but I'd really like to be able to use this and see Argolis up and running on Core also.

I do realize that's likely a non-trivial task though :)

[colin-young]

I got this far: 9f506f2. Mostly by removing the NullGuard and fixing up some reflection (plus hacking out the Impromptu Interface stuff). I'm about 99% certain it isn't correct, but the test project has 306 errors at the moment...

[tpluscode]

About .NET Core, maybe initially it's enough to only have the actual library migrated and leave test project on full .NET?

[tpluscode]

It's a shame that Fody doesn't work in .NET Standard/Core yet (see Fody/Fody#206). I'm using Fody plugins extensively in my various projects.

[colin-young]

I'd feel much more confident about having some tests running especially in light of linked-data-dotnet/json-ld.net#11. By knowing just enough about json-ld to be dangerous I mean that I'm at the point that I don't know what I don't know, but on the plus side, I do know that what I don't know is >> what I do know.

I think one of the bigger issues at the moment is I haven't tried to untangle the paket/nuget/project.json mess, so a lot of errors are likely the result of missing dependencies. It was very late last night when I got library building so I didn't have the energy to deal with the test project (US, eastern time).

I've noticed you do seem to like Fody :) I've avoided it due to some extremely poor experiences with PostSharp, although from reading up on Fody it looks like they may have avoided some of my biggest objections.

[colin-young]

I'm looking at the repo now and it appears that the commit is in my fork in the net-core branch. I just pasted the commit hash into the message and it appears as though GitHub is showing it as of it's part of your repo. If you look at the commit history, it shouldn't be there. Seems like a UI issue. You had me scared for a minute there...

…

On Feb 3, 2017 4:06 AM, "Tomasz Pluskiewicz" ***@***.***> wrote: Forgive my ignorant question, but how is it possible that you committed directly to this repo. Without forking and even creating a branch? :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABuMQhIBs5-R1S2ZwbhTja1YJ8j7lAuHks5rYu4jgaJpZM4L1NbQ> .

[tpluscode]

I'd feel much more confident about having some tests running

Ofc, you'd still run tests against .NET Framework 4.6. It has to count for something

the paket/nuget/project.json mess

Which version dotnet are you using? According to these tweets, paket should work fine with project.json. I'm more concerned about replacing dependencies which don't target .NET Standard/Core yet.

I've noticed you do seem to like Fody :)

I certainly do. I use a number basic plugins on a regular basis. I'm curious what's your beef with PostSharp. What kind of bad experiences have you had?

You had me scared for a minute there...

Yea, I'm guessing GitHub stores forks as branches and not physical clones. It would explain why unmerged commits are accessible through "my" URLs. It also explains why it's possible to merger PRs even after a fork has been deleted.

[colin-young]

Ofc, you'd still run tests against .NET Framework 4.6. It has to count for something

Yeah... it's still early (or late) and that didn't occur to me :) Of course I'm doing my dev on OS X at the moment, so I can't run the 4.6 tests myself (my day job is in a locked-down corporate environment where they're just starting to think that maybe there's something to this open source thing after all).

Which version dotnet are you using? According to these tweets, paket should work fine with project.json.

I need to create a project.json first with the correct packages listed. The mess is more having to figure out how they interact, and getting comfortable with paket. So far I've run into a few issues that I don't 100% understand how I got around. In particular, it was pulling the wrong version of Newtonsoft.Json (6.x instead of 9.x) and complaining it didn't support .Net Core, which is true for 6.x, even though 9.x was listed explicitly somewhere, and when I removed the paket.lock file and tried to regenerate it, it complained they were out of sync, and then eventually I managed to get things building, but, as I said, I don't really know how/why. I'll pay closer attention tonight and see if I can learn a bit more about it.

I'm curious what's your beef with PostSharp. What kind of bad experiences have you had?

2 (and a half?) things really. In one case we experienced really poor performance, but that may have had to do more with intercepting every single method entry and exit and logging it than PostSharp itself. Then, once you've added it to your project it's nearly impossible to eradicate it when you decide you no longer want to use it. There's also the issue that it needs to be installed (as in full installer installed) on any system that wants to build the project. And then there's the issue that I can't see exactly what it's doing to my code. And that makes me nervous, no matter how much test coverage I have. Fody seems to have addressed all of those concerns, so it's just the lack of Core support that's a major issue.

Yea, I'm guessing GitHub stores forks as branches and not physical clones.

http://stackoverflow.com/a/6286877/173225 explains it pretty well, but I think the issue we see here is probably a UI implementation detail since my best guess is that git is still able to treat the fork as a sort of branch since it forked from a specific commit and they're just failing to account for the commit being in a different repo.

[tmarkovski]

Bump. Still no plans for supporting .netstandard?

[tpluscode]

hey @tmarkovski thanks for bringing this back to my attention!

Still no plans for supporting .netstandard?

Not at all, I'll definitely want that. And I think that all upstream dependencies and tools used here now support .NET Standard. Should get started on that