I have found couple of references to the "TryAddStateSerializer" method but it appears to be deprecated, and the examples provided don't seem to work anyway including this one GitHub Azure content.
How an I supposed to register my Custom serializer?
TryAddStateSerializer is currently the only way to do it. The API may change in the future but it is safe to use today.
Related
I don't see any documented plugin framework for extending the functionality of the Service Fabric Explorer. Is there perhaps an undocumented one (or some samples), which I can use to add custom actions / information to my services?
SFX does not contain a feature like this, but the source is available online on github though, you could either:
Request as a feature and wait to be accepted and implemented by someone
Fork the code and implement yourself, and maybe submit back to upstream repository.
After updating to .net core 2.2 we have the following issue:
Autofac.Core.Registration.ComponentNotRegisteredException: 'The
requested service 'Microsoft.AspNetCore.Hosting.Server.IServer' has
not been registered. To avoid this exception, either register a
component to provide the service, check for service registration using
IsRegistered(), or use the ResolveOptional() method to resolve an
optional dependency.'
We are using preBuilder.Populate(services);.
Any ideas?
Thanks for your help
I had the same problem when following Microsoft migration guide for migrating from Core 2.1 to 2.2.
The problem might occur if you are not using WebHost.CreateDefaultBuilder to create the default web host builder, and you change in the CreateWebHostBuilder method of the Program class to call ConfigureKestrel instead of UseKestrel, as suggested in the migration guide.
As far as I understand if you use WebHost.CreateDefaultBuilder to create the default web host builder, it already calls UseKestrel which registers the IServer service. But you might get into some conflicts if also using UseIIS, so to avoid this problems there is a new ConfigureKestrel call that does not register the IServer. So I think that if you are not using WebHost.CreateDefaultBuilder then you still need to call UseKestrel or UseIIS explicitly.
Of course it might be something else that is causing the problems in your case, but I suspect that following the migration guide blindly (as I did) could cause problems for many developers out there.
I am working with UberDost, but the application lacks functionalities, for this reason I want to implement my own solution.
Thanks!
Today, we do not provide UberDost functionality via the API. We will add it to the features request backlog and follow up on this thread if it ever changes.
Using the latest Service Fabric SDK, we would like to replace the restrictive DataContractSerializer with a custom IStateSerializer that uses JSON serialization. We have found the IReliableStateManager.TryAddStateSerializer method, however it is marked as obsolete.
How else can we register a custom IStateSerializer?
There's no alternative way. Using it in this way is supported, but the way it works will change somewhere in the future. You should make the call based on whether you're prepared to deal with that uncertainty.
In Sails.js you can easily create an api and this will provide you with action, rest and a shortcut api. This is wery clear from a lot of sources on the internet. This is also very practical when setting up a new app.
One thing that don't seems very clear is what to do when deploying the application to production. I can't think of anyone who would like /user to be open for anyone to see...
I don't really know how to handle this, there is many routes that one might not want to be open in production. I can think of the following ways to solve it:
close rest, actions and shortcuts in blueprints.js (which will remove all automatic apis), and then define them myself in routes.js.
Add policies for every route that I want no one to see (I don't even know all the routes that is automatically created so this seems risky).
Override all controller actions that should not be visible.
What is the right way to handle the routes that I don't want to have, when they are automatically created?
I don't like only your 3-rd method. I can suggest few methods:
Disable rest for all models in global blueprints configuration (config/blueprints.js) and enable it in needful models. Look overriding blueprints.
Yes, you can add policies to some blueprints. You can find list of all default blueprints ("routes that is automatically created") in blueprint-api reference.
Hope it helps you. Sorry for my english :)