I've made a windows service with a timer (I've seen discussions about timer-driven windows services vs windows task scheduler, and still want to go with my own windows service) that runs some business logic.
To separate my concerns and make it easy to test & run manually, all my business logic is in a separate project that I also reference in a windows forms tester GUI.
Now I want to make another timer-driven windows service in another solution that runs some other business logic, so I'm thinking I don't want to end up with several codebases for my windows service and timer, so I'll reuse them from this solution, and go write my other business logic project.
How does this work? Am I going to end up with the same DLL name for the service project in both solutions? If they run on the same server, that will cause problems. It's such a small piece of code, I almost feel like the service isn't worthwhile as its own project, or isn't worthy of reuse, but I also hate the idea of not reusing it.
Also, I dislike the notion of reusing, say, just one or two .cs files and not the whole project, not only because that seems like it goes against the intentions of .Net, but also because our Mercurial source control makes that cumbersome.
What's the right way to approach this?
Related
Current situation :
Multiple .NET Framework solutions (implementations) that each have :
Core logic library project
Windows Service project (builds as exe)
WPF UI (builds as exe)
Core logic is run on a timer that is kept alive by the Windows Service
Windows Service communicates over WCF to a WPF UI
Desired situation :
Multiple .NET solutions that only include the unique portions of logic that cannot be reusable between implementations
Reuse one common WPF UI
Reuse one common Windows Service by each individual implementation
I am struggling to figure out how one common Windows Service project could be maintained, that could then be consumed by every implementing project (1 (windows service) -> to -> many (implementations).
The main limitation here being that Windows Service needs to build to an exe and have an installer to go with it, so that the service can be added to the registry.
Possibilities I could think of thus far :
Some strange pre-build event process of pulling down pre-built components for the Windows Service from somewhere (GitHub perhaps), adding them to the build directory and using said components in the build of the final installer
Sounds absolutely appalling and a nightmare to maintain to me
Maintain a common .NET project for the Windows Service. Have a rule that any new or existing solutions must 'Add>Existing Project' and point to the common .NET Windows Service project.
Is dependent on humans following a particular workflow each time they create/make changes to a solution, which...I am not a fan of
Is a little counterintuitive and is definitely repetitive and redundant to have the same exact project in each individual solution, despite needing only the build results of said project.
Abandon Windows Service + WCF. Adapt an architecture that more resembles microservices - run the logic that keeps the core logic alive and allows the UI to get updates to it in a docker instance.
Definitely sounds like the 'right' and future-proof way to do this
The most effort to refactor a significant portion of the codebase
Introduces new, unknown and potentially significant problems that using Docker may introduce given the app's highly restricted execution environment (Windows Server with sometimes extremely restrictive privileges)
Is there some method of architecting such an application that I am not aware of/not thinking of?
We are faced with the problem maintaining lots of windows services.
The idea is to reorganize windows services in to class libraries and connect libraries to one master windows service. Is there a good idea ? Any advices please)
There is a framework for hosting "services" within a single Windows Service called TopShelf. You might want to consider using that. https://github.com/Topshelf/Topshelf
I am interpreting your question to be "We have tons of little Windows applications that run as services - how can we simplify them?".
In general, lots of smaller programs are better. Single monolithic applications are difficult to maintain and test; when someone needs to make a small change it can trigger catastrophic consequences for dozens of other components of the application. It can also make it impossible to change one small application without taking down the whole service, as Chris Knight comments above.
On the other hand, lots of small programs suffer from the breadth problem. You probably want to make sure all your little programs run on a consistent framework - i.e. they all log their results to the same place, they all use a standardized configuration system, and they are all managed in the same place.
I have seen situations where people write services because they need to run a task "when a particular condition happens", so they make it a constantly running service and continuously check for that condition. Is it possible that you could take some of your services and turn them into triggered launches of individual applications?
If this isn't the correct interpretation, please let me know :)
I’m currently writing a windows service that’s sole purpose in life is to poll a database and, based on the resulting information, update some other data. I wrote this as a windows service because it seemed an ideal platform. I don’t need any user interaction.
However, while developing it, I’ve noticed one or two issues that make developing a windows service more time consuming that developing a straightforward windows app. Has anyone has any experience with this kind of choice? What is the best practice for this kind of app? Are there any reasons why using a windows service is preferable?
The issues of development imoho are far out weighed by the features that services provide. Remote polling, no need for a user to log on, built in fault recovery and monitoring.
I just made my first service too and noticed they are not quite as easy to debug or test. You can install and start the service then attach the debugger to the process. Or you can run the service as a console app just to test out functionality. Something like this http://tech.einaregilsson.com/2007/08/15/run-windows-service-as-a-console-program/
Whether a service is preferable or not is your call. rerun listed good reasons for services. Based on your description it sounds like a scheduled task of some SQL would accomplish what you want.
To debug a windows service directly under visual studio , Add this Code snippet to your service designer class under Main() .
Shared Sub Main()
#If DEBUG Then
Dim service As New YourServiceClass
service.Execute()
System.Threading.Thread.Sleep(System.Threading.Timeout.Infinite)
#Else
Dim ServicesToRun() As System.ServiceProcess.ServiceBase
'More than one NT Service may run within the same process. To add
'another service to this process, change the following line to
'create a second service object. For example,
ServicesToRun = New System.ServiceProcess.ServiceBase() {New YourServiceClass}
System.ServiceProcess.ServiceBase.Run(ServicesToRun)
#End If
End Sub
This is vb.net code but C# should do the same trick. I have managed several windows services like this without any issues. If debug should be preceded with a hash.
One thing you should be aware of is that a service will not be able to use video hardware acceleration. If you are not doing any graphical work then you can safely ignore the limitation, but if you have graphical-intensive operations (for ex. WPF-related) you have to keep this in mind.
I admit it's not a common scenario, but I've worked on a project where a service rendered WPF controls.
The reason for this is Session0 isolation, described here.
I need to build an application in C# that will have multiple UIs, 2 for web and one that will be the same application, but able to be used with no internet access. I am leaning towards MVC for web, then MVVM/WPF for the windows application (Silverlight is not an option). I should be able to inject a different repository implementation for the two paradigms, thus solving the disconnected-from-the-internet issue.
What I am wondering is how best to re-use as much presentation logic as possible. Ideally, I would like to be able to use the same controller/presenter-type entities to run both UIs. I'm looking for an example of a good solution to this problem. I don't see a clear path to re-using MVC's Controllers (they seem too tighly bound to the MVC framework to work), but at the same time I'm not excited about the overhead involved in implementing a custom MVVM or MVP pattern for the web (which I fear is the answer).
Alternatively, am I crazy to even try to re-use those components? Is it not worth the hassle? We can easily share the services underpinning the UIs, but it seems a shame to write such similar UI code twice.
The right thing to do is to share only the Business Layer and Database Access Layer. At least you will have consistency between all the clients.
Then build the clients taking advantage of the benefits of each platform (richness of the desktop app and simplicity in the web app)
Of course it all depends on the budget.
You have the option of using WPF for everything for max re-use. WPF can be deployed as partial trust XBAPs.
There are downsides though
* Download size can be a problem
* Clients need the correct framework version and can only run in Internet Explorer (Firefox through plugin (not working on Windows 7))
I've tried it on a solution with a small XBAP client and a larger Standalone Application - and it is really minor details that cannot be reused (Window in app, Page in XBAP and so on). Makes for nice consistent layout too.
This is slightly hackish (and not really recommended, unless you really understand what you are doing :)), but you could try creating a desktop app, which embeds a browser. This enables you to reuse the GUI. You will also need to package a web-server, which might be a problem though if you are using C#/MVC/.NET.
I created a Windows Form executable in .NET 3.5 that uses a dll to communicate with a machine that scans checks. I'm eventually going to need to move from an executable to a Web Form that can do the same thing. This will be months from now, but I wanted to start doing the research now as I have not done this before. I'm going to need to use ActiveX in order to communicate with the device via a Web Form. I've also not done this before.
I'd like to keep the functionality of my existing executable without having to rewrite most of it, although I do understand that some of it will need to be rewritten. I've done research on ActiveX and how to use it, but I wanted to know if someone has had a similar situation as this. What did you do to convert an exe to a web program? Are there good, specific sources out there that I'm overlooking that can point me in the right direction for this situation? Is there any advice that you can give from your experiences that can help me to reduce mistakes? The company that I work for does not have anyone else here that has done this before, so I've got to teach myself everything needed to do this.
Thanks in advance.
This is where separation of concerns and n-tier design shine through. Hopefully your UI layer is loosely coupled from your domain model. If this is the case, you can code a second IU layer for the web. And not have to change your domain model at all. Then you can compile for each scenario.
*note - In practical use I have always had to extend my business domain to account for some issues with the second UI, but those modifications have usually been minor, and have pointed out places where I had coupled too tightly anyway.
Another option you may consider is creating a web services layer over your business domain code. And then coding a web application that communicates with your domain model via those web services calls. This may have performance implications, and would not be my preferred method of accomplishing this. Though you may find it more manageable if you don't have a well designed application to start with.
"I'd like to keep the functionality of my existing executable without having to rewrite most of it"
In general if you extract as much logic as possible into its own assembly/dll, you can reuse that from whatever UI framework you want. Just make sure you're not doing anything UI specific in there (throwing up dialog boxes, etc).
Normally, converting winforms to webforms is quite possible, although typically a slow development process. Even if you've got the cleanest domain layer in the world, the fact that objects in your web page are thrown away every time means that a web domain layer is normally written very differently to a desktop domain layer.
However, in your case the device - server communication is going to be extra difficult.
Have you looked at xbap? It's basically a way to deploy WPF applications into a web page. It requires your clients to have the right version of .NET installed, but it's going to be the easiest path for you, especially considering that you can host winforms in WPF...
You may take a look at Silverlight 4,
http://silverlight.net/getstarted/silverlight-4-beta/
It contains many features that ASP.NET Web Forms hasn't.
If your team can accept something like ActiveX, why not Silverlight 4? The only disadvantage is that SL4 is still in Beta.