search

goblinfactory / konsole

Home of the simple console library consisting of ProgressBar, Window, Form, Draw & MockConsole (C# console progress bar with support for single or multithreaded progress updates) Window is a 100%-ish console compatible window, supporting all normal console writing to a windowed section of the screen, supporting scrolling and clipping of console output.
721 stars 62 forks source link

.NET Standard support and VS2017 #8

Closed adamhathcock closed 7 years ago

adamhathcock commented 7 years ago

Hopefully this mostly covers https://github.com/goblinfactory/konsole/issues/7

I need to investigate why the tests kind of run weirdly. I have to downgrade the packages for the tests. I wonder if it's because of NUnit. Might want to look at XUnit instead.

The samples kind of run on .NET Core on Windows. It looks weird. On my mac, there is something missing. Blinking cursor? I'll look into it sometime.

Also added a basic Cake script :)

adamhathcock commented 7 years ago

I'm targeting net standard 1.5 (which is .NET 4.6.2) but it could probably be reduced. The samples should probably be reverted to net462 instead of using netcoreapp1.1 but I wanted to see what happened.

goblinfactory commented 7 years ago

Hi @adamhathcock Apologies for the slow response; I saw the pull request yesterday and unfortunately this morning is the first time I have the chance to review;

  1. Yaaay (+10) for the Cake script, wooot! Going to be fun testing that, have been meaning to do that for a while.
  2. I need to understand the implication of .NET starndard support and VS17. I have some reading to do to understand the benefits, and if they actually apply to this Konsole application due to the limited cross platform support of Windows Console library. Specifically, not sure this would make sense in a mobile app in any way?
    • @adamhathcock Could you please give me a quick overview of the benefits of Konsole moving to standard? Was there a need in one of your projects where you wanted to use Konsole but couldn't because it wasnt standard? (I may be totally missing the point of .NET standard, ...this is written before I'll have done my reading.)
  3. I may need to decompile the System.Console class in .NET Standard, (if there's in fact a different dll for System.dll in standard? I know... this shows exactly how little I know at the moment) and see how the different methods are implemented, in case there's anything different. For example on Mono, some methods are just stubbed out, e.g. Scroll.
  4. I need to consider if any addditional tests will be required. How will I know (gaurantee) that Konsole will work, anywhere it get's referenced? I know that parts of Konsole are not cross platform.
  5. will need to merge this into my 'menus' branch, as that will become the next release, contains some much overdue fixes, and see what's involved in doing that.

Please forgive me if I'm describing a whole bunch of stuff that has nothing to do with .net Standard, as I said before this is written before I will have done any reading.

Lastly; I'll be doing some reading on best practices for encouraging contributors and recommended workflows for open source projects before I merge this or work with it.

Thanks again for the contrib,

cheers, Alan

goblinfactory commented 7 years ago

Hi @adamhathcock

ok, done a brief bit of reading.

I'm not certain that supporting .NET Standard will be of much or any value to 'Konsole'. It may even be misleading suggesting it can be used, when I don't believe it can.

All that the standard guarantees is that your code will compile if you have code that relies on any of the libraries. It doesn't promise that the different platform implementations will work as expected across platforms.

For most projects the minor differences across platforms can often be ignored if the vast majority of the system or application still provides value and passes the 'acceptance tests' for that platform.

For Konsole to target .NET Standard, @adamhathcock you would need to please include acceptance tests for each platform and that's not included in the pull request, so I'm closing this, for now pending a discussion between you and .

Happy to re-open later if we agree that makes sense.

I also think that simply creating a .NET standard solution does not mean that the library will be cross platform. It only means you can create an assembly that can be referenced cross platform.

We will still have the same issue that I described in #7 (.NET core support).

The biggest challenge is that is that Console.MoveBufferArea is stubbed in Mono, while it's technically implemented, if you dissasemble MoveBufferArea on Mac in VisualStudio for Mac, you'll see it's stubbed out with a blank { nothing to see here !! }. Doh!

So, closing for now, requires further discussion, requires tests, requires an alternative platform dependant implementation of MoveBufferArea at the very least for Linux, with platform detection, plus acceptance tests.

regards,

Alan

goblinfactory commented 7 years ago

Sorry, prematurely closed this, I need to leave it open for a while for discussion, my bad! If we can merge, or change and merge I'll be the first to dive in to help make this happen. Cheers, A

adamhathcock commented 7 years ago

I want to have a cross platform app basically. .NET Standard is basically an API spec like your thinking but it allows your library to work with Full Framework, .NET Core, whatever if it implements the spec.

Now, I don't care about Mono but I do care about .NET Core. I guess you're right in that not everything is going to work correctly. I didn't do much in the way of testing because I'm not sure how a lot of it works.

I guess I'm really only interested in the progress bar and I could just copy/paste that but I figured maybe you needed a bit of help to see about .NET Core/.NET Standard.

Maybe make a subset of things be .NET Standard and some things be Full Framework. You could also help out with System.Console in .NET Core if some things aren't implemented if you were so inclined: https://github.com/dotnet/corefx/tree/master/src/System.Console/src/System

Anyway, what do you think?

goblinfactory commented 7 years ago

As I've already said; just switching over to .NET standard won't allow your app to suddenly run on all platforms. You have to still fix any oustanding .net methods that have been stubbed by various authors to allow code to mostly work. Unfortunately one of the extremely few empty method stubbs that were done, was to MoveBufferArea(...) which Konsole relies heavily on to scroll the screen.

I need to find a cross platform way to scroll the screen that does not require redrawing the scrolled portions. I had a spike that actually did that, that would have been 100% .NET standard compatible, but it was not suprisingly too slow for practical use.

I'm probably going to re-release just a sub-set of this library using visual studio linked assets and rely on the strong testing in this project to ensure the 'asset' is reliable and make that a .NET standard project.

Since the progress bar fits to the width of the window, it won't overlap, or cause the window to scroll.

Now that .NET Standard is out, this simplifies building PCL's and should be easier to release that in a few days, that should do the job.

:) cheers, A

Update: I've obviously not been watching this specific area closely, as it's quite possible that MoveBufferArea has simply been removed entirely? Which makes more sense, since the promise of compatibility is then actually true. In that case, switching to .NET standard breaks Konsole since Console in .NET standard has no MoveBufferArea method. Closing this as this can't be done with this project. I'll update this comment when the new .NET standard nuget package and project is available for just the ProgressBar.