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 :)
Related
We have a number of small ASP.NET MVC apps. All are basically a bunch of forms which capture data and store them in a SQL Server database, usually which are then loaded through to our datawarehouse and used for reporting.
We are looking to rewrite all the small applications and apply a level of consistency and good practice to each. All the applications are fairly similar and I think from a user perspective it would be better if they seemed to be part of the same large application so we were considering merging them together in some way as part of the re-write.
Our two currently preferred options seem to be:
Create a separate portal application which will be the users point of entry to the apps. This could have 'tiles' on the homepage, one for each of the apps (which would be registered in this parent app) and could link them through to all. In this scenario all the Apps would remain in different projects and be compiled/deployed independently. This seems to have the advantage of keeping the separate so we can make changes to an app and deploy without affecting the others. I could just pull common code out into a class library? One thing that annoys me about this is that the parent app must basically use hard coded links to link to each app.
I looked into using 'areas' in ASP.NET MVC and have all the small apps as different areas in one big project. This seems kindof cleaner in my head as they are all in one place, however it has the disadvantage of requiring the whole app deployed when any of the individual ones are changed, and I have a feeling we will run into trouble after adding a number of apps in to the mix.
We have a SharePoint installation and someone suggested creating the portal type app in SharePoint... This doesn't sound like the best idea to me but am willing to consider if anyone can point out advantages to this method.
Are there any recommendations on the architecture of this? Has anyone completed similar projects in the past and something worked well/not well?
We have 4 developers and we do not expect the apps to change too much once developed (except to fix potential bugs etc.). We will however plan to add new apps to the solution as time goes on.
Thank you
MVC Areas advantage would be allowing code sharing, by refactoring the repeated redundant parts of each app to use the same infrastructure code (security, logging, data access, etc.)
But it will also mean more conflicts when merging the code initially.
Deployment concerns can be mitigated with a continuous deployment tool (there are many in the market) or if you deploy to an Azure WebApp, then deployment slots can give you a zero down time deployment.
This is my first time dabbling in windows services.
I have a service I would like to manage, I would like to be able to connect to this service via a command line / REPL of sorts to avoid the development time of working on a user interface. I was thinking we could communicate much like attaching to an Asterisk daemon or somewhat like connecting to a MySQL server which to me seems like nothing more than a simple custom shell spawned to handle requests. However, I am always concerned about how efficient my code is and would like to keep to common practices. This will be connecting on the same local machine.
My proposed solution:
I believe I can make simple network stream, to create a simple Read - Eval - Print - Loop.
Another option is to use WCF, however my question would then be, how efficient is this as opposed to packet handling?
My question:
What are some standard practices for communicating with or managing services on the local machine?
I'm trying to learn more about service-oriented design, any resources that could help explain common practice models would be much appreciated.
Of course there are so many ways to do this. The way I would recommend is to make sure you use log4net (or some other logging framework) and log the important info. Create the solution with 3 projects, the first will be the "service logic" or the business service, with the second being the windows service wrapper that starts that service, and the third being a console app that does much the same as the windows service only giving you the ability to interact as you wish. The advantage of the console logging appender is that you still get the console output without actually writing to the console... it give good separation.
I will give another option that I have used in the past, but would give with caution. You can selfhost a WCF service inside a windows service. It gives a nice interface that gets away form the messy self rolled TCP server approach. The caution is that if done wrong it can eat up lots of memory and CPU cycles.
I have a client/server application written in C#/.NET 3.5 that I want to do a bit of performance testing on. I've been looking for a generic framework to help me but not had much luck. I would like something that can manage a set of clients and perform random actions for them based on some settings. I would also then like to record some data relating to this to help me work outsome rough thresholds for my system, e.g. I can support n users performing x actions per second.
I would write code specific to my application to perform tasks such as:
Login/logout a client.
Send messages to the server to perform various actions.
Record acknowledgements and other messages from the server.
Measure statistics specific to the system.
I'm hoping the framework will then be able to take a set of parameters to describe a testing scenario such as:
Number of clients logged in at a given time.
Perform a given number of actions per second for each client.
It would then run the scenario, manage and track all of the users and actions and collate all of the data. (This is the boring bit I'm trying to avoid coding myself...) Ideally it would have some general measurements built in, e.g. time between sending a message and receiving a response, but I could code them myself if not.
I don't want to do any profiling of my code; I can always attach a profiler whilst running these tests later on. Instead I want to make some rough conclusions about my system, i.e. how many users can I throw at it before it breaks. (If there is a better term for this than 'performance testing' please let me know... Stress testing maybe?)
I realise I'm not giving very many specifics about the system here. It strikes me as a fairly general situation - I'm sure there are lots of client/server systems out there that people need to do similar tests on. I've found lots of web based frameworks to do similar things but they seem to be pretty web ingrained and don't lend themselves easily to non-HTTP based systems.
Anyone know of anything that might help? My searching hasn't found anything yet. I should point out that I'm stuck with Visual Studio 2008 Professional for the foressable future so if 2010 can do this it's out of bounds for me. I guess it doesn't have to be a .NET framework provided I can still plugin my .NET code fairly easily.
EDIT To be clear my application isn't a website, it's a Windows Forms client application that connects via a custom protocol to a .NET service. I can write code to perform the relevant client actions, I just need a framework to put it in.
The keyword you are looking for is "Distributed testing".
Smart Bear have a product called TestComplete which supports distributed testing. I don't think it can run multiple instances of your client on a single machine though (maybe it can, but I guess it's not a good idea any way since it would impact the performance results).
They also have an open source project called LoadUI, it is built to integrate with SoapUI, however you might be able to hook it up to your own client-test tool. I have no idea how much effort that would cost.
These are the tools I know of, but there are many more distributed testing tools out there. While most are indeed for web-bases testing, they often are extensible enough to simply kick off a different (GUI-based) testing framework (my favorite is QAliber) which runs the tests on your client app.
To my knowledge, such a framework does not currently exist (and it is likely it won't exist because everyones scenarios are so different). Because "Performance" means different things to different people and different projects, you will usually have to roll your own. Thankfully, with the advent of .NET4 and the TPL this has become easier than ever before.
There are three aspects a Performance test needs to cover:
Define "Load"
Measure "Performance"
Evaluate the Results
As you can imagine, both of these are totally lax definitions. Load could be measured in Requests per Second, Logged In Users etc... Performance could be measured in Response Time, Memory Usage... you get the picture.
So your first step is to define a "unit load", that you can easily scale up. For example you could create a ClientUnitLoad class, that simulates a client and periodically performs actions against your service. The TPL makes it easy to scale your ClientUnitLoad (except you are bound by hardware constraints of course).
The next step is to measure Performance. How you measure heavily depends on the metric you want to collect: Simple Stopwatching is fine 90% of the cases but can only measure time. Building a custom tracing and metrics collection infrastructure is definitely worth it, as you will also need it in production to verify your system performs as expected in the real world.
The last step is to evaluate your Metrics. The largest issue with Performance Tests is that: a) they are slow, and b) unreliable. Theres no way around that. In general, you need large sample sizes (repeated test runs) and some sort of statistical analysis on your metrics to ignore outliers. The processed results should then be compared to a configurable performance baseline.
Depending on the desired level of sophistication, that performance baseline may have simple acceptance criteria (such as: Repsonse Time under 100ms) or advanced, specific criteria (such as: Repsonse Time does not decrease by more than 10% when the amount of logged in users is 10 vs. 1).
I've not tried it myself but this may be suitable for your needs.
https://browsermob.com/performance-testing
Can't really say if there is a testing framework for such a specific purpose, but maybe you could use a simple console application (since the main idea is to test server performance)? You could make multiple calls to the server in different threads and use, for example, Stopwatch class to measure response times.
Or, you could try overloading the service by just increasing the number of calls (likely the service will slow down before threadpool runs out of threads?).
Kindly check at the following link.This may help you.
http://msdn.microsoft.com/en-us/library/aa337591.aspx
I guess you will get the feature even in VS2008 but for ultimate edition.
http://blog.maartenballiauw.be/post/2008/02/code-performance-analysis-in-visual-studio-2008.aspx
Available in Developer and Team-based Visual Studio 2008. I think the feature has been improved in Visual Studio 2010 though.
I should clarify - this doesn't provide support for all the test cases you want to run. You would have to write that logic yourself in a separate project, set that as the startup project, then run the Performance Analysis.
I've done some performance tests a while ago in a client/server application using Microsoft Visual Studio Load Test
When you add unit tests to a load test, you exercise the performance
of non-Web based server components
You have to code your load generators as "Visual Studio Unit Tests", so that later you can add them into the Load Test project.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I want to create a small helpdesk ticket control system at work, that would allow users to enter a help request ticket; these tickets would then be assigned to a technician to work on, and the technician would mark it as "FINISHED" after the job is done. The requesting user would then be able to confirm and "CLOSE" the ticket, so that a Help Desk supervisor can keep track of response times and other stats based on the ticket details. Nothing too complicated, using .NET and SQL Server.
I am not sure if I should develop this as a Web application or a Windows application. This application would be used in the plant floor, so it would have to be easily available in the LAN. But we currently host a list of Windows applications via Citrix, so deployment would not really be an issue here. I don't really have experience creating winapps from scratch (though I've modified quite a few), but it feels like a web application would not look as "solid".
What advice can readers provide that could guide me into deciding the better architecture for this purpose?
EDIT
Thank you all for your thoughts! Given that this is a very simple application, I could go either way. I decided to go with a Web application, as our local Citrix setup still has some quirks that need to be fixed.
If you develop a web app you can pop it on your local intranet and your users can use either their browser within Citrix, or via the browser on their terminal.
However, if you've got the infrastructure in place, then perhaps a Windows application would be easier to develop and deploy. The only limitation with a windows application would be that if you were to move away from a Citrix environment, or were to expand to wanting to use the system externally to the plant floor, then it's harder to deploy and maintain your installations.
You can use Web Deployment with Windows applications which is quite nice as it updates itself whenever you publish a new version, however it is a bit of a faf for the users and you've no guarantees that the user will allow the update to occur. So if you had a critical update, the users could, in effect, choose to ignore it.
That's where the web application gets its bonus points. One installation and one point of access. If you update it, then all users are instantly on the latest version.
Personally, I'd go with the web application for future proofing and ease of acccess. It's slightly more work than a windows application, but the payoff usually exceeds the extra time required for the web application.
Before writing this system, I would highly recommend searching www.codeplex.com and making sure that adapting another work isn't a better choice. You may find something that is already written and meets your needs while allowing you to dig around, learn and be ready to modify when they want some new feature not already present. (I believe all projects grow if the users believe in the developer.)
If you are going to write your own and can do it in the time you have, I would highly recommend that you either go with MVC if web based, or WPF (using MVVM) if you want a desktop client. There is a definitive learning curve to either MVC or WPF with MVVM. But I believe the payoff will come. I have found changes much easier when there is a clear line between business logic and visual behavior.
Personally, in this situation I would go for a windows application - as it doesn't sound as though you've any compelling reason to invoke the complexity of web-ness (perhaps it's just me that thinks web => additional complexity). I'm sure you could create a neat little windows app. in half the time it would take to create a clunky web version of the same thing!
As a sidenote:
I really like the way Eclipse Mylyn integrates with XML-RPC. Check this architecture out for inspiration:
http://www.eclipse.org/mylyn/
If you went for a similar strategy you might start off with a simple front end (Maybe as a C# with a native GUI and augment with a web-based integration with your intranet at a later point whichever is the fastest for you to do).
In esscente a 3-tier approach where you have:
The database.
The application layer wich implements an XML communication protocol (XML-RPC is quite simple).
A front end where information fields and workflow steps are 'introspected' rather than hardcoded in the client.
Just a though, hope it helps.
Write a winform app, and distribute it over ClickOnce. It's the best way to go, IMO.
Don't rush to make this decision. In the end, the Web vs Win question is about user accessibility. Much of the processing logic for your business need is independent of the interface. Spend your up front time building the right data model and identifying the necessary processing/services that you need. A well designed DB and service layer will work with both Web and Win apps. This will also give you the best flexibility as your "product" inevitably grows. You may very well want a web interface for managers needing reporting functionality and a WinForms application if you need more advanced user processing abilities for your users. And that is when your initial design work will payoff.
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.