I have been trying to import methods from a WSDL file by adding a service reference.
As you can see here,
It has found the services with the operations, but after pressing OK, I still cannot use them and they are not even visible in Object Browser.
Does anybody have any idea, where could be the problem? Why does it find the methods and services, but still cannot access them?
PS: I have never worked with WSDL files so I do not understand it well..
Related
I am trying to use Swagger UI to document our node.js API, so I went to http://swagger.io/docs/, down to Swagger UI Documentation -> Usage, to find this
Now, this is not the only place that provides these instructions, there are dozens of blogs & tutorials saying the same thing, so that's exactly what I did.
Cloned the repo, went into /dist/ and ran the /dist/index.html and all I get is an empty page with an error:
I'm slowly going crazy now as I can't find anything about it and literally every place I looked just has the same, copied, instructions with nothing else provided (like what could go wrong? you just open a file...)
Any help or explanations are much appreciated!
P.S. for some reason opening the /public/index.html works (mentioned nowhere on the www)
I think this is bug in new version of swagger-UI. This is fresh release and they are still modifying and fixing bugs.
Look here: Swagger-ui cannot access JS scripts. This seems to be similar problem, maybe it will help you.
PLEASE NOTE: None of the answers in the link above (which I don't seem to be able to remove) helped me. As I explain below, I had already tried all that stuff
I have a web site, developed in VS2013 using ASP.NET MVC5/WebAPI2, which has several related projects such as a service layer, repository layer, etc. Down at the bottom of the stack is a class library that holds an EF model. I have separated the actual entities into another class library, to allow them to be reused without requiring the model library.
All of this has been working fine. The web site was running, and I could make calls to the WebAPI methods as well.
I just uploaded the latest version to the production server, and all is working fine there. Then came back to VS to carry on work, and when I try to run up the web site, I get an exception
Unable to load the specified metadata resource
Searching around, it seems that the cure for this is to modify the connection string to point to the actual assembly name instead of using the default . I have two problems with this, first is that none of the config files in the solution have been touched today (by me at least, and the file history form source control confirms this), so there's no reason why it should suddenly stop working after being deployed, and second, even if I add the assembly name, I get the same exception.
Anyone any ideas what I can do? I'm completely stuffed now. Can't do anything.
Edit: I tried again to specify the assembly in the connection string, and now get the exception Unable to resolve assembly. I have checked the assembly name in a decompiler, and I'm pretty sure got it right.
Edit again: I just pulled the version that I deployed from source control, and that gives the same exception, so I'm sure this is nothing to do with any files I've changed (or even that have been changed by VS). The version on the production server is still working, but the source code that drives that exact same version gives the exception. So, I'm certain that the answer is NOT to be found in the myriad other versions of this question, but is somewhere else.
Found the problem, and am posting it here in the hope that it will help someone else, as I don't think this was clear in any of the other posts on this issue.
I have a layered solution, with the web project referencing a service layer, which references a repository layer which in turn references the model project. It seems to for EF to work, whichever layer actually causes the database to be accessed requires a reference to the model project. My service layer project, which was where ToList() was being called (thus enumerating the query, and causing the database to be hit) didn't have a reference to the model project, so was failing to load the assembly.
I didn't need to alter the metadata part of the connection string either, as once the service layer had a reference to the model project, it was able to find the resources by itself. Having said that, one thing I did learn from all of this is that you can speed up the creation of the model (slightly) by specifying the assembly containing the resources explicitly, as this saves the framework having to search through all loaded assemblies to find them. I'm not sure if this will make any noticeable difference, but it can't harm.
I still can't explain how this had been working up until now, and suddenly stopped, as I hadn't changed any references, nor the way I was doing the data access. Still, it seems to be working now, which is all that matters.
Hope this helps someone.
I have code using the SysOperationFrameworkService, and after a model-deploy or some other set of circumstances, many users get Function SysOperationDataContractInfo::newParameterInfo has been incorrectly called..
It's unable to be resolved with full-compile, sync, full CIL, deleting XPPIL files, deleting AUC/KTI, usage data, security (they're admin), refreshing caches (server &client), etc. and I have a ticket open with Microsoft and they're struggling.
I've narrowed the issue down to when the service group AxClient located in the AOT at \Service Groups\AxClient WSDL files get deployed to C:\Users\[User]\AppData\Local. Either those files existing there, or something happening when those files get deployed is needed.
Any idea how/what causes these files (AxClient.wsdl, etc) to be created? With a user who happens to be "working", I can close the client, delete all the files, open the client, and no files will exist...then I perform a SysOp process and those files get created during that process. With the non-working user, with same security on the same machine does it, the files don't get created.
I have found that the
"Function SysOperationDataContractInfo::newParameterInfo has been incorrectly called" has been throwed because of a possible bug in the kernel when calling the "dictMethod = new DictMethod(UtilElementType::ClassInstanceMethod, dictClass.id(), methodName);" in the SysOperationServiceController.getServiceOperation() method. In my case the new DictMethod was sometimes unable to get the method parameter from a superclass, causing the _parentMethodParameterName check fail in the SysOperationDataContractInfo.newParameterInfo.
So, I solved the issue just by doing an override of the super method where the parameter could not be retrieved and then just calling super(_parameter), then everything went well.
Have you tried axclicfg.exe -> connections -> refresh
Recently I got the error "automation server can't create object", for which I know the solution is to add your website to trusted sites and enable the setting: "Initialize and script ActiveX controls not marked as safe for scripting". But since this is a security issue, I searched for an alternative workaround but came up with nothing.
So, I am wondering if there is any other work around for this?
Please look at this SO question. Check if you did everything that was discussed there.
The first thing is to implement IObjectSafety interface. Then sign the activex and installer and CAB. You might also want to look at this example how to implement an activex.
We've recently setup out own webservice using SOAP and it all works like a charm.
Because the service is only used from within our own applications, I usually don't allow for a WSDL to be generated.
Today i started some tests with SoapUI and needed a WSDL of our own service. So I enabled the Default action of the TWSDLHTMLPublish component and tried to get the WSDL exported. All I got was an access violaton in WebServExp.GenerateXMLSchema, line 1636:
if (ParentInfo = nil) and ((GetTypeData(ATypeInfo).ParentInfo)^ <> nil) then
Debugging this, reveiled that GetTypeData(ATypeInfo).ParentInforeturned a nil, so of course using ^ on nil raises an access violation.
After removing the carret i had no problems generating the WSDL.
So did I find myself a bug here or am I missing something?
BTW: We have created our own SOAP.bpl, containing all original Delphi soap sources, to correct it for a known problem with exception derived from TRemotableException
So did I find myself a bug here or am I missing something?
Yes, that's a bug. And Subversion reveals it's been like that for many years - for as long as we've been on Subversion:(. [I am not setup to access the previous Starteam repository anymore].
I'm making to a note to remedy and check in unit tests for this. Please feel free to file a QC if time allows. And I'd like to hear more about the issue with TRemotableException-derived types.
Cheers,
Bruneau