I have a couple of questions regarding a project I recently started working on. This project requires me to discover devices on the network (broadcasting UDP packets on a specific port), store device information into a database, and then display all the data on a local web page. My questions are:
Can I have a C# program that runs in the background that deals with the device discovery and database management while also running a local webpage for users to interact with?
If so, which kind of Visual Studio project would be the best to
implement this project?
If not, how else could I do this?
We had a problem where we needed a long running process that was initiated by a user but which timed out. We resolved this by running a background Windows service which interacted with the database backing the website. We also have other tasks that we wish to run asynchronously following user action. We run three Windows services on the web server; this solution has been running successfully for a number of years. So, in answer to our specific points:
Yes, as a Windows service separate from your website project
There is a specific project type for this; you will also need to set up an installation project
There may be other ways but I would recommend this approach
Related
Our company uses a system of which I am the sole developer. It is a C# based desktop application that is run on some 50 workstations or so and all connect to one central SQL Server database.
Our network administrator is now looking at presenting the application through Terminal Services, something that I know nothing about, yet.
As I started Googling around I saw that, apparently, some applications do not work under Terminal Services. MS Paint is mentioned as an example. So this got me wondering, what does a developer need to know to make sure that his/her application works in Terminal Services?
I don't have the time right now to investigate TS in depth but I'm hoping there might be an article somewhere that is written for developers. As in "Things not to do when you develop an application that will be run in Terminal Services".
Terminal Service RemoteApp works pretty well if you application is designed to be multi-user compatible. so you will need to ensure user session related data is not shared, but placed in isolated storage with IsolatedStorageContainment set to DomainIsolationByUser for example.
here are some useful links:
http://www.fmsinc.com/microsoftaccess/terminal-services/remoteapp.htm
https://www.youtube.com/watch?v=Nf20-76dMcg
https://msdn.microsoft.com/en-us/library/3ak841sy%28v=vs.110%29.aspx
I’m working on a windows app composed of two parts:
An agent, running in the background.
A main application with a window to start/stop the agent and configure it.
What I understand is that I should use a “windows service” for the agent.
But I’m not sure how this is supposed to be packaged? (Can I have these two parts in the same .exe?)
And how the agent and the main application can communicate (should I use a shared file? Can my agent have a private folder to work in?)
I’m looking for some architecture advices basically
Running the agent as a service is probably the best way to go. It'll run without anyone needing to be logged in to run it, and Windows provides extensive monitoring support for services. You can use the sc command to install, start and stop a service, and it even supports controlling services on other machines if you've got the appropriate permissions.
In order to have your gui communicate with it you could look at using WCF. It will allow you to define your interactions with the service as C# classes and will save you having to worry about checking shared directories or looking into a shared file etc. This approach will also make it easy to support multiple clients at the same time, whilst something like a shared folder approach will make this difficult.
You will need to have to separate .exe files, one for the service and one for the windows application. You can package these are two separate MSIs within Visual Studio, the benefit here is that if you need to move the service (for whatever reason) you are not then also packaging up the Windows App and leaving it where ever you install the service.
There are different ways you can have them communicate without getting massively complex. you could read from a text file, as you've suggested, but this could cause locking problems. When I've had to do similar I created a simple database in SQL (or any brand of database you wish), and have the Windows App insert / update configuration options to a table, and the service then reads the table to get its settings.
This isn't exactly a code question as much as it is an advice question. I currently working on a program for a small business. This program does a multitude of things from updating their local access database, edits and updates Word and Excel docs, etc. Now I have the WPF/C# based program running on a Windows 8 computer but they would like to be able to run it from multiple computers. My first instinct was to make the project again as a WPF Browser application. My questions is how would one set something like that up? Would I have to dedicate a computer with special software to handle just this program, the database, and their documents? Any Suggestions or tips would be greatly appreciated.
It doesn't have to be a WPF Browser App to run on multiple PCs. I suggest using Click Once deployment, where all users automatically get the latest version from a shared folder on an office server or just one of the other PCs in the office.
If they want all of these instances of your application to connect to a common data source or sources, then you will need one computer that hosts the server application and its database (you'll now have 2 projects: the server application, which might run as a Windows Service and have no UI, and the client application, which is the WPF app).
This computer be an existing Windows server in the office or it can even be just one of the PCs in the office, but that PC must be kept on for others to use the app and if anyone reboots it in the middle of the day others could lose some of the data they were updating.
Fundamentally, you need to alter the WPF application so that it fetches and sends its data from/to the "server," most likely using WCF services.
It is a lot to digest, but in incremental steps you can get there. The biggest hurdle will be getting your first successful WCF communication between server and client. Once you cross that threshold you'll be well on your way!
I am creating a website in asp.net but i have some issue..
I have coded a program which can crawl a give web page i.e. thenextweb.com for its links, and content and images.
Now i want to store these crawled data inside my table *Crawlr_Data*.
I want that the crawler runs after every 30 minutes and updated the table with new links if available.
{ON the Home page of my website i am showing the information stored in the database}
How can i run the crawler on back end and update the database ?
What technology like (web services, WCF) should i use or any other thing in visual studio which i can use so that i if host website online its crawler keeps on running and updating table}
Please suggest
Thanks
There are two ways to do this with the Microsoft stack.
Create a service to run on the server. Have the service itself manage when it wakes up and crawls.
Create a console app to do the crawl. Run the console app as a scheduled task using windows task scheduler as often as you like.
I guess there are other ways to do it -- so saying there are just two is not totally accurate -- there are 3rd party programs that will do it for you also... I expect most if not all of them are implemented as a service. You could also write a program that runs on the server not as a console app or as a service. But this is generally a bad idea.
I have spent days trying to solve this problem and still stuck with this and I have posted some questions already on this website, but didn't get satisfactory answers. I am trying to be more clear this time and hope to get a better answer. I have gone through this article already http://blogs.msdn.com/b/michen/archive/2007/03/22/running-ssis-package-programmatically.aspx
and here are my issues (I need to run the SSIS package from ASP.NET)
option 1 is not suitable for me, because it may recycle worker process if it consumes memory
option 2 is also not suitable because of security issues in creating a new process and passing the context to new process looks very complicated for me (according to the support article)
option 3 is not suitable because using SQL Server Agent to run SSIS package is not allowed by the company I am working for(I guesss it requires installation of db engine on application server, not sure). but SSIS is installed on the application server.
option 4&5 will have the same issues as options 1&2.
I guess the only option left now is to create a windows service and start the service from ASP.NET. but will this allow running multiple packages in parallel? OR is there a better alternate solution for this? please let me know. Thanks.
I have built something like this in the past with
a windows service that monitors a database table
an asp.net page that inserts jobs in the database table
each job is a (set of) ssis package(s)
the windows service is configured at startup with a number of threads in a pool
each time the windows service sees a new job, it checks if there is a thread available and launches the thread with the job to be run with dtexec.exe using System.Diagnostics.Process (you can use the SSIS class libraries, but I found dtexec.exe more useful
the thread (and the job) runs in the security context of the windows service, thus using the windows credentials used by the windows service
when a job is finished, the windows service updates the database table
You could change this to do without the table, and expose a wcf service from the windows service with asynch methods that return when the job is finished. I'm not sure how to use multiple threads in that case, but I think by making it asynch you also make it inherently multi-threaded.
You are on the right track with the windows service.
Instead of running the SSIS package from asp.net, get asp.net to place an entry in a queue or a list. Then get the windows service to monitor the list.
When the windows service sees that a new item is in the list it runs the SSIS package that the list item refers to.
The benefit of this is that the web page does not have to wait while the SSIS package runs.