Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andrew Arnott
    @AArnott
    @amachanic Is the problem unique to your use of MessagePackStreamReader? Does it work properly if you read the entire stream first and then deserialize with the same Typeless resolver?
    Andrew Arnott
    @AArnott
    @kstreichergb Why not use NativeDateTimeResolver? It doesn't lose the type (or Kind) information, does it?
    rous100
    @rous100
    Hi, in OSX I cannot get the CodeGenerator to run from Unity - I get the ".Net Core SDK not found" error even though I did install it. I set a break point when it is testing for it by executing "dotnet --version" and the error that is returned is "Cannot find the specified file". I noticed the PATH environment variable did not include the location of the dotnet executable so I manually edited to add /usr/local/share/dotnet, but I still get the same error.
    Andrew Arnott
    @AArnott
    @rous100 If dotnet --version isn't working for you, please take this up on a .NET Core SDK forum as you have more general problems than messagepack.
    rous100
    @rous100
    it doesn't work when run from the Unity menu.. I can manually run "dotnet mpc" from the command line which I guess is fine
    this is a necessary step unless I'm using the Typeless formatter right?
    kstreichergb
    @kstreichergb
    @AArnott it does keep the type if you deserialize into DateTime, it does deserialize as Int64 if it is a object (e.g. Dictionary<string,object>)
    kstreichergb
    @kstreichergb
    I am running into the same problem with Dictionary<string,object> dict; and other types, e.g. Decimal. I would expect that the ContractlessStandardResolver.Instance does pack the type information and I receive a decimal if i deserialize dict["key"] = 14m; but I do receive a string.
    kstreichergb
    @kstreichergb
    image.png
    resolver = CompositeResolver.Create(
                                                    NativeGuidResolver.Instance,
                                                    NativeDecimalResolver.Instance,
                                                    DynamicObjectResolver.Instance,
                                                    ContractlessStandardResolver.Instance,
                                                    StandardResolver.Instance
                                                   );
    kstreichergb
    @kstreichergb
    ... ah this is still won't fix neuecc/MessagePack-CSharp#651 but - sorry I thought it was a "won't" fix in v1
    rous100
    @rous100
    Since the Typeless formatter doesn't work in newer versions of Unity does that mean we need to use annotations on all classes that will be serialized?
    Andrew Arnott
    @AArnott
    @kstreichergb The Typeless resolver is the only one that can figure out how you want an object to be deserialized, I believe.
    hiradyazdan
    @hiradyazdan
    @AArnott I am upgrading from 1.7 to latest of messagepack, there seems to be a lot of breaking changes, is there any list that I can see what changed and how to work that through?
    hiradyazdan
    @hiradyazdan
    thanks @LiorBanai that’s it :)
    do you also happen to know whether the new docs has the latest benchmark against version 2 on it or not?
    Andrew Arnott
    @AArnott
    yes, the README.md in the repo matches the perf of the branch you find it in. So the master branch's readme describes 2.x perf and the v1.x branch's readme matches the v1.9 perf.
    hiradyazdan
    @hiradyazdan
    awesome! thanks @AArnott
    hiradyazdan
    @hiradyazdan
    @AArnott I have tried mpc 2.1.90 with .net core 2.2 and it generated fine, but in the docs it says: First of all, mpc requires .NET Core 3 Runtime., is there smth i’m missing?
    hiradyazdan
    @hiradyazdan
    the only issue is that it doesn’t run under mono anymore, but it used to with 1.7 at least
    Andrew Arnott
    @AArnott
    @hiradyazdan MPC runs on .NET Core 3, but it can generate code that runs on .NET Core 2.x, that's not a problem. Does that clear it up?
    hiradyazdan
    @hiradyazdan
    @AArnott with .net 2.x it generates a correct file, but with mono it fails with File does not contain a valid CIL image.
    Andrew Arnott
    @AArnott
    I don't think we support mono. Can you just run mpc with the dotnet CLI?
    hiradyazdan
    @hiradyazdan
    @AArnott the thing is, i’m using a run configuration on Rider and for some reason no matter what I do, it prepends mono to any .net executable command by default, i’d rarther use mpc in the editor, than on a separate console
    hiradyazdan
    @hiradyazdan
    this issue was happenning before if I was using the mpc file without the .dll extension, the latest mpc doesn’t come with dll, so I have no choice to use it with mono, or let the rider detect that it’s to be run/built against dotnet and not mono (as it auto detects based on the file type)
    Andrew Arnott
    @AArnott
    Can you prefix the config in Rider with dotnet, so that the whole command line is dotnet path\to\mpc? The dotnet executable is definitely not a .NET executable itself so Rider shouldn't prefix mono to it.
    Another option might be to prefix with cmd or bash or whatever so you can control the whole thing, as these are not .NET executables either.
    hiradyazdan
    @hiradyazdan
    @AArnott I can’t prefix it with anything as the config asks for certain fields only to construct the command. Rider uses mono by default as the main cmd tool if the file is either .exe or doesn’t have any extension, unless it comes with .dll which then it uses dotnet instead
    why can’t we just have the mpc.dll any more?
    Andrew Arnott
    @AArnott
    No reason why you can't. We just didn't anticipate Rider's limited support for .exe's that aren't mono-compatible and wanted to make the tool that much easier to use for everyone else. I hope you send Rider some feedback.
    You can file an issue on our site to track shipping a .dll
    But surely you can pass parameters into the tool from a Rider config, can't you?
    If so, can't you point Rider at a native .exe with args?
    hiradyazdan
    @hiradyazdan
    I have spoken to Rider guys, so far they suggested to use the Native Executable template than .Net Executable, though it doesn’t justfiy the fact that Rider defaults to mono for any .net executable instead letting the user to choose between dotnet and mono. But there’s caveat of how to use it which gives the same result using a normal console as well, tha path arguments for input project file (.csproj) and the output file (generated file) need to be absolute path and not relative even if running under the working directory, otherwise it internally fails with System.ArgumentException: The path is empty. (Parameter ‘path’)! This issue could also be related to neuecc/MessagePack-CSharp#355 as well
    hiradyazdan
    @hiradyazdan
    btw, I love the new api, everything can be managed in their own place and centralized properly.
    aperel66
    @aperel66
    Hi all. I have been using MP in it's native for for many years and love it! First time I needed to do something special would like your advise. We have our own set of attributes that we use on objects that we mark for various purposes. One of them is whether member needs to be serialize. Without adding extra MP attributes such as [Key] or [IgnoreMember] how would I approach this problem? I also do not want to create a proxy class to add attributes on the fly dynamically.
    Andrew Arnott
    @AArnott
    The messagepack resolver that looks for attributes directly turns them to a dynamic formatter. There is no mechanism in place to get it to read other attributes or allow you to direct it yourself after reading your own attributes. I'd love to see this enhanced in the future, but that's where things are now.
    Andrew Arnott
    @AArnott
    @neuecc what do you think of me adding a GitHub Action (bot) that tags stale issues and PRs and then closes them if no activity happens? There would be an 'exempt' label you could apply on long-term issues, and we could negotiate the 'stale' timeframe. I'm thinking 90 days is stale, +5 days to close.
    Yoshifumi Kawai
    @neuecc
    @AArnott I can't imagine what kind of results it will have, but I think it's good to try.
    Andrew Arnott
    @AArnott
    Alright neuecc/MessagePack-CSharp@38f095b. It will activate at 0:00 UTC
    Andrew Arnott
    @AArnott
    First run is complete. It only tagged 15 issues since it has a 30 operation limit by default. So each day it will get some of the job done. We could lift the limit, but since this is brand new, maybe doing a small batch each day is a good idea so we can keep tabs on how it goes.
    aperel66
    @aperel66
    Thank you Andrew. But is there a way I can turn my attributes into a dynamic resolver at runtime?
    provanguard
    @provanguard
    Is there some way to use NSwag / NSwagStudio to generate client code in C# that supports MessagePack-CSharp serialization between the client and the server?
    Andrew Arnott
    @AArnott
    @aperel66 Sure, you could do it the same way we do based on the two attribute sets that have built-in support. It's non-trivial to be sure.
    @provanguard If NSwag can produce [DataContract] conforming classes to represent the data to be serialized, then yes it should work fine.
    aperel66
    @aperel66
    @AArnott Andrew. I wave looked for docs on how to write custom Formatter resolver and seemed to be missing something. Can you please point me in the right direction as to how to write a custom forrmatter resolver? While I have used MP a lot, I am not familiar with its internals. Just need an example please.
    @AArnott I have*
    Andrew Arnott
    @AArnott
    @aperel66 It's in the README file at the root of the repo.
    provanguard
    @provanguard
    @AArnott After initial investigation, it seem that NSwag / NSwagStudio focuses (solely?) on JSON serialization. It is a mystery to me why binary serialization is not a option. I am investigating this to find a fast and reliable inter-service communication. The goal is to have fast response from chained services and binary serialization looks very promising. In that context, generation of client code would be very handy.