I'm doing my first steps on Microsoft IoT on a Raspberry pi 3.
I was able to deploy and run the application.
However, I need to run two application, one is going to write a file with events, and the other is going to pick up the batch and send it to Azure.
I was wondering what file location/ path should I use, as the App path changes with every new build.
Should I develop as a single app instead?
Kind Regards,
Juan
Not sure if it fits your scenario, but sounds like the purpose of a second app is to pick up some parameters and send to Azure. So, maybe it's time to consider using App Service.
In general, App service is a background task that runs in the backgound, with on-time event triggers. You can pass in parameters when your app triggers the service, and gets return data when necessary.
If hope it helps.
Related
I have created a C# console application that needs to run once every month. The company i work at uses Azure, so I wanted to use a Azure service to run the application. But I have a hard time finding the right service for the job. I have looked at Logic apps, but is unsure if that is the right solution.
Does anyone know a Azure service which is able to run a C# console application once every month?
Not sure how complex your console app is, I guess it just starts and does a simple task. This is what Function Apps are for. They consist of a single function that can be run on schedule, or triggered by a system event.
Here is MS Docu on how to run it on schedule: https://learn.microsoft.com/en-us/azure/azure-functions/functions-create-scheduled-function
It does not answer your question directly (how to run a console app), but if you are asking about Azure, I'd say it's a good Azure way to achieve what you want, and is not very far from a pure console app. Azure will care about launching it and the environment.
Function Apps can also be tested locally run like a cosole app.
You can use Azure Automation Account for these needs.
It also allows you to run scheduled tasks directly on premisses.
Function app is definitely a better and more flexible solution.
You can use Function apps to run a console application (any exe for that matter).
Please check this code sample. It uses an HTTP trigger to kick off the execution but in your case you could use a Timer trigger.
If you want to skip the process of downloading the binary from an external location, you could even copy the exe file to your function app folder. The steps are here
I have to make a program that watches a location on a computer for files and then converts them when new files get put into a specific folder.
Now my question is what kind of Project would be most appropriate for this?
Is ASP.NET MVC Web Application a good choice or would I be better of doing a Windows Service or WCF Service or even Console App?
My app needs to run on the same server as another MVC app already runs, and I need to access some database to keep track of what files I have converted.
You could utilize Windows task scheduler to periodically run an exe file. In this case the project would be a console app.
A better solution would be to use Windows service. See comments from David & as.if.i.code (tnx btw, you learn something new every day :)
I have a Azure process that stores some .png files in Azure File storage or Blob storage every 2 hrs. I want to create a service which will run from my machine and pull the latest files every 2 hrs . Please suggest if we can do this by Windows service or if there is any other better solution to Automate this.
Please suggest if we can do this by Windows service or if there is any
other better solution to Automate this.
Yes, you could do it with windows service ,this is the official doc, it also shows how to add Timer Event then you could handle Azure-Storage like normal program.
Or you could choose to use console app, this also could satisfy your requirement. You could use a Timer to handle Azure-Storage , however you need to keep this app running all the time.
If you still have questions, please let me know.
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.
I have created a message Queue here which is basically on a single thread and sending email one after another from the database. First I thought that since it is a continuous process, it has to be on windows service and it sounded like an ideal solution but not that I talked to my manager, he said that it would be better if it is in the same repository as the entire project and if I put in a while(true) statement. that way while deploying to the production, we do not need to worry about installing any windows service or anything. But what I think here is that if we do it that way then there would be a lot of unwanted pressure on the web server.
I am not sure which way to go. Any suggestions?
I would definitely suggest a windows service for processing the email queue in the background. Here are some points you can suggest to your manager:
The service could be kept in the same repository as another project.
Installing and upgrading services is very easy. Use installutil and add a batch file to your project for installing/uninstalling. Upgrading is a matter of stopping the service, updating the service .exe, and starting the service again.
All of this could technically be automated as well as part of your deployment process.
I'd go with a separate Windows service. With this service being party of your application, its life time is dependant on the life time of the application pool process (depending on the version of the IIS you are using, of course), and this way whenever youll choose to change the application pool settings, you will have to remember ur message job is also dependant on it, and if you set up any recycle settings for the app pool, you might have hard time uynderstanding why your job suddenly stop working or anything like that.
You can also go the route of simply writing a command line application and then wrapping it with something like Service+ to make it behave like a service. You also get other features like being able to run it like a command line application if you like (whenever you want to run it) or having it launch/execute from some other application as needed. You can build in a variety of behaviors as well... continuous mode, perhaps process 1 (or 100 or whatever) at a time then exit (and let Service+ restart it), or whatever else you may need.