make the library portable about microsoft.io.recyclablememorystream HOT 22 CLOSED

Went back to this today. .NET 3.5 is particularly unpleasant. Beyond missing EventSource it's also missing System.Collections.Concurrent entirely. Where I'm at right now:

• I can make a .NET 4.0 target (got this working)
• Without more pain I don't think I can make a .NET 3.5 target and I have to punt on that for now. Happy to take PRs, although I'd encourage Unity and its users to move forward off 3.5 because it is something like a decade old (and stuff like concurrent collections seems great for a gaming framework, IMO)
• Right now making .NET Core is similarly unpleasant because of the goofiness of xproj/project.json. As it happens I am working with our folks on the build team and I want to see if this gets better with VS '15' or not in terms of targeting .NET Core more easily (huge mess atm) before I move on.

As always will be happy to take PRs. For now I'm going to wrap up what I'm doing for .NET 4.0 and .NET 4.5 multi-targeting in NuGet and move from there.

I do apologize for the lengthy time this issue has lived, it hasn't been at the top of my stack and making this work in a non-hacky way is viscerally unpleasant.

from microsoft.io.recyclablememorystream.

adding related issue - dotnet/roslyn#1689

from microsoft.io.recyclablememorystream.

Seems reasonable.

from microsoft.io.recyclablememorystream.

+1 Would like to use this in PCL client lib.

from microsoft.io.recyclablememorystream.

Working on this.

from microsoft.io.recyclablememorystream.

Actually there is an issue here: no EventSource in PCLs right now. Since this is used a lot for tracing and diagnostics I don't think we can make this change at the present, at least without some kind of substantial updates to dig the events out and figure out how to keep them. I'll talk with Ben about this but for now I'm going to close this out. Sorry!

from microsoft.io.recyclablememorystream.

Should probably keep the issue open.

Personally, I'm going to fork this so I can use on PCL/dnxcore50 projects.
On 18 Jun 2015 04:19, "Chip Locke" [email protected] wrote:

Actually there is an issue here: no EventSource in PCLs right now. Since
this is used a lot for tracing and diagnostics I don't think we can make
this change at the present, at least without some kind of substantial
updates to dig the events out and figure out how to keep them. I'll talk
with Ben about this but for now I'm going to close this out. Sorry!

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

from microsoft.io.recyclablememorystream.

@doubleyewdee I think it not being PCL is a major adaption blocker since more and more stuff is now moving to CoreCLR, cross platforms, project k and etc. basically without the support, this lib is not usable for any modern .NET app. especially the reason it being closed is not due to main functionality but due to misc thing such as logging.

from microsoft.io.recyclablememorystream.

That's a good point. That said, at least for the way many teams inside have used this project, the logging is far from incidental. I will re-open this though and talk to ben about what we can do here. Since we expose events for all the relevant logged messages (I think) it may simply be a matter of writing a separate library to use those or migrating the code into the apps that need it.

from microsoft.io.recyclablememorystream.

+1
On 19 Jun 2015 01:33, "Chip Locke" [email protected] wrote:

That's a good point. That said, at least for the way many teams inside
have used this project, the logging is far from incidental. I will re-open
this though and talk to ben about what we can do here. Since we expose
events for all the relevant logged messages (I think) it may simply be a
matter of writing a separate library to use those or migrating the code
into the apps that need it.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

from microsoft.io.recyclablememorystream.

For folks looking for the PCL version can you let us know what your plans are? It'll help a lot terms of discussing funding and changes we can make in a shorter time frame. Obviously the opportunity to fork is there but we'd rather support you natively. Just need to understand what is being held up here. Thanks!

from microsoft.io.recyclablememorystream.

I linked it above. dotnet/roslyn#1689

...

Roslyn has its own version of pool.
http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces/Utilities/SerializableBytes.cs,e854af24fe209ffe,references

I would like to move to this, if possible. and this is needed at the bottom of Roslyn Layer which needs to be PCL (Profile7).

from microsoft.io.recyclablememorystream.

👍

from microsoft.io.recyclablememorystream.

We'd love to use this library in a Silverlight application so PCL support would be great. Our app is heavy on network access and the MemoryStreams that back a lot of that are starting to be a memory/performance bottleneck for us.

from microsoft.io.recyclablememorystream.

Sorry for the slow response here! Yes, I agree that migrating this library to PCL is desirable. It is important for us that we do not break compatibility with existing users who rely on the event data. I will look into ways to make a non-breaking change to the library if possible. If not I think we can do this in a 2.0 revision with a breaking change.

from microsoft.io.recyclablememorystream.

I think the best thing to do would be to move to a project.json-based model and switch to dotnet5.2 (soon to be netstandard1.1) instead of PCL. That would include net45 (the current target) and allow you to add System.Diagnostics.Tracing to use EventSource. It would also easily let you multi-target (and package for) .NET 4.0 and close #17. For more info, check out the platform standard document. If you need any help porting, let me know and I'll send a PR 😄

from microsoft.io.recyclablememorystream.

+1 Compatibility for Unity/3.5 would also be nice

from microsoft.io.recyclablememorystream.

I'm finally getting back to this now, and there is an interesting mix of requests. Some are angling for a big forward move (to .NET core) which I am partial to. Does Unity really still require 3.5? Can't it use anything newer? That seems weird.

I think multi-targeting could be done relatively cheaply but I'm generally disinclined to port backwards on (honestly) principle. Not totally opposed to it though...

from microsoft.io.recyclablememorystream.

On the backwards porting issue; I'd really appreciate a .Net 4 compatible version. I don't want to be on 4, but I have client apps distributed to multiple customers on different networks and client PC's. Some of them have upgraded to OS' that support versions of .Net later than 4, but some are still running XP/Server2k3 etc. and anything later is not an option for them. They should change eventually. We're telling them to update every time we talk... but some businesses move slow and we can't force the issue.
However, I haven't made an issue of it (was just watching #17) as I understand your reluctance.

from microsoft.io.recyclablememorystream.

Does Unity really still require 3.5? Can't it use anything newer? That seems weird.

@doubleyewdee Yes, 3.5. Thanks for considering it.

from microsoft.io.recyclablememorystream.

1. What is the current state?
2. Any love for UWP?

from microsoft.io.recyclablememorystream.

Closing in favor of #39 which will be resolved soon. Other targets TBA, but I'm pretty confident 3.5 isn't going to happen.

from microsoft.io.recyclablememorystream.