We're building a C# application that allows loading custom plugin DLLs and executing them.
Each DLL contains some task, and we'd like that task to be transparently executed either locally or on some remote server.
I have examined various solutions for this, and so far the best solution that was proposed was to use WCF.
I'd like to understand, since i'm currently only through basic tutorials of WCF, if it is at all possible to dynamically deploy new code using WCF to be executed remotely?
The way i see it, i have 2 different scenarios:
Remote machine has a base "execution" library deployed.
Remote machine has no WCF service installed on it currently.
With option #1, i guess i could have some functionality to send across the DLL or something, and execute it remotely, since the execution library knows how to do that already.
With option #2, i would need to basically deploy everything (somehow) from scratch, and then send a command to run it.
Is this scenario possible at all? do you have any tips to perform this kind of task?
Also, if you have any good WCF tutorials (i'm currently reading up on MSDN).
Thanks!
The important thing to remember here is that WCF can be used to transfer data, but not to tranfer execution logic. You can send the result of an addition from one end to the other, but you cannot send some arbitary instruction (like adding or whatever) and let the other end magically execute it.
In other words, if you have a WCF client on the remote end, you could send it your DLL file (as a binary data), and the client could then dynamically load and execute it using reflection (but what's without mentioning all the obvious security and compatibility concerns this would raise).
Another maybe easier option would be to send scripts instead of compiled code, and execute them with some interpreter on the server side. But whatever trick you use, you'll need to do a lot of work outside of WCF as sending instructions is not the objective of WCF.
Related
Background:
I have an old vb6 application that I really need to get out of my life. I love coding in c# and want to make an application to replace the old vb6 application.
The vb6 app has a component app that is installed via IIS and that the main GUI vb6 app connects to for various purposes. The reason the COM app/components exist are so that everything done is coming from the same source.
Ex: I'm working remotely and need to connect to an FTP server that is only accessible from my works network. The main GUI app connects to the COM object, issues a command and then that set of components creates the FTP connection from my work network/ip (instead of my home network/ip).
Question:
In replacing this old application GUI and COM object, what is the best approach in c#? Should I still use the old Component Services that I hate so much? Or is there a newer, better way of going about this same task?
There is nothing special about using FTP that would require COM (and certainly writing a GUI in C# does not require COM either).
If I were doing it:
WPF GUI (Future proof for when WinForms is gone... and gives you a leg up with WinRT which also supports XAML).
Nuget in an FTP library, like this one: https://www.nuget.org/packages/Ftp.dll/
Make sure you separate your GUI from your back-end communications through appropriate interfaces/patterns so you can replace things easily and more "future-proof" your application.
Edit:
So, what you're really after is: How can I have a GUI front end that talks to a back end via various means?
So, there's lots of answers to that, and it basically boils down to, either: don't do that, "pick a lane and stick to it", or "Use WCF".
WCF (Windows Communication Framework https://learn.microsoft.com/en-us/dotnet/framework/wcf/whats-wcf ) is a back-end server side technology that supports multiple communication protocols simultaneously, but generally allows you to interact between client and server. SOAP was originally the popular choice, but it also supports Remoting (which you alluded to), you can send attachments via DIME which is then like FTP, or you can roll-your-own and do anything you want (e.g. using Capn Proto (https://capnproto.org/) to send binary messages).
Alternately, if you can get away from trying to do everything, you may want to look into REST instead which is supported by Web API (https://msdn.microsoft.com/en-us/library/dn448365(v=vs.118).aspx ). This will allow you to send lightweight data back and forth, and is, typically, "the way it's done" these days.
Good luck!
I have a C# library that interacts with webservers. (Specifically, it implements various means of binding local data to a remote source). All the webserver needs to do is return simple strings to simple HTTP requests. (Later, I'll add handling web sockets)
I would like to have a self-sufficient test suite for this library; so it seemed to me that a reasonable way to do this was to implement a simple C# web server (which so far seems delightfully simple). Tests could then start up a thread with the server, then run against it, and then shut down the server thread.
However, I'm running into difficulty. Is there a better way / more canonical to do this?
Note: Complex solutions are not going to be better.
Note2: Wrapping Web services in wrappers and stubbing those would defeat much of the purpose of the library in the first place.
There are other ways of creating simple web servers.
I use Node.js to create Mock web servers for testing things like C# web clients. Python is another option.
If you like to stay with C# here's another simple solution, this can be adapted:
https://codehosting.net/blog/BlogEngine/post/Simple-C-Web-Server
I'm writing a REST API that encapsulates some common Windows management tasks, (DNS/DHCP management, terminal sessions, etc.). I don't want to use PowerShell Web Services, as I don't want OData in my API. I'm trying to figure out what's the most efficient way to execute remote management commands on the back end.
As far as I can tell, the options are:
WMI over RPC, using System.Management. There's also Microsoft.Management.Infrastructure, but it seems to be locked to Windows 8/2012 R2 and above, which doesn't work for me. Obviously this isn't the most firewall friendly, and is probably considered legacy by MS, but is probably the fastest protocol.
WMI over WSMAN, using an approach like How to access WinRM in C#. This is more in line with MS's current thinking from a protocol perspective, but XML parsing could be painful with more complex return sets.
PowerShell Remoting, this probably results in the most readable code (after the Powershell session is created), and you wind up with some sort of (generic) objects but this seems like the slowest method, because of the time it takes to spin up the PowerShell session.
Am I missing anything? Am I going a step backwards by using System.Management?
I am creating a windows application in dotnet framework 4.5. The architecture involves a connection between Application and Central Server where it communicates to central server and sends data in case of a crash (a crash report is submitted). Also it downloads data from the server.
It's basically a two tier application. I am not sure which method will be best for the communication between these two as per the industry standards as well as acceptable to anti-virus applications.
So far, I have known about Socket communication as well as WCF but not sure if there are other methods or which one is better as per the requirements.
Please help.
Thanks!
Depends on the needs that you have, a web-service is always a good option, since it is very friendly for the network because it usually works in port 80 or 8080 and it has fail-safe mechanisms like exception handling which could make your job allot easier. If you use sockets, you might have problems, since the "network guys" will need to create rules for your application to work, and you still need to handle "manually" all of the connection problems.
I guess it depends on your needs, maybe give some more information so that you can get a more specific answer. In my opinion, I would say to go with the web-service since it is able to send binary data through the network in a safe way and it's more "scallable" (not sure if I translated this word correctly).
You can use both option with the WCF, but maybe you are looking for some other option? Is there any specific needs?
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.