I have standard class library infrastructure assembly which i reference in my main application.
The infrastructure assembly uses a webservice internally and exposes functionality to my main application.
To get it to work i need to add a reference in my main app to the webservice otherwise i get a Endpointexeption. If i add it everything works fine. It seems to me that the infrastructure dll reads information in the main applications app.config so the entry has to be there. But it seems strange that i cant expose the web service throug an external dll as the main application does not call the webservie directly. Whats even stranger is that the webservice ignores the main applications security mode and reads it from the external dll's app.config.
If im correct in my assumptions, how do i expose a webservice in an external dll withot the main app knowing about the webservice.
in your class library project when you add the service reference you have to make sure the generated proxy is Internal.
for more info:
C#, WCF, Hide web service through dll
This will hide the WCF interface to the client.
if you don't want that the client that uses your class library project needs to add the WCF configuration key in its app/web.config your library has to configure the EndPoint/address/binding in the code (hard coded) but I won't recommend you to go down this road as if something changes on the WCF side your class library won't work anymore
You don't need to add the service reference to your main app, but you must copy the relevant configurations to the main app.config
Related
I have created a class library - MyNS.MyClass. The Library has a Service Reference to a Webservice (added through Add Service Reference) - the Service Reference shows up as MyNS.VS in the Project. The class library is MyNS.dll. MyClass has a static method myStaticFunc which calls the Web Service
I have a separate C# console application where I add reference to this DLL. I have code there calling MyNS.MyClass.myStaticFunc. My project compiles fine. But when I run it, I get an exception
{"Could not find default endpoint element that references contract
'VS.MyObj' in the ServiceModel client configuration section. This
might be because no configuration file was found for your application,
or because no endpoint element matching this contract could be found
in the client element."}
To get rid of this exception, I have to also add a Service Reference in my Console Application & give it the same name (VS - however, here the namespace would obviously be my client app's namespace).
I don't understand why this needs to be done - it's the Library which is calling the WebService - the app is not calling it directly - and the Library does have the Service Reference. And why does the workaround work - in spite of the namespaces being different?
I have a question about references to WCF Services. I have two apps:
Console app
--Library
----WCF Service
The console app and library are in the same solution. Because of the WCF service in the library, its app.config has info for the WCF Service.
The console app config has nothing about the WCF Service. The console app calls the WCF Service indirectly through the library. I'm guessing that is why the console app has no WCF info in its config (since it knows nothing about the web service). The console app does a call to a static method in the library, which handles the WCF call.
I'm getting this error on the above call:
Could not find default endpoint element that references contract 'MyServiceReference.IMyService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element
Does the host (console app) need the WCF Service related info from the library? If so, why didn't VS2010 add it.
The library you created ("--Library", in your hierarchy) likely added a service reference to your WCF service. ("in the library" makes no sense, so I'm assuming that's what you meant). This means that a bunch of information about the WCF service was added to the app.config for the library. That information needs to be in the app.config of any exe that references the library in order for the library to correctly access the WCF Service that it references.
What I'd suggest is running the SVCUtil.exe. You can run it against the running service like this:
svcutil.exe http://localhost:Port/YourSvcClass/YourSvcMethod /language:c#
What that will do is build a client-side c# (or vb) stub class in c#, plus a .Config file with the exact client side configuration file you'd need to connect ... all the good stuff. You can also run svcutil against your WCF dll like this:
svcutil.exe c:\yourfolder\YourService.dll /language:c#
Whether you use the stub class or not, the .config file will be helpful in setting up the client.
Good luck
I am building a C# UI to interact with a COM Service (.exe). The VS2005 COM project outputs a valid typelib (TLB), which is referenced by the C# project. However, the VS2005 C# project insists that the service be registered in order to build the C# project, even though the typelib appears perfectly valid when examined with the OLE Object Viewer.
We would rather not register the service on the build server, if possible. Further, debug builds cannot register the COM object as a service, since this makes debugging in general, and startup code in particular, more difficult (can't use F5 - Start Debugging).
What should I look for in order to get this working? Do I need to register just the TypeLib? If so, why would COMInterop insist on having the service or TLB registered in order to build correctly (and, is there a command-line tool for this on Win2003 with VS2005)?
If I recall correctly, once apon a time I built a C# web service which referenced the Win2003 firewall COM object, but we built it on Win2000 (which does not have such a thing) simply by referencing the TLB file with no registration required, so I don't understand why this should be a problem now.
You need to create interop assembly using tlbimp.exe tool. And add reference to this assembly in your project instead of typelib. In this case building will not require registered com server.
If you do not want to ship yet another assembly, you can extract interface description from generated interop assembly using Reflector and include them into project as source files.
Solved this by adding a -regtypelib command to the COM service, which calls the AtlRegisterTypeLib function but does not register the service. Suboptimal because it will leave registery entries on the build server, but quick and it works.
I have a 3 projects in a solution like such:
WCF Service: Hosts a couple of methods
Class Library: Acts as a gateway to the WCF service by returning an instance of its Soap client
WPF Application: Consumes the service methods via the referenced class library
Everything was working perfectly...the application was accessing an instance of the soap client through the library and consuming the methods accordingly.
Now I signed my assemblies and everything still compiles and when I add new methods and update the service reference in the library, the new methods come up in the application...but when running the application and try to use a method, a MissingMethodException is thrown:
Method not found:
'MusicData.Entities.User
DBAccess_Gateway.DBInteraction_Service.DBInteractionGatewayClient.User_Login(System.String,
System.String)'.
This is the line its failing at:
var user = WSGateway.MR_WebService.User_Login(username.Text, crypto.Encrypt(passphrase.Password));
I think it has something to do with the assemblies (now in the gac because they are signed?) being signed...but why arent the methods are not being found? Are the signed assemblies not being updated correctly now?
When you update the service references in your class library, make sure you are creating a new version of the assembly and registering this new version in the GAC, then make sure your WPF app is referencing this new version.
I have a C# class library and a startup project (a console app). The class library includes a service reference to a web service. When I try to run the project, I get an InvalidOperationException because the startup project isn't reading the class library's app.config, and it's ignoring the service reference. To get it working, I'm forced to add the same service reference to the startup project. Is there any way I can avoid this? Can I make the startup project recognize the class library's service reference and app.config without having to copy it to the startup project?
I've tried adding a link to the app.config from the class library, but that doesn't work. The class library isn't very portable if it requires anyone who uses it to add that service reference to the startup project.
Think about what you are trying to do - you have two assemblies that you are building:
Library
ConsoleApp
Both of these assemblies have configuration files - I would imagine they look something like this:
Library
app.config
ConsoleApp
ConsoleApp.exe.config
When you run ConsoleApp it has no way of reading from or knowing aboout app.config from your Library assembly. The only configuration file that it knows or cares about is ConsoleApp.exe.config. Now it is possible to have configuration files reference each other but this is not the proper solution for what you are trying to do.
Since your Library assembly has no entry point, it will never be loaded into an AppDomain. Since it will never be loaded into an AppDomain its application configuration file will never be used.
What you ought to do is reference Library in ConsoleApp via a project reference. Then move all the relevant configuration data from app.config into ConsoleApp.exe.config as this is the configuration file that will be used by your application.
This will allow you to have to two things you need to invoke methods on your web service
The code in Library that can send and receive SOAP messages.
The configuration metadata that is required by Library to function.
An alternative to using a service reference in the class library and then copying the config would be to use build events that call svcutil.exe. The thing I like about this is that you don't have to make "update service reference" when the service changes. It will be updated automatically.
In the class library, use a build event that only generates the proxy code:
svcutil.exe net.tcp://localhost:3315/MyService/mex /noConfig
In the application, use a build event that generates the config. You can use the /mergeConfig option to merge it into an existing app.config.
svcutil.exe net.tcp://localhost:3315/MyService/mex
/config:App.config /mergeConfig
If you don't want to get a build error if the service is not running, put this in your project file and you will get a warning instead of an error:
<Target
Name="PreBuildEvent"
Condition="'$(PreBuildEvent)'!=''"
DependsOnTargets="$(PreBuildEventDependsOn)">
<Exec WorkingDirectory="$(OutDir)"
Command="$(PreBuildEvent)"
ContinueOnError="true" />
</Target>
You just need to copy the config key, pointing to the service, from your class library config file to your console app's config file.
You can copy the relevant portions of the app.config from the class library's configuration into the app.config for the console application.
Alternatively, if you're really trying to make this truly portable, you'll need to think about another way of referencing the address for the specific service reference from within the class library.
I'd think it more confusing if you had multiple configuration files running around.
If a library has configurable items, I would fully expect to have to put that configuration in my config file to properly consume the library.