Support .NET Core #11
Comments
|
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... |
|
About .NET Core, maybe initially it's enough to only have the actual library migrated and leave test project on full .NET? |
|
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. |
|
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. |
|
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>
.
|
Ofc, you'd still run tests against .NET Framework 4.6. It has to count for something
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 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?
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. |
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).
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.
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.
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. |
|
Bump. Still no plans for supporting .netstandard? |
|
hey @tmarkovski thanks for bringing this back to my attention!
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 |
No description provided.
The text was updated successfully, but these errors were encountered: