We Keep Coding

Combine .NET MVC website and Windows services

I am currently involved in a simple to medium complex IOT project. The main purpose of our application is gathering data from our devices and analyzing that data as well as calculating statistics.
On the server side we run a MVC application. Up until now we used Hangfire to schedule the calculations. Hangfire is an amazing tool for scheduling emails and other simple stuff, for more advanced things it's too slow. The calculations can take up a lot of time and are processor-intensive (we are trying to optimize them though), so we need to call them in a background task, a simple API call won't be enough.
I thought about splitting the application into multiple parts, the website, the core and a windows service.
The problem is, I never tried that before and I have no idea what the best practice is to achieve that kind of thing. I searched for examples and articles, but all I found were suggestions to use Hangfire and/or Quartz.NET.
Does anyone have any resources on what the best practice is to build a MVC application, a Windows service and how they could communicate (probably through a queue)? What is the best practice in such a situation?

Although there may be many different possible ways to connect a site with a windows service, I'd probably chose one of the following two, based on your statements:
Direct communication
One way of letting your site send data to your backend windows service would be to use WCF. The service would expose an endpoint. For simplicity's sake this could be a basicHttpBinding or a netTcpBinding. The choice should be made based on your specific requirements; if the data is small then basicHttp may be "sufficient".
The advantage of this approach is that there's relatively little overhead needed: You'll just have to setup the windows service (which you'll have to do anyway) and open a port for the WCF binding. The site acts as client, the service as server. There's nothing special with it, just because the client being a MVC site. You can take almost any WCF tutorial as a starting point.
Note that instead of WCF you could use another technology like .NET Remoting or even sockets just as well. Personally, I often use WCF because I'm quite used to it, but this choice is pretty opinion based.
Queued communication
If reliability and integrity is crucial for your project, then using a queue might be a good idea. Again: depending on your needs, there may come diffeent products into consideration. If you don't need much monitoring and out-of-the-box management goodies, then even a very simplistic technology like MSMQ may be sufficient.
If your demands to the aforementioned points are more relevant, then maybe you should look for something else. Just recently I got in touch with Service Bus for Windows Server (SBWS). It's the Azure Service Bus's little brother which can be used on premises locally on your windows server. The nice thing about it is, that it comes at no extra charge as it's already licensed with your windows server licence.
As with the first point: MSMQ and SBWS are just two examples. There may be a lot of other products like NServiceBus, ZeroMQ or others usable, you name it.

Non-enterprise uses for WCF?

I'm interested in gaining a better understanding of WCF.
Of course, I can read books and tutorials about it, but it seems that a better way would be to actually come up with some project idea (either open-source or a startup) which would actually benefit from using WCF, and then build it using WCF.
What are your ideas for small-scale projects which might benefit from WCF?

I'm not sure it is really a matter of scale that drives a decision to use WCF. If a learning project is all you are interested in, then take a normal idea for a project, and turn the entire data access layer into WCF calls.
This should give you a fair understanding of all the little nooks and crannies of WCF, and allow you to fail in a controlled manner. That way you can make decisions in the future about when are where it is best to apply a service boundary using WCF.
As was already mentioned, anything to do with the web can benefit tremendously from WCF. Heck, you could build a pure JavaScript and HTML 5 application using WCF without ever touching ASP.Net.

A hosted service that a mobile device (such as a WP7 or iPhone) could connect with to retrieve data

WCF is great for setting up non-ASPX endpoints for Ajax clients. See for example this article. There are many more out there.

Any project involving .NET and communication is likely to benefit from WCF. WCF is the replacement for ASMX web services and for .NET Remoting. There's no one particular type of application that it is suited for. For instance, it's not like it's suitable for Enterprise applications but not for small ones.

WCF data contracts are very easy and handy for storing application configuration, settings and state. Write a library/application to take care of serialisation and editing.

Controlling a service through a separate application

I'm writing a windows service to do some daily processing, and I want to have a user-friendly way to interact with it. I'll just be doing basic things like checking its status and viewing logs, though I may decide I want to throw in a function call or two as well. After doing some research, it sounds like I need a separate application to perform these functions, since the service will run independently of any user that's logged into the host machine. My idea is to have this application interact with the service through some kind of interface, but I'm not sure where to begin.
What would be the simplest way to have an application communicate with a separate service? Would I use COM, WCF, a message queue, or something else entirely? I know there are probably a few ways to do this, so I would love to hear some pros and cons if possible.
Edit: The service and the application will both be running on the same machine.

Use WCF with NetNamedPipeBinding (allows only IPC on the same machine) or .NET Remoting. If you want to do it quickly choose the technology you are more familiar with. If you are not familiar with any of these technologies choose WCF because it is newer one and you will more probably use it again in the future - so exeprience with it will be useful.

Ideally you would create a separate application and use WCF to communicate between your service and this application.
But there is a 'cheaper' way which is to implement your own simple Web server using HttpListener. See http://msdn.microsoft.com/en-us/magazine/cc163879.aspx
This makes it easy to accept a few simple commands and you can send them using any web browser.
For viewing logs why not just tail the log files (using e.g. baretail)?

Skip WCF, and just use plain .NET Remoting. So much easier. Why they call it deprecated, God knows.
Edit: Seeing it runs on the same PC, the transport would be Named Pipes, IIRC WCF supports this too.

What's the right way to communicate between 2 or more .Net applications running on a same computer without using web services?

If my applications run on a same computer or even on different computers in a same LAN and need intense and quick communication, it seems illogical for me to use text-encoded web services and HTTP. I could possibly use IP/TCP/UDP sockets and invent my own protocols, but believe there is a standard way for .Net applications to send/receive object instances (and, maybe, even sharing an object by reference?). Can you tell me what's that standard way? I am only interested in .Net Framework 4 applications and don't need to support legacy frameworks.

You'll want to use Windows Communication Foundation:
http://msdn.microsoft.com/en-us/magazine/cc163647.aspx
Another link on getting started with WCF
Microsoft has chosen this as their preferred method of communication for .net apps. It replaces Remoting and Web Services.
The great thing about it is that you can switch to different protocols with a small amount of work, so if one protocol doesn't work for you, you can change around the configuration to try another one.

Probably either WCF over NetTcp or NetNamedPipe bindings, or else .NET Remoting.

.Net 4 gives you the Memory-mapped File which you may back with the paging file and share between applications by name.

I you want to share objects, then .NET Remoting is probably a good way to achieve that.

In a word: remoting
http://msdn.microsoft.com/en-us/library/kwdt6w2k(VS.71).aspx
If performance is still an issue, TCP (or even UDP depending on requirements) is still your friend.

To be future proof, I would use gRPC, which allows a) local communication between C# apps, b) local communication between apps in various languages and c) communication over network.

Best and Easiest Method for inter-process communication in large project

What is the best and easiest method that can be used for inter-process communication in a very large project?
My requirement is to communicate between a normal Windows Forms Application and Windows Services.
Methods that are easy to maintain and implement are preferred.
Thanks

From the tags I understand that we are talking about .NET. Perhaps you should try Microsoft WCF. It unifies this issue, abstracting specific inter-process (inter-service) communication technology from actual code. So generally you'll design and write the interfaces that your processes will use to talk to each other and then you'll configure a specific communication technology in XML config file. That is, you have rather clear separation between "what do the processes talk about" and "how is this communication implemented specifically".
WCF supports SOAP, TCP\IP communication, MSMQ etc., you processes can be IIS-hosted web-services, usual Windows services, console applications etc. - all this under unified framework. I think, this is exactly what you are looking for.

It really depends on the project as there are a large number of methods.
This may depend on where the different portions of the project run (They could run on different servers, or different technology stacks altogether.).
The most common method is probably web services. Although these come with an overhead, so it may be worth looking at a simple interface API via a DLL.
Whatever you do it should probably be thought about and designed carefully, considering security and performance, and how you will extend or modify it in the future.

Not necessarily the best or the easiest....
In the .NET world try MSMQ or IBM MQ message queue middle ware.
If the communication is mostly 1-way, then consider using WCF services, which are both good and easy if you let the code generators in Visual Studio do most of the work for you.