Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service not running after transistioning from alpha-1 to alpha-2 #1

Closed
johnkattenhorn opened this issue Apr 6, 2017 · 4 comments
Closed

Comments

@johnkattenhorn
Copy link

Briefly tried to migrate a project from alpha-1 to alpha-2 today and after fixing up the code the SF app would deploy but none of the Services would start.

They didn't appear to error, they just didn't get activated. I suspect it's my understanding of how the refactored package should work.

A sample of the usage would be great.

@alexmg
Copy link
Member

alexmg commented Apr 10, 2017

I removed the need to have two calls to register a service. The second call that was required to register the factory method with the SF runtime should no longer be required. To make this call you needed to have the constructed container in your hand. Basically the RegisterActorServiceFactory, RegisterStatefulServiceFactory and RegisterStatelessServiceFactory methods have been removed.

The dependency on Autofac was increased to 4.5 because I added a feature to the core library to make this possible. A build callback is added to the ContainerBuilder and that gets provided the constructed container when Build is called. So now when calling a method like RegisterStatelessService, the service is registered with the container, and a callback is added to the ContainerBuilder that will add the factory to the SF runtime.

Because you need to provide the service type name for stateless/stateful services I also removed support for adding all services from an assembly. This was only applicable to the first call of registering the service with the container. You still had to make a second call to provide the service type name when registering the factory.

These changes were made because I started writing a blog post about the integration, and when I got to the point of trying to explain why you needed two separate calls, I decided things needed to be simpler (or at least appear to be so from the outside). I have updated a local sample solution with these changes and they were working fine. I might try to get that solution up to the https://github.com/autofac/Examples repository.

@alexmg
Copy link
Member

alexmg commented Apr 11, 2017

I have created a Service Fabric demo application and pushed it to the Examples repository. It has its own solution file due to the Service Fabric dependencies that are required to build and run it successfully.

https://github.com/autofac/Examples/tree/master/src/ServiceFabricDemo

The solution was created with Visual Studio 2017 and version 2.5.216 of the Service Fabric SDK.

@johnkattenhorn
Copy link
Author

@alexmg - I've just taken a quick look at the example and it looked as I thought it would so there must have been something else wrong with our code base. I'll look into this later this week and upgrade to alpha-2 again.

Like you pointed out it's a little simpler than alpha-1.

One additional thing we've done which might help is we placed an action into the factory to allow us to log the entire stack when something wasn't registered correctly. The SF explorer helpfully cut's off the text from the exception and it's too hard digging through the EventSourcing :-)

@alexmg
Copy link
Member

alexmg commented Apr 12, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants