I am usually working with WCF services that uses single instance context mode. Also service contract and behavior is in a WCF service Library.
If the service is hosted as a Windows Service or a Web service, they get their own projects that references the WCF service library. I like to keep this WCF service library running (for simply debugging with WCF Test Client) but it requires too much effort when I try to resolve dependencies through the behavior class.
Using Castle Windsor, I also have to make additional configuration for Castle Windsor WCF Integration Facility. I am just trying to resolve the object graph on service startup and I feel like it shouldn't be this hard.
I thought, since behavior instance is created only once I should be able to use it as the composition root. I can provide all dependencies using a single object and resolve it from the container like this:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
public class SampleService : ISampleService, IDisposable
{
private readonly IServiceManager _serviceManager;
private readonly IWindsorContainer _container;
public SampleService()
{
_container = new WindsorContainer();
_container.Install(new ServiceInstaller());
_serviceManager = _container.Resolve<IServiceManager>();
}
public string GetMessage()
{
return _serviceManager.GetMessage();
}
public void Dispose()
{
_container.Dispose();
}
}
I know it's a bad idea to explicitly ask the container to resolve a dependency but this saves me from so much trouble. I get to keep the default WCF configuration, I can run the WCF service library for debugging since I have a default constructor now. I also don't have to use Castle Windsor WCF integration Facility which was missing documentation last time I checked.
I guess Castle Windsor WCF integration Facility offers more features but I just want to resolve the dependencies. Is this approach likely to cause some problems? I haven't seen anyone do it like this so I would like to know if this would be legitimate use.
Related
I have a group of services that are written in WCF. This is a whole logic which cannot be changed and rewritten to another technology.
I want to create an application in .NET Core 2.1 and connect to WCF services. I am using library which has clients for all services with custom communication, bindings, endpointbehaviors etc. This library is written in .NET Framework v4.7.2, so if I want to use it in my .NET Core App I need to add target to the .net standard 2.0.
I did this and now I am having a problem as some classes are not supported in .netstandard2.0.
public class UserInfoBehavior : Attribute, IServiceBehavior, IEndpointBehavior
{}
For Example above class is used for adding EndpointBehaviors to my Channel:
public DashboardServiceClient(InstanceContext instanceContext, string endpointConfigurationName, string endpointAddress)
: base(instanceContext, endpointConfigurationName, endpointAddress)
{
base.ChannelFactory.Endpoint.EndpointBehaviors.Add(new UserInfoBehavior());
}
The problem is that IServiceBehavior is not available in .netstandard 2.0. Do you know some equivalent for this? There are more classes which I am using and are not supported:
RemoteEndpointMessageProperty,
Method Open() which is in ClientBase,
ChannelDispatcher,
and also EndpointDispatcher which is empty class in System.ServiceModel.Dispatcher
I am wondering if it is possible to target it to netstandard
You can call the wcf service by adding a connected reference.
Select the WCF Web Service Reference Provider.
Enter your WCF Service URI:
Check all quotes and finish.
You can see this folder in the client.
Just call it in the client, and you can acess the method in WCF Service.
static void Main(string[] args)
{
ServiceReference2.Service1Client service1Client = new ServiceReference2.Service1Client();
var t=service1Client.GetDataAsync(15);
Console.WriteLine(t.Result);
Console.ReadKey();
}
You can also refer to this link to call the wcf service:
Use the WCF Web Service Reference Provider Tool
I need to create a service class for my constructor in which I need to load a lot of configurations from my appsettings.json.
I want this service to be created as singleton and need to load configurations values in the service itself. So please anyone suggest me the best way to do so. I am creating asp.net core webapi and using its core DI built in container.
The configuration is already pre-registered by the host that is used with ASP.NET Core. So you can just register your service as you would any other singleton service, and have it depend on the configuration by requiring IConfiguration in the constructor:
public class MyService
{
private readonly IConfiguration _config;
public MyService(IConfiguration config)
{
_config = config;
}
}
You can then register this service as a singleton directly in your ConfigureService method:
services.AddSingleton<MyService>();
Things that now depend on your service, for example constructors, will automatically get a reference to that service instance. And since it is registered as singleton, it will only be created once by the DI container.
If you want a bit more control over your configuration, then I would suggest you to adapt the options pattern to make sure that you can work with strongly typed configuration and to avoid unrelated configuration value from spilling into services that shouldn’t not have access to them.
I have an IIS-hosted WCF application. Right now the service has this constructor:
public ClassService()
: this(new ClassRepository())
{
}
public ClassService(IClassRepository repository)
{
_Repository = repository;
}
The parameterless constructor is because WCF requires you to have a parameterless constructor when generating service proxies. Now, when I have the service proxy in the UI assembly, the constructor with the IClassRepository is not present so I can't inject an implementation of the repository.
How is this commonly done? One idea I have is that injection would take place not in the UI but in the Service but I am not sure if this would have some repercussions or just plain bad. Can someone give me some ideas?
What you need to do is implement a WCF InstanceProvider, delegating creation requests to your container of choice. Once you have your instance provider coded, you can install it in a ServiceHost by implementing a WCF service behavior. The service behavior, in turn, is installed by adding it to the collection ServiceHostBase.Description.Behaviors.
Here's an MSDN Magazine article on WCF extensibility.
I have a WCF service which implemented using Repository and UnitofWork patterns.
And now I am getting following error:
The service type provided could not be loaded as a service because it does not have a default (parameter-less) constructor. To fix the problem, add a default constructor to the type, or pass an instance of the type to the host.
When I worked WIHTOUT these patterns it did not throw any error.
HELP ?? SUGGESTIONS? How to get passed this error?
Following is the code snippet:
public class Service : IService
{
private IUnitOfWork _unitOfWork;
private IMyRepository _myRepository;
// Dependency Injection enabled constructors
public Service(IUnitOfWork uow, IMyRepository myRepository)
{
_unitOfWork = uow;
_myRepository = myRepository;
}
}
If you use default service instancing you must provide parameterless constructor. Your design provides dependency injection through constructor. In such case you must have your own instance provider to call the constructor and create service instance. You can create per service instance provider, behavior and optionally service host but it is really bad way. The better way is to use Inversion of Control container which will resolve your dependencies from configuration. In that case you will have only one new instance provider, behavior and optionally service host.
Here you have very nice post about creating new instnace provider which resolve services through Unity.
I am using wcf 4 and trying to use some Ioc container to resolve service dependencies. I was looking at Castle Windsor and StructureMap. I haven't use any of them with wcf.
The scenario is that I have IService1 and Iservice2. Service1 is using service2:
public class Service1 : IService1
{
public Service1(IService2 service2)
{
}
}
If I use WcfFacility from Castle with a transient lifecycle for service2 will it automatically dispose service2 after service1 is done with it(consider service1 a per-call instantiation for example)? And how exactly does that work internally.
How is this done with structuremap?
Some sample code would be really appreciated.
Yes, Windsor will do that for you out of the box. It's the default, you don't have to do anything. It tracks all disposable objects and their dependencies it creates and then disposes them as needed. Google "component burden" if you want the details.