I got a strange problem recently. I have some VB6 .dll that I must use in my ASP.NET Web Service project. When I test the .dll in Console application - all works fine - I create an object and can use all methods as it should be. But when I start to use it in my Web Service I got a strange problem. When I'm creating an instance of dll class - it is created (after a long pause) but all properties instead of being nulls (as it happens when I test it in Console Application) in the debugger are set as "Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation". Something competely strange I've never seen before :) And at the same time in my client application (which actually invokes the service) I'm getting a connection reset.
Any suggestions?
If this DLL was created for a desktop environment, then it may simply not work in a server environment. It may depend on using a Windows message loop for synchronization, and may not be thread-safe at all (and it needs to be thread-safe in order to use it in a multithreaded server environment like ASMX).
Related
The core of our system requires a WCF service to be either installed or launched in interactive mode. The latter is currently the preferred way for debugging purposes.
The problem I am having is that I would like to run regressions from Jenkins that require that service to be up and running first.
The service must first be built (C# solution) and cannot reside on the test machine, since its implementation may change over time.
I could add pre and post steps in my Jenkins pipeline to install/remove or launch/kill the service, but it is very messy and requires every single job to do the exact same thing (which could be omitted and result in having a residual installed/running service preventing any future job to run).
Is that the way to do it or are there other approaches for it?
Another issue in interactive mode is to keep the console (running the service) going for the time of the test (which is a separate process).
Say we started the service in interactive mode ; it would end up terminating before any test gets the chance to run.
What would be the way to keep the service running for the duration of the test only?
I am trying to run a background service which just writes to a file on a specified interval.
There are two methods that I tried
1) Created the project with the Console application template
2) Created the project with Web Application as template
When I run the app from visual Studio, both of them run fine. But when I deploy them to IIS, only the web application version works. It must be noted that there is absolutely no difference between the code of the two projects. I have used the WebHost as a hosting strategy in both the projects as well as well as installed all the dependencies in case of Console application as there are in the Web Application version.
I must also inform that I have used the preloadEnabled="true" option in IIS as IIS needs a web request to start the application.
I am wondering what is the difference between both the project types as the code is the same? I don't want the Web Application template.
Edit 1: I forgot to mention that the service will also need to expose an api endpoint for healthcheck purposes. Will the windows service approach listen for http requests?
I used the following article for implementing my background service.
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice
After years of building background services, I learned that Windows services are the best tools to implement these applications. While there are different techniques to keep an IIS application up and running in the background and prevent it from getting recycled, in practice, the applications on IIS are not meant to be executed forever.
If you had an intention to build your app in the cloud, I would have suggested using something like Azure WebJobs or Azure Functions Timer-Triggered functions, but for on-premise, even using something like Hangfire in the web is not sustainable. The worst happens when you need backward compatibility on Windows servers that don't have the "Application Initialization" module.
My suggestion is to move your application to a simple Windows Service if you control your environment. Windows services consume less memory, are easier to manage, and can run forever without getting recycled.
WebApplications are plain the wrong tools for this.
Being always on and always reachable, WebServers are primary targets for hacking. To compensate for that, they are usually run under the most restrictive user rights you can imagine: Read rights to their programm and this instances content directory. While I do not know why it worked at all, it propably will stop working in Production.
What you wanted to write was eitehr a Service or something executed by the Windows Task Sheduler. Personally I advise for the Task Sheduler as Services have their own set of restrictions. Unless of coruse there is some detail of the requirements that you did not told us.
This article could be helpful. It's a step by step tutorial on how to convert a console application to a web application.
I've created a Windows Form Application in C# and I added a Window Service on it. The problem is every time I started the Service after installing it, I always get the Error 1053 the service did not respond to the start or control request. But after creating a new project and Select Windows Service and Installed and Run it there's no error and the Service is Starting correctly.
So do I have to create a Separate project for Windows Service or I am just missing something?
My target Framework is 4.5.2 and I am planning to have UDP and TCP function inside my Windows Service.
Calling ServiceBase.Run() from Main() is what makes an application a service rather than a normal application. If you created a project using the Windows Service template, but took away the call to ServiceBase.Run(), the result would be a normal application rather than a service. (Probably a broken application, but an application nonetheless.)
Under the hood, ServiceBase.Run() calls StartServiceCtrlDispatcher(), which calls the internal ServiceBase.ServiceMainCallback() function, which calls your OnStart() function. So if you don't call Run() there will be no call to OnStart() and your service won't do anything.
The StartServiceCtrlDispatcher() function is also indirectly responsible for calling OnStop() and all the other related methods. Basically, it's the core of the service, and without it nothing will work. Also, of course, if you don't call it Windows will eventually notice that the control dispatcher hasn't started, assume that the process has hung, and kill it. That's what error 1053 means.
While it is possible to incorporate both a service and an application in a single executable, it isn't trivial to get it working properly. It is also an unusual approach, not often used. Unless you have a compelling reason to avoid doing so, I'd recommend that you use a separate project for your service.
I'm currently working on a WCF service which holds and processes all the data for an application, while a MySql database is used for persistence. The service currently works as a singleton (InstanceContextMode.Single) and supports multiple concurrent calls (ConcurrencyMode.Multiple). I'm not really sure what version of IIS the service is hosted in, but I believe it is IIS 7.5.
The problem is that there are some situations where if an exception occurs (eg.: while releasing ReaderWriterLockSlim locks), the service will be in a unreliable state and data may get corrupted (and written into the database) if users keep calling the service.
Currently I know of two ways of preventing users from calling the service: either closing the InstanceContext object (through OperationContext.Current) or raising an exception in IDispatchMessageInspector.AfterReceiveRequest if the service is in a faulted state. The problem with both of these two ways is that they make the service unavailable until I restart the server/application pool (which I can't, see note below) or re-deploy the service.
Important note: Although I have Full-Trust, the service is currently hosted on a shared server, so I can't restart the server or the entire application pool (if that is possible) because that would restart other people's services as well.
Update:
I tried unloading the AppDomain as #usr suggested, but that doesn't work as well: after unloading it, an exception is raised for every call to the service.
Currently I'm trying to find out what WCF/IIS uses as a condition to decide if the service should be created again. I noticed that in the code generated for the client checks if there is any channel available to communicate with the service; if there isn't, a new one is created. Thus, I tried to close all channels in the service: I tried closing OperationContext.Current.InstanceContext.OutgoingChannels, OperationContext.Current.InstanceContext.IncomingChannels, OperationContext.Current.Channel, and many other properties with "Channel" in their name, all of them with no success.
The way to warm-up anything in IIS prior to version 7.5 is using scheduled console application to ping your web site / services and warm them up. It's not a good fix but it works, it is easy and I saw it on every project which had to deal with this requirement.
Or If you are using IIS 7.5 then
You can use Windows Server AppFabric, it has Auto Stat feature to keep the service always on. But you need to be on IIS 7.5 to install App Fabric.
I have a requirement that a Windows Forms C# .NET 2.0 program running in user-space (not a service) must always be running. As I'm not infallible and make coding mistakes, I wanted to know of any extra safeguards I could use to ensure this requirement is met. The things I've been thinking of are TaskScheduler to check it every 5 minutes, A stub watcher or a secondary process. Are these good / bad ideas?
Thanks,
Richard
EDIT: The reason I didn't use a service (the obvious and sensible answer!) was the program runs in a kiosk type environment and has has a heavy GUI component. The service option didn't work well across Windows 2000 - W7.
EDIT: The second reason not to use a service was the app needs internet access and on some of our customer sites, proxies are set up to only allow specific users (not the local system account) so it would be tricky to ensure access if multiple users log onto the machine.
Task scheduler is a cheap solution for this which does work. I use this to keep our Perforce Proxy server running (had some issues with the service), and so far there's been no problems - though now I've said that the server's probably exploded!
However, the most complete solution is a Windows service which invokes your app. You can make that service catch error return codes from the app, restart it on failure and notify you by email, which may help you diagnose and fix those issues. I think the Task Scheduler does something similar but it won't be able to provide as much insight into your application as a custom service.
If you're unsure of how to do that, then something like this should work:
http://www.codeproject.com/KB/install/csharpsvclesson1.aspx
There are three approaches that you can take:
Heartbeat Message.
A heartbeat is useful in a distributed application and is simply message that is sent (from let say a client to server) to confirm that it is still healthy/running.
Manager Process
A stub program, implemented as either a user process or a service. It launches the main application, monitors any unhandled exceptions, reports errors, and restarts on failure.
An exception guard on the entry point.
A try-catch-all in the application entry point.
I would recommend either of the first two options; the third option, the try-catch-all, is a particular nasty hack for the lazy and inexperienced programmer (IMHO).
I have successfully used both heartbeat and manager process in a large distributed application.
UPDATE
As for ready-to-go™ restart managers, take a look at the Windows API Codepack as discussed in Emmanuel Istace blog post (http://istacee.wordpress.com/2013/09/21/automatic-recovery-restart-in-net-application/).
You can install the package from https://www.nuget.org/packages/WindowsAPICodePack-Core/