I have an WCF Webservice project, built in my local machine, which when hosted using test client and triggered, returns values from remote database in JSON format.
For example, if you key in the URL with localhost then you get results back in the below format:
{"Id":3,"Value1":"67.5687","Value2":"126.7125"}
I want to host this project on a remote server with a public URL, which should return the above results back from any network. I have 3 question regarding this:
** What modifications should I do to my current WCF project to host it on remote server.
** Given the various types of hosting like :
1) windows process activation services (WAS)
2) IIS
3) Self hosting
4) Hosting in a Windows service,
which type of hosting is best suited for hosting on remote server.
** What changes should I make in my App.Config file (including the change in my endpoint address from localhost to IP address) to make the service work.
Thanks.
1) You shouldn't need to make any changes to your project just because you want to host the code on another machine. I find this an odd question.
2) Given your choice of JSON as data format and a browser as test client, I'm guessing you want to make it available over HTTP using simple GET requests. In the Microsoft stack, IIS is the web server, and the natural choice for this scenario.
3) It is quite impossible to answer. I don't know what's in your app.config today. I don't know if you're going to authenticate, and if so how. And I don't want to know! That said, it seems to me if everything is supposed to behave as it does on your dev box, the bindings are already ok. I don't remember if a WCF service needs to know about the endpoint it is itself at (hard to see why it would need to know this, really); I would have thought it more natural to do such configuration on the host, e.g. IIS. The client of course should use a different endpoint pointing to wherever you host the service. (You can put many endpoints in app.config and let the user choose one, btw.)
I think most of us sin against the following advice now and then, but it is the best advice I can give: Read a book. Learn as much as possible about the thing you're using, in this case WCF. You'll get the time back later, and your software will be less bad!
Related
I was reading this article from Microsoft and in step 5 it says: The WWW Service uses the configuration information to configure HTTP.sys.
What exactly is the WWW service configure in HTTP.sys?
What is the purpose of the WWW service?
How is it different from the Windows Process Activation Service (WAS)?
Thank you!
In short, WWW service gets the configuration elements from applicationHost.config and applies the portion related to Windows HTTP API to the driver HTTP.sys.
The purpose of WWW service is roughly documented in https://learn.microsoft.com/en-us/iis/get-started/introduction-to-iis/introduction-to-iis-architecture#how-the-www-service-works-in-iis
Don't try to acquire a deep understanding of such components at the beginning. They are not open sourced so he documentation is rather vague.
The same applies to WAS, https://learn.microsoft.com/en-us/iis/get-started/introduction-to-iis/introduction-to-iis-architecture#windows-process-activation-service-was
If you are taking a course, just memorize the facts at this stage. Once you get more familiar with IIS daily operations, you will get more insights.
We have run into a problem with IIS, TLS 1.2 and domain users. I searched SO and other forums, but all possibly related topics didn't lead me to a solution.
Please don't judge the configuration, it wasn't invented by me, I just need to solve this problem.
What happens is the following:
We have an old web application, that opens an executable with Process.Start and that executable calls an external webservice. This used to work fine with TLS 1.0, but in the near future, the external webservice demands TLS 1.2.
So now we are trying to make this work, and we are almost there: we upgraded the executable's .Net Framework version to 4.7.2 and enabled TLS 1.2 on the Windows Server 2008 R2. The web app's .Net Framework version is set to 4.6.1. It seems to me that this should be everything there is to it.
And indeed, when we run the executable stand alone (not called by the web app) from the server, so owned by the domain user logged on to the server (with RDP), everything works as expected; we receive the proper answer from the web service.
Also, when we call the executable by the web app and in IIS the application pool identity is set to a build in account: ApplicationPoolIdentity, everything works as expected as well.
But, when we set the application pool identity to a dedicated domain account (so a different one than the one that executed the executable earlier), the trouble begins. Connecting the web service fails with the following exception:
System.ServiceModel.EndpointNotFoundException: There was no endpoint
listening at https://<some url>/<some webservice name>.asmx that could
accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details. --->
System.Net.WebException: Unable to connect to the remote server
---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond ...
Now the question is of course, what could be causing this?
I like to believe that the failing domain account is configured correctly, but it seems it is not. Or could it be something else, that I don't even know the existence of...
EDIT:
I managed to narrow it down to a permissions issue: when the dedicated domain account runs the application stand alone, it works as it should. When the dedicated account runs it from within the IIS context (started by the web app), it doesn't work, but when the dedicated account is given admin rights, it also works as expected.
That leaves me to the question: what additional permissions does IIS need to allow this setup? Maybe in combination with TLS 1.2 thingies.
Any help would be greatly appreciated.
I have an ASP.NET webservice which is deployed on Server2008 IIS7. We use two servers, Production and UAT (test server) and this webservice is deployed on both servers, the same compile is on both of them (no code changes, revisions etc, pure copy/paste from one to another).
The only difference between the applications is a connection string in web.config, one points to PROD database, the other UAT.
If I make a call to the test webservice I get an expected response and all is well, but when I do the same thing on the production webservice I promptly get and error
Server was unable to process request. ---> Object reference not set to an instance of an object.
I am suspecting there must be a configuration issue as the webservices are running under their own Pool which is run by a service account/user (local admin on the servers) and they are set to only run through SSL (https:// only) on a special port.
I tired sniffing with Fiddler and got two identical SOAP requests, the only difference being the server name in URL. I can access the WSDL of both webservices from IE browser, I can successfully refresh my web reference in Visual studio (for both prod and uat services).
Does anyone have any hints what should I be looking at, perhaps someone had a similar problem?
This is resolved. As I suspected the error was in production server configuration. When the sys team added a service user into the local Administrators they added it through Active directory groups, which as I am told requires a logoff/logon or a restart.
Server restart was the solution in my case.
We have deployed an application on the server.
Problem is, sometimes the application will be down due to some issue (Ex: While Downloading huge volume of data into Excel).
The application will be up after manually restarting the IIS.
We are creating a new application, so we are not working to fix this issue.
As a workaround, we are trying to build an exe with the below requirement:
Ping the application deployed on the server and find out whether the application is up or down, If the application is down, restart IIS.
Is it possible to ping a local website on the IIS? Is there any other way to do a temporary fix?
Hmmm, that kind of stability isn't good. However, you're interested in monitoring a URL and determining whether it is active...
TBH, I'm sure there are a few monitoring applications knocking around, some even free if that's you thing that will recognise specific ports and utilise appropriate protocols such as HTTP. But if you fancy having a go yourself you could always utilise the HttpWebRequest to mock up a request to the server and hopefully it will respond in a timely manner. Typically if you're just touching the server you can utilise a 'HEAD' request you just receives the header data rather than all the data. Check out this example.
I would like to be able to step through an application deployed to a remote location which as yet has nothing bar version 3.5 of the .Net framework.
What steps do I need to go through to achieve this and how long would you envisage this taking?
How to: Set Up Remote Debugging
Screencast for Visual Studio 2008 - Remote Debugging with MSVSMON.EXE
This is also a good KB showing some troubleshooting scenarios..
If you have unrestricted TCP/IP access to the remote location, this will be very easy (as in, 5 minutes tops to get it to work): see How to: Set Up Remote Debugging and How to: Run the Remote Debugging Monitor for the steps involved.
If your development machine is separated from the remote server by firewalls, routers, etc., things get a bit more difficult. Since remote debugging requires Windows authentication, DCOM and other things that are usually (and quite sensibly) blocked by security policies, you'll most likely require some kind of VPN access to the remote network in order to get things to work.
Setting up a Routing and Remote Access service on the target server is a quick way to get PPTP dial-in access to it, but there are significant security implications to doing this. So, this is most likely the step that will take up most of your time (and, depending on the organization that manages the target network, lots of discussions with their network/security people...).
My advice would be to start testing with remote debugging using a test machine on your local LAN first, and deal with the connectivity issues once you're comfortable with the basics.