I am having an issue similar to this question:
Problem with WCF and Multiple Namespaces
The major difference I am having is that I don't control both ends of the wire. My setup is similar to this:
My.Objects
My.LoginService
My.Service1
My.Service2
The first thing you do is login via the login service and receive a security ticket. The ticket object is located in the My.Objects namespace. For each subsequent call in My.Service1 and My.Service2 you have to pass in the security ticket to authenticate the call. The issue I am having is that instead of the client (a .net one for now but Java and others in the future) seeing one My.Objects.Ticket the references are resolving as My.LoginService.Ticket, My.Service1.Ticket, and My.Service2.Ticket. When the client tries to pass the object retrieved during login to any other function it is receiving an object mismatch error.
How can I make each service resolve objects to the My.Objects namespace?
Have a look at the NetDataContractSerializer, might be what you're looking for. It's different from the DataContractSerializer in that it includes the CLR type information in the serialized XML which allows you to share your type but forces both ends of the wire to use the same type.
Have a look at a blog post I put together and an attribute (from another blog I stumbled across) to inject it on operations that needs to use it:
http://theburningmonk.com/2010/08/wcf-using-the-netdatacontractserializer-to-share-your-type/
Create an assembly referencing one of the services with a ticket type and then reference this assembly from your main project.
There is an easy way to share types between client and service, just by adding reference to shared type assembly to your client BEFORE adding the service reference.
You can find the detailed scenario and sample project there:
http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server-and-client.html
Related
I have two service references that I am importing into my asp.net project by importing a WSDL for each. The first reference is a default reference from my web service (Acumatica) and the second is a custom endpoint service I created in the original web service.
The problem is that both of them use the same "base types" in their object classes so when I include both namespaces to use the objects from both of them in my code, I get an error saying there ambiguous references between the base types in the two namespaces. Makes sense. But how can I set this up so that .net knows to re-use the base types between the two namespaces since they are exactly the same?
To show what I'm talking about:
You can see there are types that are exactly the same between the references. Can I configure these references to re-use those types between the two of them to get rid of my ambiguous reference errors?
Unfortunately, there's no way of achieving what you want.
The thing is, the base classes used are not the same (they have different attributes which leads to different XML (de)serialization). To add insult to injury, when we researched this issue, we've found out that WCF client utility which you use to generate client-side code does not support reuse when XMLSerializer is used, so even if Acumatica made the base classes exactly the same, there still wouldn't be any reuse on client.
But why do you need to different endpoints simultaneously? If your own endpoint is only adding functionality to Acumatica's Default, why not consider extending Default? This way you'd need only one endpoint in your code.
Create a class library (e.g. "MySharedContracts") where you place all the types you want to use in the web services. You can reference that same class library in your web service projects and in the ASP.net project that consumes the web services.
Then, in the ASP.net project when importing the WDSL definition, click on "Advanced" to open the "Service References Settings" dialog. In here, enable "Reuse types in references assemblies". You can then either let VS search for fitting types by itself by selecting "Reuse types in all references assemblies" or alternatively specify a set of assemblies that you want to use types from for the web services.
I am building a test-stub for a webservice, implementing the interface retrieved from the production webservice using svcutil. When calling a method on the stub i get the exception;
Object of type
'Sbsys.Services.HostService.DokumentBoks.DKALWSAfsendService.MaterialeType[]'
cannot be converted to type
'Sbsys.Services.HostService.DokumentBoks.DKALWSAfsendService.MaterialeType[]'.
where 'Sbsys.Services.HostService.DokumentBoks' is the namespace of the consuming client, and 'DKALWSAfsendService' is the namespace containing the generated proxy classes for the service.
Any ideas on whats going on?
Bonus info: When using the production service everything works as intended
Solved: I had a suspicion that it might be a versioning problem, and moved my servicereference to an isolated project, containing nothing else. Referenced this from both the consuming client and the webservice stub, hoping that this would solve any problems with building multiple times or whatever. Presto. Problem gone.
Any chance that the wsdl/contract in prod is different from the one you call against ? If the proxy has been generated against the prod and use on another instance of the service with a different contract, you might have that kind of weird message.
Sometime this error occurs because of Generate Serializable Assembly option in Project properties (especially if you are using per-generated serialization assembly using sgen). Try setting this option in Project properties to Off and see if it works. After you turn this option off you will need to per-generate your assembly using sgen. There is some good discussion and background thread in this Q&A for this.
It it possible to call a function on an external class?
The external class runs on another machine (say its locations is mymachine.com).
have used CreateInstance some time ago but don't think that will do (correct me if I'm wrong).
I have been searching for a long time but haven't found a solution yet so I hope one of you can help.
one of the sources i have searched is but no info :(
http://www.dreamincode.net/forums/topic/102523-call-an-external-function-on-button-click/
hope u can help.
use a self hosted WCF service, remoting or any networking technology.
There is unfortunately no magic attribute to achieve that.
[Edit] I also would like to add that you me be careful. When you are using some remoting mechanisms (either remoting, WCF, rpc, etc.) you work with "proxies". A proxy is an object that simulate the actual object, but encapsulate the communication. It allow the developer to hide the complexity by having an objects, with properties, methods etc., but the technologies behind (xml messaging for a WCF service for example) must be known by the developer. It can have impacts on network, responsiveness, and also programming model.
This sort of operation is what Web Services / WCF Services / Remoting is built for. WCF is a really nice solution for handling communication across boundaries. Have a look into WCF, google is your friend.
See these:
http://www.aspfree.com/c/a/.NET/Introduction-to-RPC-on-Windows-Part-I/
http://www.csharphelp.com/2007/01/interprocess-communication/
If the external assembly is on a shared folder on the remote machine, then you can do one of the following:
1) Implement the AppDomain.CurrentDomain.AssemblyResolve event handler to load the external assembly, and make the calls you need to make. Also put a reference to the assembly in your project by the way (copylocal=false). The first call to instance a class or static method in the assembly will invoke the event handler and load the remote external assembly.
2) Load the assembly via reflection using System.Reflection.Assembly.LoadFrom() and provide te remote path. Use reflection to invoke the desired method, etc.
I have two "identical" webservices (Soap) on two different servers. Don't ask why :-)
WebService-1 decides if it handels the request itself or if it passes the request to WebService-2. If so, the response of WebService-2 should directly be returned from WebService-1.
The response datatype is complex and self defined. With simple datatypes like 'int or 'string' there would be no problem.
The response of WebService-2 is a serialized object (I think it is called "stubs") and theredore it is not possibel to pass this object through as the response of WebService-1 because the type of the objects doesn't match.
Is there a simple way to convert the serialised datatype into its original type without buiding a complex converter?
Yes - how to achieve this differs depending on whether you are using WCF or old-style Web Services.
Essentially, you want the web reference tools (svcutil.exe or wsdl.exe, respectively) to identify that the result of the webservice is actually a "well-known" object type - much as it does for many of the core framework objects.
Within WCF, this is normally achieved by ensuring that your contracts are held in a referenced assembly, and are decorated with namespace attributes. If you do this, when you add a reference to your webservice it should use your class natively instead of generating a similar proxy class.
If you are using old-style web-services, you will have to look into using a SchemaImporter project - this will allow the wsdl.exe tool to recognise your types and correctly utilise them. It should be mentioned that this is only required at design-time - no such measures are required during deployment.
I have an application which consumes both a WCF service and an ADO.NET Data Service. Types are shared between the server and client using a shared class library.
When I configure the service reference for the WCF service, I can choose to use the existing types in the class library to avoid creating duplicate types in the proxy classes.
But Visual Studio doesn't offer me the option to do that on the ADO.NET Data Service.
Is it possible for an ADO.NET Data Service to reuse existing types?
Great question.
Yes this is definitely possible.
I just put together a Tip that show you how to turn off default Code-Gen and reference an existing type instead, and showing how too tell the DataServiceCpntext how to do the mapping between the type expected on the wire and the type used on the client.
NOTE: that even though the Types might be the same inside the DataService and on the client it is still possible that the Data Service has been configured to expose the Server types in a different namespace, so this mapping may still be required.
Anyway I'm sure Tip 52 will help you get your scenario working.
Alex
Way i would do is instead of creating proxy through add service option.
Use DataServiceContext directly
then can use
Execute<TypeOfData> method