Yeah definitely if it’s as fast as ProtoBuf but doesn’t require attributes it would be more useful for POCO DTOs which is protobuf’s major shortcoming.
How is this progressing? I would love to incorporte this is our in-the-works project that uses a backend server and a frontend website. For obvious reasons I would like to keep the overhead of their communication to a minimum.
Just for info:
Tried Wire and MsgPack, but it seems my superduper DTOs are not being (de)serialized properly. This is on the 4.5.4 version. I will pull the source and see if this is at all possible. Keep you posted.
Hi Rob,
Do you have an example of a failing DTO?
I have an example for Wire failing. It’s a client + server with a models assembly.
The reason MsgPack was not working, was due to the fact that the response was sent as json. The reason for this is that the Feature.MsgPack was not included in the supported fetures in AppHost. I would opt for throwing an exception when this is the case (it took me 3 days to finally find this).
Also, there is no way to add Feature.Wire (it’s not in the enum)
Where can I put the sample for you to check out? (I believe the error is Wire related, not ServiceStack) Send me an e-mail (see profile) and I will send you a zip.
What serialization capabilities each format supports is typically opaque to ServiceStack where we’re very limited in what we are able to do (i.e. where it’s possible we could change their default configuration), otherwise any changes/issues would need to be submitted to the Wire project.
So I’d see if the serialization/deserialization works with just the Wire serializer, if it is submit an issue with the Wire project. The easiest way to share any code is to just put it on Github.
Here you go:
This solution has 3 projects. The client will call the server for JSON, MsgPack and Wire. The last one fails.
Hi Rob, not at the moment, only had a chance to look at it briefly last night and so far it looks like the request and the response can be serialized and deserialized ok and the null exception is being thrown when the line https://github.com/ServiceStack/ServiceStack/blob/b748d262cd4d5caa67d0738b119a6fb468cf0336/src/ServiceStack.Wire/WireServiceClient.cs#L36 is passed a System.Net.ConnectStream back from the server.
Not sure why this is yet, so will have another look tonight.
@mythz I couldn’t get the symbols from the symbolsources specified in the debugging docs and had to just clone the assets repo and unpack the nuget packages, are the symbols being uploaded ok during release?
@Mac SymbolSource is dead and always fails when trying to publish the symbols. I’ve mentioned a couple of alternatives in this previous answer.
As it’s easier for me to debug this since I’ve got local clones of all the repos, I’ve just looked into this and it’s due to the static serializer was null which is now resolved in this commit.
This change is available from v4.5.5 that’s now available on MyGet.
2 Likes
our package symbols are being published to the nuget symbol server, could this be an alternative?
Here’s an example: https://ci.appveyor.com/project/MacLeanElectrical/servicestack-seq-requestlogsfeature/deployment/465322
Cheers for the fix @mythz 
That link didn’t work for me, just kept “loading” forever. But I don’t really want to add a 3rd CI into the mix as we’re already using TeamCity and Travis CI. We’re also publishing the symbols for each release to:
I’ve updated the Debugging docs to mention this + other debug solutions: Debugging | Documentation
ok, must be only for logged in account, point is that it’s not about appveyor or any specific CI. Below is the console output from publishing that the link showed:
Downloading artifact ServiceStack.Seq.RequestLogsFeature.4.0.66.0.nupkg to temporary location...OK
Publishing ServiceStack.Seq.RequestLogsFeature.4.0.66.0.nupkg to https://www.nuget.org/api/v2/package...OK
Downloading artifact ServiceStack.Seq.RequestLogsFeature.4.0.66.0.symbols.nupkg to temporary location...OK
Publishing ServiceStack.Seq.RequestLogsFeature.4.0.66.0.symbols.nupkg to https://nuget.smbsrc.net/api/v2/package...OK
Total packages published: 2
I’m using TeamCity’s built-in NuGet Publish task to publish symbols and just tried deploying again and I’m getting the following error:
[23:23:48]E: Step 1/2: NuGet Publish Symbols (NuGet Publish) (3s)
[23:23:48]W: [Step 1/2] Attempt to publish NuGet package with wrong extension: .nupkg, expected: .nupkg
[23:23:48]W: [Step 1/2] push: Publish package symbols\ServiceStack.4.5.5.symbols.nupkg (3s)
[23:23:48] : [push] NuGet command: C:\TeamCity\buildAgent\tools\NuGet.CommandLine.3.4.4\tools\NuGet.exe push C:\TeamCity\buildAgent\work\57e017c5f7c7861b\symbols\ServiceStack.4.5.5.symbols.nupkg %%teamcity_nuget_api_key_1478647428987%% -Source https://nuget.smbsrc.net/
[23:23:49] : [push] Starting: C:\TeamCity\buildAgent\temp\agentTmp\custom_script5805683182620294916.cmd
[23:23:49] : [push] in directory: C:\TeamCity\buildAgent\work\57e017c5f7c7861b\symbols
[23:23:49] : [push] Pushing ServiceStack.4.5.5.symbols.nupkg to the symbol server (https://nuget.smbsrc.net/)...
[23:23:49] : [push] PUT https://nuget.smbsrc.net/api/v2/package/
[23:23:52] : [push] Forbidden https://nuget.smbsrc.net/api/v2/package/ 2891ms
[23:23:52] : [push] Please provide credentials for: https://nuget.smbsrc.net/
[23:23:52]W: [push] Object reference not set to an instance of an object.
[23:23:52] : [push] UserName: Password:
[23:23:52]W: [push] Process exited with code 1
[23:23:52]E: [Step 1/2] Step NuGet Publish Symbols (NuGet Publish) failed
Do you know if we can use the same API Key to publish symbols that we use to publish NuGet packages on NuGet?
yeah, it’s the same apikey, we’re just using the default appveyor nuget deployment so its not clear what is happening under the covers when it deploys beyond the console output
So it looks like the apikey isn’t passed by nuget to the symbol server properly when automatically publishing the symbols and it’s an open bug
Manually pushing the symbols as a separate task would likely work though.
Any chance to see this added to the .Net Core version as well?
No the .Core packages are only temporary, they’ll be merged back into the main NuGet packages after a couple of releases.
OK. We’ll stick with MsgPack for the time being. Works like a charm on .Net Core.
We’ll keep an eye on the main packages.