i am trying to develop a client application (both in java and .net) using a wsdl file.
The problem scenario is that:
in .net the classes generated by adding wsdl is different to the classes generated by adding same wsdl file in java.
here the difference is that in java some classes are missing that are present in .net.
also for some class in .net the class variable is generated while in java these class members are missing for the same class.
so, please let me know why this type of different behavior is shown for the same wsdl file in .net and java.
Related
The status of SOAPsupport in .net 4.5 is very ambiguous for me...
I'd like to do RPC on my home router (It is based on OpenRG)
I am trying to write a soap client and I'm baffled by all the tutorials that say to import that assembly.
I have no WSDL file for the CWMP proprietary version of the maker, so I'm on my bare foots (reversing from the Web UI).
Optionally, is there any program to easily create/modify WSDL files with a fancy UI and everything else? Maybe my best option is to start with some WSDL file for generic CWMP and modify it with the extensions of the maker?
Can VS2012 build a proxy in a PCL project to consume a WCF service for SP2010? We add a reference (old school works everywhere else) but once we make calls, for instance GetListsCollectionAsync(), we get all sorts of errors. When we build the proxy, VS gives a warning:
Service proxy generation failed. Proxy requires type 'System.Xml.Linq.XElement' which is not supported in portable libraries
Has anyone successfully subscribed to a SharePoint WCF using a portable class library? The same stuff works fine in .net 4.5 class libraries and in metro libraries. Only portable ones give us this problem. We have win 7 and win 8 devices in the mix - so PCL would be a really good fit.
Got a conclusion here: We found a work around and the statement that this is a bug in VS2012 PCL projects still stands.
We created our proxy in a metro project and simply copied the reference.cs file over into the PCL project. It was a "what the heck - why not" last attempt of sorts, but it actually works. Even better, the calls are awaitable and come with response objects. Awesome!
Cheers,
Gregor
I have this project developed by some goofball who decided to nest a dependent WebService within the Web Application that uses it. This has caused problems with publishing changes because you can't update the WebService without Publishing your changes first, and you can't Publish the changes without the WebService being updated at the publishing location. It's totally paradoxical.
Any suggestions on how to remedy this simply? I'm thinking it might be best to somehow extract the WebService out into a separate project which can be published independently (this is best practice after all, isn't it?). Also note that I have updated the project to .NET 4 which has the option to use a WCF Service instead, however if this would require a major reworking of the project, then I would like to keep things as simple as possible.
It's difficult to provide any code to illustrate this problem, but here is the basic hierarchy of the project.
Solution
Project
WebService
MyService 'This is a reference to the Web Service
Service
MyService.asmx 'This is the actual code for the Web Service
[Other Code Pages within the project]
EDIT: What if I did this? This way they could be compiled and published independently of each other.
Solution
Project - App
Web Reference
MyService 'This is a reference to the Web Service
[Other Code Pages within the project]
Project - Service
Service
MyService.asmx 'This is the actual code for the Web Service
The only remaining decision (assuming this is a recommended approach) would be whether to create a WCF Service Library or WCF Service Application? (Remember, this service is only used by this one app and is not shared by any other).
I would definitely extract the web service into a new project.
In addition, if there is other "shared" code (classes, modules) that is common between the projects, you have a couple of choices, depending on how much code needs to be shared:
1) Link the source files from one project or the other (so that you only have a single physical copy of the class)
2) Create a DLL project that each of the projects references and then move the shared code to that project.
3) (Obviously) Duplicate the code in each project.
there! I have a library written with .Net Framework 4. This library exposes some objects as COM via System.Runtime.InteropServices, which are registered with the regasm utility. These objects are intended to be used by an old (not .Net) ASP page, which is configured under an application that runs .Net Framework 2 (I know!!!) on IIS6 (Windows Server 2003).
Everything seems to work, except for the configuration file. When the .Net 4 COM object attempts to access System.Configuration.ConfigurationManager looking for a connection string, it gets a Null Reference exception. The web site has a Web.config file, and obviously the connection string is there, but the library can't find it. I think that it's because the Web.config is for the .Net applications running under IIS, and the COM library is seen as an external component.
I don't know where else the library might be looking for a configuration file. Changing the machine.config in the FW4 folder works, but I'd like to know if there is another location I could use, because machine.config is system wide and I don't want to pollute that, especially with connection strings. I tried adding a mylibrary.dll.config file in the DLL folder, but it doesn't work either.
Thanks in advance
I have some methods which are not compiled with Silverlight framework but are very essential for execution of SL workflow(by workflow, I mean to process my application completely). What is the best/quickest way to do so?
I was thinking of publishing a web-service(for non-sl compiled methods) and make SL call into my WS.. but I am unable to see/create webservice instance even after registering one in my SL project. (I am using VS 2010)
any help?
Esentially, you have three ways to run code.
native built-in methods in your application--this would be the easiest way
methods that live in an external silverlight assembly, like a class library
use a webservice
if you use a webservice, you have to either host the website yourself or use a 3rd party website, then add a reference to said service. if the service is not hosted on the same website as your silverlight app, there must be a cross-domain policy file in place otherwise silverlight will not use the service.
if you use an external assembly, it MUST be a silverlight assembly. you can not use a windows class library, etc.
There is a common (and relatively easy) way to solve this issue without requiring a web service: you can create a new Silverlight class library and then share the files from the other project through to your new Silverlight library.
To do this, right click on the library in the Solution Explorer, and select Add -> Existing Item, then navigate to the appropriate code file, select it, but instead of just clicking Add you should instead click the little down arrow and select Add As Link.
Of course when you do this you have to ensure that the shared files don't contain anything that cannot be compiled targeting the Silverlight runtime, if they do then you will either have to use conditional compilation directives to isolate out that code, or revert to the web service option.