I'm building an extensible service application for my work, and the way it 'extends' is by loading DLL's and executing methods within. It is designed this way so that I do not need to recompile and re-deploy every time we have a new job for it to do. Currently, the service loads a DLL using Assembly.LoadFrom() and then it registers the assembly with the service. In the registration, a Func<object, bool> is passed that dictates the entry point for the new job.
My question is would it be better if I created the instance every time I needed to run the task via something similar to this:
IRunable run = (IRunable)asm.CreateInstance(t.FullName, true);
run.Run();
or would it be better to do it the way I am currently, where I store the Func<> in a class that is called based of a timer?
Timer!
If the performance might stuck because of it (i always had this problem in c#) u can still change it, but a timer gives you more controll over the programm itself...
But implementing a buffer should also just work fine
Related
Over the months, I've developed a personal tool that I'm using to compile C# 3.5 Xaml projects online. Basically, I'm compiling with the CodeDom compiler. I'm thinking about making it public, but the problem is that it is -very-very- easy to do anything on the server with this tool.
The reason I want to protect my server is because there's a 'Run' button to test and debug the app (in screenshot mode).
Is this possible to run an app in a sandbox - in other words, limiting memory access, hard drive access and BIOS access - without having to run it in a VM? Or should I just analyze every code, or 'disable' the Run mode?
Spin up an AppDomain, load assemblies in it, look for an interface you control, Activate up the implementing type, call your method. Just don't let any instances cross that AppDomain barrier (including exceptions!) that you don't 100% control.
Controlling the security policies for your external-code AppDomain is a bit much for a single answer, but you can check this link on MSDN or just search for "code access security msdn" to get details about how to secure this domain.
Edit: There are exceptions you cannot stop, so it is important to watch for them and record in some manner the assemblies that caused the exception so you will not load them again.
Also, it is always better to inject into this second AppDomain a type that you will then use to do all loading and execution. That way you are ensured that no type (that won't bring down your entire application) will cross any AppDomain boundary. I've found it is useful to define a type that extends MarshalByRefObject that you call methods on that executes insecure code in the second AppDomain. It should never return an unsealed type that isn't marked Serializable across the boundary, either as a method parameter or as a return type. As long as you can accomplish this you are 90% of the way there.
Ok so I have a C# program which handles some scheduled tasks. However I need to be able to call a specific function within this program from windows task scheduler.
I have no code or no starting points because frankly I don't even know the proper terminology to put into a google search... its like I am trying to search for "ferrari" by typing in "things with disk shaped objects mounted on the sides". I just have no idea where to even start. I need someone to just give me a quick brief on where I should be looking to accomplish this task. Once I know where to look I can figure it out.
Heres what I need to do.
I have a c# winforms application that has several functions inside of it (lets say method_1, method_2, and method_3). I want to create a windows scheduled task that runs just method_2. I was imagining some sort of launch parameter like you can put in the "target" line of shortcuts like "chrome.exe /d" or whatever.
Thoughts? I am probably over thinking things honestly, but some simple suggestions would be nice.
It's a little unusual to have a windows scheduled task executing a winforms app... scheduled tasks are more commonly used to execute background tasks/services. It's a little hard to give you further advice without knowing more about what you're trying to do.
Usually, you'd move the common logic to its own assembly and compile it as a Class Library.
Then you'd have your WinForms project reference the shared class library, a third project for your scheduled task that also uses the class library.
But if want to send parameters to your WinForms app, you could change your Program.Main signature from this:
static void Main()
to this:
static void Main(string[] args)
The args array will contain the arguments passed to your application. You can interpret these and call the appropriate method.
In addition to dcastro I like to add that you could also create a library and create several dedicated executables to call specific functions inside this library
Then also use this library from your winforms app.
Projects in your solution:
library.dll with all the shared methods
Task1.exe: Exe to be called from the scheduled Task. (References library.dll)
WinFormApp.exe: Your gui (References library.dll)
I need to create an application that will run on a server and be able to be configured to run commands at certain times. For instance, there will be a web interface allowing a user to set an engage time and a disengage time. Once those values have been saved by the user I need for the server to be able to fire off those commands precisely at the time specified each day.
I would also need to be able to set single use non recurring events that would occur... maybe 10 minutes from the time an event was triggered and have a command fired off when that 10 minute timer goes off.
I've already got a class library written that has the engage and disengage commands exposed. I would hope to be able to integrate this into whatever solution I end up with and simply be able to make calls directly to the class. Alternatively I could also compile the class library into an executable and have commands issued to it via command line. I'm hoping to not have to do the latter.
I've never written anything like this before. I've peeked a bit at Windows Services, but there is a lot of chatter out there saying that it isn't necessarily the best option. Can someone please guide me in the right direction please?
A windows service is not a bad idea, its perfect for this kind of application. Unless you end up using standard windows scheduled tasks as the trigger for your command, you need some sort of process that is always running to contain your scheduler. A windows service is an excellent candidate for this.
Using a windows service in conjunction with Quartz.NET and some sort of persistence layer so you can store your schedules (in case you need to restart the service or it crashes etc) would be a good way to go.
Alternatively, you could write an application that just adds and removes windows scheduled tasks, but considering you have existing class libraries, using Quartz.NET will fit in well with your existing libraries.
easiest solution:
make a console exe and run under scheduled task in windows.
Let web page to accept user input and modify a configuration file.
The problem (and some unnecessary information): I am creating a chat bot in C# (not chatterbot), and want users to be able to run custom code on the bot. Basically, you send a string message over the network, and the bot runs the code contained in it.
I have looked into and actually implemented/used CSharpCodeProvider, however, this has the problem of every time custom code is compiled, it adds another Assembly to the AppDomain (which is impossible to remove). When you take into account that tens or hundreds of separate custom code invokes may occur in a single lifetime, this becomes a problem.
My idea is that there might be a interpreted language or some such thing that is able to be invoked from C#.
You can remove an assembly if you remove the entire appdomain. So you could create a fresh appdomain, load the assembly there (or compile it from there) and dispose of it after use.
You could recycle the appdomain every 100 statements or so in order to amortize the (small) time it takes to cycle one.
Context: I have a set of View/Presenters and I've noticed that for complex views I get some performance issues at the time of the InitializeComponent() call
Is there any way to instruct the spring container to pre-instantiate objects scoped as prototype? Something similar to a queue with the objects ready when the application requests them?
We had exactly the same problem. We also found that this performance overhead occured only the first time we requested a form from the container. We didn't find a clean solution, so we decided to write an initialization routine that runs in the background and requests all objects of type Form from the container. When this routine is finished, all forms open quickly.
Looking forward to a better sution, but this worked for us. Main disadvantage of this workaround is, that during the initialization routine, users might still experience some slow loading forms.