I have a quite old web-service (asmx) that run well on IIS. Now there is a need of start this up in a windows-based application e.g. a console application (or perhaps in a windows service)
Is there any way of hosting the current ASMX project in a console application without modifying this? Unfortunatelly we cannot convert this in a WCF.
I appreciate any help on this.
Related
I've just created a simple asp.NET web service application with a WebMethod that passes the current server time and a Windows form application to run alongside this as a client.
As it stands, for the client app to be able to interact with the server app, the web service application needs to be running (runs in a web browser). If the browser is then closed, the client app cannot talk to the web service app.
Ideally, I would need this web service to always be running in the background on my server at all times (not just when a web browser is opened) and start when the server is booted up.
What would be the best way to achieve this? I have minnimal experience with asp.NET so is there a way to configure the web service to be a background service? Do I need to create a seperate Windows service application that uses asp.NET web services?
Any help appreciated, thanks.
Yes, by default, Visual Studio stops debugging your web application when you close the browser used for debugging... But you shouldn't run your application from Visual Studio. You deploy web applications to IIS. Then they'll start when the machine starts, and they don't need a browser to keep running.
I developed a windows desktop application using vb.net. I want to use the application with windows headless server. It will be easier if it has a web interface like utorrent. My initial approach was to write the current state to a text file (JSON/XML) and then read the file from the web interface. but it leads to too much read/write operation. is their any better approach? how about using REST API calls?
You could run a WCF web service from your WPF application, see https://learn.microsoft.com/en-us/dotnet/framework/wcf/how-to-host-a-wcf-service-in-a-managed-application
That would expose an API that you could run a client against (eg. using Javascript on a web page).
I've read in some articles that we can create a console application in .NET & we can host that in IIS which makes our console application as web application. Is it a rumour or can we actually do that?
Also, please provide a working example or procedural steps for that, if we could do that?
Thanks
Console application cannot be run as web application in IIS by itself unless you have a web application calling your console application to trigger on it. of course your console application path must be accessible.
Configured framework, run time at ease.
I want to know why we should use Webapi SelfHosted and where it is useful?
Let say we have a console application and selfhosted webapi what is the benefit?
The main benefit is that you do not have to set up IIS and websites when you deploy it. This way, you can simplify the deployment of the service and make it easier for administrators that are not experienced with IIS to install it. Typically, you would not use a Console application for self-hosting an API in a real-world-scenario, but a Windows service that runs whenever the computer is running - without requiring a user to be logged on.
In a less common scenario, you could use a self-hosted Web API for inter-process communication. If you want to exchange data between some processes either on the same or on separate machines, you could host a Web API in the application that provides the data and access it from another one.
I have a C# application that needs to always be running. I originally planned on making this a windows service but I now have a requirement to make the application host a web admin console.
I haven't played with IIS in quite a few years so my question is this:
What would you recommend I use?
I've thought about making a windows service and embedding a web server such as Cassini but so far I'm not very happy with the open source web servers I've looked at.
Can IIS handle this? Do people use it for this type of scenario, and if so how?
This sounds like a job for two separate projects.
One is the original Windows Service. Windows Services are well suited for what you're doing.
The second is the Web Project that will be used to administer the Windows Service. This is the part that runs in IIS.
It depends on what you mean by always running. An ASP.NET web application deployed in IIS could very well be unloaded by the web server if there aren't any requests for certain amount of time killing all background threads. So if you want an ever running background thread it would be better suited to use a Windows Service. As far as the web admin is concerned, well, here you don't have much choice: ASP.NET in IIS. In order to do something useful those two applications should be able to find a common language to talk. So you could use a database to store the results into which could be used by both applications.
IIS will run your app on first request, not on server boot. So you will still need to run a service to ensure your app is always running.
You can use IIS as a webserver for your web admin part, and link your ASP.net app with your service by means of a configuration database (easy) or webservices (a little more tricky).
Windows and Web services are two very different creatures. A web service will expose external methods that you can implement against an application, while a windows service is an entity within itself. If you're planning on using this service on a timed interval to perform an operation, a Windows service would be the right way to go. If you use a web service, you will need to invoke the method you wish to run from a secondary application.
If you need to queue commands against your windows service, you could always create a database that was accessible by both your website and your windows service. This way you could send commands and query data between the two. Placing a web service in to serve as an intermidary between the two may be overkill.