Is it possible to force WcfSvcHost (which is executed automatically when I do an F5 or when I am debugging another project in the solution) to use a custom ustom service?
I have my custom service host working great in my asp.net Host container by using a service factory which in turn calls the Custom Service Base.
But when WcfSvcHost executes it's not using my custom ustom service.
Is this possible?
If not, what are my alternatives? I presume I must uncheck "Start WCF service host when debugging a project in another solution" which is in the WCF Options in app properties but then I must create a console Host container?
And I can't get the console host container to automatically execute each time I am debugging something else?
I notice this under DEBUG in app properties (maybe I can use something like this to force the loading of the custom servicehost)
/client:"WcfTestClient.exe"
The problem being is that I have my custom ServiceHost inject some UNITY (IOC) stuff, here the overriden method ... so it must execute otherwise it fails.
protected override void InitializeRuntime()
{
Bootstrapper.ConfigureUnityContainer();
base.InitializeRuntime();
}
I was trying exactly the same thing for exactly the same purpose (;-)
I thought I found a solution by not using physical .svc files anymore (which contain the custom host factory when hosting in IIS), but moving this info to the .config file instead:
<serviceHostingEnvironment aspNetCompatibilityEnabled="false">
<serviceActivations>
<add relativeAddress="~/Services/NaisTime/NaisTimeService.svc" service="Nais.Time.Services.NaisTime.NaisTimeService"
factory="Nais.Time.Services.NaisServiceHost.NaisServiceHostFactory, Nais.Time.Services" />
<add relativeAddress="~/Services/Northwind/NorthwindService.svc" service="Nais.Time.Services.Northwind.NorthwindService"
factory="Nais.Time.Services.NaisServiceHost.NaisServiceHostFactory, Nais.Time.Services" />
</serviceActivations>
</serviceHostingEnvironment>
It works for IIS, but putting the same entries in the app.config file of my Service Library project does not make SvcWcfHost use this.
I guess I am not getting my relativeAddress right.
Anybody any experience with this?
kr,
Michel Liesmons.
I don't think you can do that - you'll need to host in IIS or create your own, customized service host.
Related
first of all this is not duplicate. I have a little bit different question.
Is it good practice to get rid of WCF's config in App.config file in the client (or clients in case of cross-platform project) and replace it with injected Proxy class (from different dll, shared for all clients)?
I'm just starting so my config file is not big, but here is an example:
App.config (WCF part):
<system.serviceModel>
<client>
<endpoint address="net.tcp://localhost:8002/MyService"
binding="netTcpBinding"
contract="CallbackExample.Client.IMyService" />
</client>
</system.serviceModel>
I must have this code copy and pasted into every client I made. Working with Xamarin I can have many clients written in C# in single VS solution. So I though, why not just get rid of system.serviceModel section and do that:
MyServiceProxy.cs:
public class MyServiceProxy : ClientBase<IMyService>, IMyService
{
public MyServiceProxy()
: base(new NetTcpBinding(), new EndpointAddress("net.tcp://localhost:8002/MyService"))
{
}
public int JustAMethod()
{
return Channel.JustAMethod();
}
}
This way, I will have my configuration in single place.
So, my question is: Is it considered as a good practice? Is there a better way? I'm not sure, cause WCF is all about flexibility and easy config through App.config flie.
If there is no need for additional configuration, I always go for pure code solutions.
Back in the day WCF was slightly more complex to configure, via app.conf. With the ServiceHost you can even configure a WCF service in pure code.
The same applies to a WCF client imo; if you don't have the need to configure it via a config file for your users: I'd say go for the pure code solution.
Here another discussion of the same topic. (kind of the same reasoning, the question remains; do you need the configuration flexibility).
One potential downside to doing everything in code is that you lose the flexibility to configure not just the endpoint, but also the binding, without recompiling and redeploying. The binding includes some important network-related attributes (timeouts, transport protection levels, authorization schemes, etc) that you may want to tweak depending on the environment in which some of your client programs can run.
Note that you don't necessarily have to have a separate *.exe.config file for every client application. You can have a common .config file that each application can load explicitly. See ConfigurationManager.OpenMappedExeConfiguration
I'm trying to make the same project to work with WCF and MVC.
My problem is:
MVC is working perfectly, than I included the interface and the .svc that I had in WCF service.
When I try something like this:
http://localhost:2986/PAGENAME.svc
I get the following error:
The resource cannot be found.
NOTE: PAGENAME.svc is in root (and so as the interface).
Looking forward this problem, I included the ignore methods in RegisterRoutes:
routes.IgnoreRoute("{resource}.svc/{*pathInfo}");
routes.IgnoreRoute("{resource}.svc");
But didn't work either =/
Does anyone know how to fix this?
Thank you!
You need to make sure that you have all the files required, which are referenced from the Service Host (.svc file), i.e.:
<#% ServiceHost Service="..."/>
Where Service specifies the service implementation.
The service contract (the interface that the service implementation implements) is usually configured in web.config.
You don't need to ignore the route if the service host file is at the root of your solution.
You need to reference System.ServiceModel.
If you want to test your service you can by opening visual studio command prompt and running wcftestclient, File -> Add service and add the url for your service, e.g.:
http://locahost:12423/MyService.svc
It's been a while since I've played with this, but I think when using MVC you need to register a service route... but I don't remember if that's what I had to do or if I just wanted to do that for cleaner routes.
To add a service using a service route, you would do something like the following
routes.Add("MyService", new ServiceRoute(
"some/path",
new ServiceHostFactory(),
typeof(MyService)
));
I'm trying out WCF for the first time and getting the following error when I try to instantiate the host:
This collection already contains an address with scheme http...
I have found a lot of other references to this and tried some of the solution to no avail. One fairly common thread that does not apply to me is that the problem is on a web server of some sort. I'm just running everything from my local machine.
One interesting symptom I found is that I'm developing a c# Forms app. Originally my top level form object inherited my service interface instead of a separate Service class. When I implement this way, there is no error on the host side but I have been having trouble on the client side.
Based on this solution:
How to solve "The ChannelDispatcher is unable to open its IChannelListener" error?
...I decided to separate the service host into a separate object. That's when I start seeing the problem.
The ServiceContract is simple enough:
[ServiceContract]
public interface ISSAService
{
[OperationContract]
void CreateSpaMonitor();
}
I instantiate the service like this:
Uri baseAddr = new Uri("http://localhost:8000/SSAService");
ServiceHost localHost = new ServiceHost(typeof(SSAService), baseAddr);
Where SSAService is the implementation of the Service interface.
If I change the second line to the following (and implement the interface...) the error goes away:
Uri baseAddr = new Uri("http://localhost:8000/SSAService");
ServiceHost localHost = new ServiceHost(typeof(SSAManager), baseAddr);
Where SSAManager is my top level Forms class...
Then I run into a client side problem which is where I started....
I have tried changing the port number and that doesn't seem to affect anything.
I'm new to WCF so maybe I'm missing something obvious.
Thanks.
I was getting this error:
This collection already contains an address with scheme https. There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' to true or specifying 'system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters'.
Parameter name: item
I resolved it by doing the following to my web.config. Perhaps something changed in the .NET Framework 4 which is requiring this line, since I didn't need it before:
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
<!-- Rest of the system.serviceModel content omitted for brevity--->
<system.serviceModel>
This can also occur if you have multiple bindings on the same IIS site with different domain names/ports. I resolved the issue by removing the extra named binding.
One of the solution I found previously was to add something like this:
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://localhost:8000"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
And then specifying the endpoint address absolutely. This didn't seem to have an effect but I was still using baseAddr in the constructor as shown above.
The solution for me was to remove baseAddr from the constructor.
This seems like it should be really simple, but I'm unable to figure this out.
I am adding a web service reference to my console application. The web service points against our production environment and I would like to test it against development. In VS2005 it was really easy to override the target URI of the service. Is it possible to do the same with VS2008? I would like to set the URI in code or via a config file.
I would really appreciate help with this. Thanks!
If you look in your .config, you should see <endpoint> elements that were added to the <client> section of <system.serviceModel>. Assuming you need to point at only one environment at a time you can simply edit the address attribute of those endpoints to point to whatever URL you want.
If you wanted to change this at runtime you need to use the constructor overload for the client proxy that was created. There should be several overloads that take a parameter called remoteAddress in many forms.
It seems that I was able to get around this issue by going to "Add Service Reference" -> "Advanced" -> "Add Web Reference". This gives me a reference in the form I am most familiar with. Now I was able to override the constructor with the URI parameter. Is that method frowned upon?
it looks like I am not able to succesfully move my WCF proxy code into a separate DLL (as opposed to an EXE as I can see in all the examples I have run into).
The reason I am trying to do this is that I would like my proxy code to be invoked by different clients (possibly unmanaged code), which might not know anything about WCF but just need to access to the services (through a Facade exposed by the proxy maybe?).
Whenever I move the following code that creates a new proxy to a different VS project within the same solution, I get the dreaded "Could not find default endpoint element that references contract 'localhost.IRemoteCommandService' in the ServiceModel client configuration section" exception.
localhost.RemoteCommandServiceClient proxy =
new localhost.RemoteCommandServiceClient();
The same code works smoothly whenever used within a Main method in the same project where the proxy code is (auto-generated from Visual Studio).
Any idea? I hope that the client code of my proxy does not need to have the service model XML configuration as the proxy, because that would defeat the purpose I am moving the WCF proxy code into a DLL in the first place.
Thanks,
Stefano
The endpoints are indeed normally specified in the configuration file. You must look at the serviceModel data in the config file, and copy it into your calling app.config - or you need to use the more verbose way of creating the proxies in your code (i.e. specifying the address, binding, configuration etc through code to the constructors).
If you don't want to have to endpoint configuration on the client, you'll have to embed it into your proxy dll by specifying everything in code.
Another option would be to use a dynamic proxy, like this one, which would allow you to not have the serviceModel in your client apps.