This may already exist I hope.
I want to create a Windows service that schedules tasks (much like the Windows o e) but it would run C# assembles dynamically from a local folder (schedule rules via a XML file for that task) so I don't have to create a Windows service or console application every time I want some automation code but can build an assembly, upload it to a directory with a XML config for the timing and it will run/ be detected b a folder watcher.
Does this already exist or will I have to build it?
It's probably starting to look like I'm promoting this.... Try Quartz.Net
http://quartznet.sourceforge.net/
Sounds like a job for Windows PowerShell.
I assume you want to automate the invocation of code in any arbitrary .NET assembly, even those for which you don't have the source code, rather than a plug-in approach with a well defined interface. If so you'll be building a generic service that can watch the config file, which itself must contain all of the details on which assemblies to load, which types to instantiate, which properties to set, which methods to call and their arguments, etc. You might perform all of this work via reflection, or Unity and/or XAML may be of help in constructing the objects.
Depending on how sophisticated you want to get, your config file will end up looking very much like C# code, so it may not be as worthwhile an exercise as you think.
Check out the .NET namespace doc at http://www.jamsscheduler.com/doc/DevelopersGuide/Default.html
It's a .NET based commercial job scheduling system but I use the free Developer's Edition.
Related
I have inherited a massive C# application, server (a windows service) and client (windows desktop application).
It's deployed at a variety of customer locations.
I have a list of customer issues and bugs to address, but the logging in the application is woefully inadequate.
A couple of times I've taken to adding new lines of logging in the code, rebuilding the code, sending the customer the new DLLs and asking them to install them manually, but this is a very kludgey way to debugging customer problems.
Is there a way to just tell the VM (the dot net runtime engine) to produce a log file of what objects were instantiated, and which methods were entered and exited ... maybe even line numbers of lines of code that were executed?
That sort of thing would help me incredibly.
No that's not possible to just tell the VM to log things like that. You can however trace everything in your program(method calls etc).
You can use PostSharp to log detailed info on method calls(you don't need this, but this would provide you an automated way to do it in a large project).
There are also some nice alternatives to PostSharp, such as Loom.net and PostCrap.
Your next option is to modify the exe after it's been created to do this type of logging(tracing) by modifying the IL
There is also something like Runtime Flow, but this probably won't fit your requirements due to an unwieldy install.
I have a WCF service accepting requests from our clients.
After analyzing the request I need to generate (compile + link) C++ EXE.
What is the best method to create an C++ EXE from a C# application???
10x
I can only guess what it is you want, but I assume your requirements are something like:
You run a WCF service on a server somewhere.
Upon receiving a certain call, the service must output a (binary) executable, based on the parameters it receives.
C++ should be used as the intermediate language.
Let's look at what you need. The obvious first requirement is a C++ compiler/linker that can be invoked programmatically. On Unix systems, that would be g++, and you can simply shell-out to invoke it; on Windows, g++ is also available (under the name MinGW), but the version is pretty outdated, so you might be better off using Microsoft's command-line C++ compiler.
Obviously, you'll also need to generate C++ source code somewhere; I assume most of the source code is more or less the same for each request, so you probably need some sort of templating system. If it's not too complicated, this can be as simple as running a regex search-and-replace over a bunch of template files; otherwise, you need a proper templating language (XSLT is built into .NET, although the syntax takes some getting used to).
And then the glue to make it work together; I suggest something like this:
Read request and create a suitable data structure (in a format that your template engine can consume)
Pass the data to the template engine, writing the output files to a temporary folder
Invoke the compiler on the temporary location
Read the executable back in, send it to the client
Delete the temporary folder
Since compiling is often a costly operation, consider caching the generated executables (unless they are practically guaranteed to be different every time).
By the way, there is one big caveat: If the client platform is not binary-compatible with the server platform (e.g., the server is running on x64 but the client is x86), the generated executable might not work.
And another one, which is security: By hacking the server, or tricking clients into sending "wrong" requests, an attacker can potentially malicious code through the generated executable; if this application is all but super-trivial, I imagine it's going to be pretty hard to properly secure this thing.
An executable is an executable, and is defined by the abiltity to be executed.
Whatever programming language was, once upon a time, used to write the source code that was fed to a compiler which produced the executable, that no longer matters. An executable looks the same regardless of which language (or languages) you used. (A .NET executable is just an executable with some fairly complex DLL dependencies)
So there is no such thing as a "C++ executable". Perhaps you mean an executable that doesn't depend on the .NET framework?
Or do you simply mean that you have a C++ application that needs to use a WCF service?
Or that you want to rewrite your C# code as C++?
Do you mean you want to compile c# to native machine code? in which case ngen may be some use
http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.80%29.aspx
I have some VBA code that needs to talk to a running c# application.
For what it's worth, the c# application runs as a service, and exposes an interface via .net remoting.
I posted a question regarding a specific problem I'm having already (From VB6 to .net via COM and Remoting...What a mess!) but I think I may have my structure all wrong...
So I'm taking a step back - what's the best way to go about doing this?
One thing that's worth taking into account is that I want to call into the running application - not just call a precompiled DLL...
In the past, one way I accomplished something similar was with Microsoft Message Queueing. Both languages/platforms can read/write to a queue.
In my scenario, we had a legacy Access database that we had to maintain. We wanted to migrate away from it and replace it with a more robust .NET solution. To get real time data out of the current system into the new system, we added VBA code to write data to a message queue. Then we wrote a C# windows service to process that data in the new system.
I'm not entirely sure of what you're doing, so this may not be a fit, but I thought I'd mention it.
I've come up with a solution using my original structure...
That is, the VBA application calls a COM wrapper application that translates all of the types from .Net to COM safe types. This wrapper then calls the main service using .net remoting.
The problem I was having was that the common dlls between the wrapper and the service needed to be in the C:\Program Files\Microsoft Office\Office12 folder (along side msaccess.exe).
While I was using the AssemblyResolve method to provide the dlls at runtime, this wasn't working...So for now I'll just have to have the dlls copied to the folder - a far from elegant solution, but at least the communication is working for now.
Looking for the advantages of loading DLLs dynamically as opposed to letting your application load the DLLs by default.
One advantage is for supporting a plugin architecture.
Suppose for example you want to write a service that performs different types of tasks on a scheduled basis. What those tasks are doing, isn't actually relevant to your core service which is just there to kick them off at the right time. And, it's more than likely you want to add support to do other types of tasks in the future (or another developer might want to). In that scenario, by implementing a plugin approach, it allows you to drop in more (compatible by interface) dlls which can be coded independently of the core service. So, adding in support for a new task does not require a new build/deployment of the whole service. If a particular task needs to change, just that dll needs to be redeployed and then automatically picked up.
It also requires other developers to not be concerned with the service themselves, they just need to know what interface to implement so it can be picked up.
We use this architecture for our processing applications to handle differences that our different customers require. Each DLL has a similar structure and implements the same interface and entry method "Process()". We have an XML file that defines which class to load based on the customer and whether there are more methods besides process that needs to be called. Performance should not be an issue until your transaction count gets very high.
Loading Shared Objects dynamically is the mechanism for allowing plugins ad hoc to running applications. Without plugins a modular application would have to be put together at link-time or compile-time (look at the code of nginx).
Your question is about C#/.NET so in this world dynamic DLL loading requires advanced programming skills. This could compensate all the potential benefits of dynamic DLL loading. You would simply have to write a lot 'low level' code.
In C++/Win32 I often have to load a DLL dynamically when this DLL has some new API function which is not available on older operating systems. In this case I need to ensure the availability of this API at runtime. I cannot just link against this DLL because it will cause application loading errors on legacy operating systems.
As mentioned, you could also have some benefits in a plugin-based environment. In this case you would have more control on your resources if loading DLLs dynamically. Essentially COM is a good example of dynamic DLL handing.
If you only load the DLLs you need then the startuptime of the application should be faster.
Another reason to load DLL's dynamically is for robustness.
It is possible to load a DLL into what is known as an AppDomain. An Appdomain is basically a sand box container that you can put things into (Either portions of DLL's or whole EXEs) to run in isolation, but within your application.
Unless you call into a type contained within an AppDomain, it has no way to interact with your application.
So, if you have a dodgy third party DLL, or a DLL that you don't otherwise have the source code for, you can load it into an AppDomain to keep it isolated from your main application flow.
The end result is that if the third party DLL throws a wobbly, only the appdomain, and not your entire application is affected.
I want to run javascript/Python/Ruby inside my application.
I have an application that creates process automatically based on user's definition. The process is generated in C#. I want to enable advanced users to inject script in predefined locations. Those scripts should be run from the C# process.
For example, the created process will have some activities and in the middle the script should be run and then the process continues as before.
Is there a mechanism to run those scripts from C#?
Basically, you have two problems: how to define point of injections in your generated code, and how to run python / ruby / whatev scripts from there.
Depending on how you generate the process, one possible solution would be to add a function to each possible point of injection. The function would check, whether the user has associated any scripts with given points, and if so, runs the script by invoking IronPython / IronRuby (with optionally given parameters).
Disadvantages include: limited accessibility from the scripts to the created process (basically, only variables passed as parameters could be accessed); as well as implementation limits (IronPython's current version omits several basic system functions).
Look into IronPython and IronRuby -- these will allow you to easily interoperate with C#.
You can compile C# code from within a C# application using the CSharpCodeProvider class.
If the compile succeeds you can run the resulting assembly as returned via the CompiledAssembly property of the CompilerResults class.
Awesome C# scripting language - Script.Net
.NET has a scripting language including runtime engine in PowerShell which can be embedded in any .NET application.
You can compile C# code "on the fly" into an in-memory assembly. I think this is possible with IronPython and IronRuby as well. Look at the CodeDomProvider.CreateProvider method.
If you need to run scripts a lot, or if your process runs for a long time, you might want to load these assemblies into another AppDomain. And unload the AppDomain after you're done with the script. Otherwise you are unable to remove them from memory. This has some consequenses on the other classes in your project, because you have to marshall all calls.
Have you thought about Visual Studio for Applications? I haven't heard much about it since .NET 1.1, but it might be worth a look.
http://msdn.microsoft.com/en-us/library/ms974548.aspx
I've done exactly this just recently - allowed run-time addition of C# scripting.
It's not hard at all, and this article:
http://www.divil.co.uk/net/articles/plugins/scripting.asp
is a very useful summary of the details.
One of Microsoft's solutions to JavaScript in C# is ClearScript,
which uses V8, Chrom browser's JavaScript engine. Check its short FAQtorial for code samples.
It has excellent two-way integration - iterator/enumerator, output parameters, optional parameters, parameter arrays, delegate, task/promise/async/await, bigint, and more.
Apart from that, I think the most distinguishing feature is that it does not depend on Rosyln or Dynamic Language Runtime. This can be good or bad - good because there may be a lot less dependencies (depending on your project's target), bad because you need to bundle the native, platform-dependent V8 dll.
If that is ok, you get to enjoy cutting edge JavaScript / ECMAScript. Everything you get on Chrome, or 98% ES6 as of 2022 Feb, plus several extensions. Speed is as fast as Chrome, obviously, so you get the best of both Google and Microsoft.