I wanted to access WCF service from Mobile Service in Windows Azure. For this, I am using Service Bus Relay connection which is configured with credentials to call the WCF service.
When I published this Mobile Service on my local machine, I could call WCF service without any issue.
But when I published this Mobile Service on Azure, it is giving following error when trying to access it. IService1 is contract for WCF Service. I defined endpoint in Web.Config file in Mobile Service with this contract.
Can you help me resolve this?
Exception=System.InvalidOperationException: Could not find default endpoint element that references contract 'ServiceReference1.IService1' 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.
EDIT:
Upon further investigating this issue, I found out that, proxy class, which is generated by adding service reference, is not picking up the endpoint definition defined in Web.config when we host it in the cloud. But when the service is run on my machine's azure emulator, it is picking up endpoint definition from Web.config.
So, to resolve the issue, I had to define endpoint programmatically and use the ChannelFactory class to call the WCF service.
Any thoughts on why Mobile Service is unable to read Web.config in cloud?
You can set the app settings as key/value pairs in the appSettings section of the .NET backend project’s Web.config file. These values are used when testing a .NET backend project on the local computer. When running in Azure, these values are ignored and the portal settings are used instead.
http://msdn.microsoft.com/en-us/library/azure/dn529070.aspx
So I guess there is something special about .config file in Mobile Services but I don't know more. Initializing your WCF programmaticaly is a good solution.
Related
I'm facing issue with my multiple project solution in .net core webAPI. I've gatewayAPI which internally makes call to different microservices via http call.
Gateway API URI exposed to outer world which has domain as azure app name but the internal calls from gateway to microservices are configured with http://localhost:5001/{apiEndPoint} which is working fine in my local machine but after deploying it on azure app service I'm getting below error:
PostToServer call URL:'http://localhost:5001/api/authservice/authenticate' with Exception message An attempt was made to access a socket in a way forbidden by its access permissions. (localhost:5001).
Can someone please help me with this, I'm new to azure and learning on my own but could not find any solution for this yet.
PS: After going through some YouTube videos and blogs I got to know we have to use AKS but I'm not confident in that.
Would really appreciate any help on this issue.
The Gateway API you deployed to azure app service, it doesn't support custom port usage for 5001. Azure App Service only supports port 80|443(HTTP|HTTPS).
If you must use multiple ports in your actual project, then it is recommended to check whether Azure Cloud Service meets your needs. But it not the best choice.
The Best Practice:
Microservices architecture design
In short,create a Azure Gateway service, and your other microservice can be deployed in any where.(azure app service, vm or aks)
You just make sure you can access your microservices in your internal or public network environment.
If you're just learning, or the app isn't actually used by a lot of users, you can try the following suggestions:
Use SignalR (not azure signalr) to replace the websocket in your current project.
You have on azure app service, you can deploy your Gateway API Application to app service, and your other microservices can be deployed to Virtual Application in azure app service.
I want to expose the Internal APIs through Azure API Management however the gateway is unable to access resources within the virtual network.
Below is my VNet configuration
Below is my API Management Network settings
I have created a Azure VM as shown below
and deployed the Spring Boot application as shown below
Tried configuring the APIs in the API Management however the gateway is unable to access the above internal URL
How do I fix this?
Update:
If I save the API definition and upload on APIM it works without any issues.
When you create an API in APIM from portal, if you put the OpenAPI (swagger) spec URI in the field shown in the screen, it has to be publicly accessible (not necessarily the API itself, but the spec). It's because you are browsing the Azure portal from internet and portal UI form simply tries to access the file from your client side browser before uploading. I agree that it could be nicer if APIM could access it from the server side, but unfortunately that's not the case at this moment. Consider it as a simple feature which either allows to to upload file from your machine or from a URL publicly accessible.
EDIT*: Looks like VNET is not into picture in management plane.
In this case, you can just download the swagger file itself and use the "Select a file" option.
We've implemented a setup as follows:
App Service Environment having different app services exposing different APIs. This instance is configured as an internal instance, so no public access.
We've configured an internal (private) DNS zone. This zone is used to create internal URLs for the API's.
API Management instance which is exposed to the outside. Here the API's need to be registered using the Swagger files exposed by the APIs themselves.
Everything is contained within the same VNet.
Now what we see is two things:
From a VM inside the VNet, I can browse the URL of the API without any issue and download the Swagger file.
When we try to register the API within API management, it throws an error stating the file could not be downloaded. When we register manually and then try to call the API, we get a DNS resolve error.
So it seems as if the API Management instance is not able to resolve our custom DNS zone as setup in Azure. I could not find any information that tells me whether this scenario is supported or not. Any pointers that might help find the problem are very welcome indeed.
Update when we register the API via uploading a file and then try to call one of the API methods, the following error appears:
The remote name could not be resolved
This same address resolved just fine from a VM within the exact same VNet.
I have the same issue, when I look for online, the below solution looks promising. It is self-explanatory, DNS forwarded need to enable between vnets. More information is here
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md#name-resolution-that-uses-your-own-dns-server
Originally I was going to deploy a new system I am creating straight into Azure app services
However part of the system needs to get data from a third party via a dll which is registered with regsvr
Is there any way of doing this or avoiding this?
I think I have to create a virtual machine?
Paul
Due to the way the AppService Sandbox works, you cannot execute a regsvr operation.
See also:
SQLXML on Azure Web sites
General information about the sandbox:
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
If you need this component, and want to avoid using virtual machines, you could try hosting the component as a web API inside a Azure Service Fabric cluster.
You can use OWIN to host the API, and it should be possible to register your dll via startup tasks.
Azure Service Fabric register COM component
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cloud-services-migration-worker-role-stateless-service#startup-tasks
Depending on your application, you could either host everything in the service fabric API, or host only the component as an API there, while providing the actual application inside as Azure AppService.
I have two Web Apps, inside the same App Service. One is a back-end portion (with API on it, using .NET Core, SSL cert installed) and the other one is the front-end (ReactTS, created using create-react-app).
When I try to call the API method (an Auth method) using my Front-end I got this message as response:
Login failed: The resource you are looking for has been removed, had
its name changed, or is temporarily unavailable.
-404 error
Another fact is, if I run my ront-end solution locally, I can use the API (published on the Web App), normally.
My API URL is set inside the package.json file, as proxy.
My first thought was about an CORS problem, but it throws a 404 error.
Any configuration that I can do on my Azure, or something that I need to change in my application to allow my front-end to communicate with my API?
If we publish two web applications to one Azure Web App, the later one will cover the first one. It will cause that the first web application can't work. I suggest you create different Azure Web Apps for your web applications. You could choose one Azure Web App Plan for your Azure Web Apps. It will not add extra costs except for Shared plan.
If you use Shared App Plan and don't want to increase the extra cost, you could add a virtual directory to your Azure Web App. Then you could publish your second web application to the virtual directory. To create a virtual directory, steps below are for your reference.
Azure portal -> Web App Panel -> Application settings