-3

What I need is to start a new process from a .dll, that resides in the /lib folder... well, I have a Console Application project in my solution, that I want to generate desired .dll from.

When I let the output type of this particular project set as Console Application, it generates an .exe file. When I then rename that .exe file to .dll, I am able to start a new process from it. But when I change output type of that project to Class Library in Visual Studio, it delivers .dll, but I can not start a new process from that .dll anymore (see code below).

I do not want to do the rename manually and I do not want to use any post-build events/actions either. Furthermore, keeping .exe generated would be fine, unless we strictly need the users not to be able to simply double-click that .exe and let it do, what it is designed for, because the consequences could be brutal.

So, does anyone please know some nice solution to this problem? Every suggestion is warmly velcome, tips on what and how to set in Visual Studio and / or what to change in my code to do the tricks - but I can not make any significant changes to project and solution structure, still, every information welcome. Thanks.

Using Visual Studio 2012 and solution is all set to use .NET 4

So how I call the new process:

ProcessStartInfo psi = new ProcessStartInfo();
psi.UseShellExecute = false;
psi.ErrorDialog = false;
psi.RedirectStandardError = false;
psi.RedirectStandardOutput = false;
psi.RedirectStandardInput = false;
psi.CreateNoWindow = true;
psi.FileName = @"SomeAssembly.dll";
psi.Arguments = @"";

Process process = new Process();   //only works when SomeAssembly.dll is a renamed .exe
process.StartInfo = psi;
process.Start();

EDIT: I feel the need to tell, that this specific project might in future not only be run from the application as a new process, but could be loaded in-memory and run using the EntryPoint.Invoke method or just partially, creating some of it's Objects the same way using reflection. So yes, the .DLL assembly needs to have an EntryPoint whereas still being a .DLL ... feel free to ask for further info, will happily provide.

jmodrak
  • 229
  • 4
  • 17
  • 2
    So... Why exactly can't this be a Console Application? DLLs aren't executable applications, by design. If this *needs* to be a Class Library then why not write an executable Console Application which just references this Class Library and invokes the logic therein? – David Jun 24 '14 at 13:46
  • DLLs are assemblies as well as .EXEs are, so they can have EntryPoint as well. That way you can load DLLs and execute them like this way under AppDomain assembly.EntryPoint.Invoke(null,Args); – jmodrak Jun 24 '14 at 13:48
  • And I only want this .DLLs to be executed from the Application, never by user by hand, I can not get what is so difficult to understand on this constraints. – jmodrak Jun 24 '14 at 13:49
  • 1
    What's difficult to understand is your attempt to simultaneously make something both executable and not executable. Those are mutually exclusive states. If you want something to be secured, you either need control over the permissions on the user's workstation or you need to keep the code server-side (which you control) and have the client-side application make service requests to it, from which you can determine authorization based on whatever criteria you use to determine that. – David Jun 24 '14 at 13:53
  • @David close enough, but still, I got this working fine, when it is a renamed .EXE, so I just want to explore, whether there is any neat and elegant solution to have this working the way it is. I do not get the negative harsh, there is when I only try to discover possibilities, or whether there are any. Still thanks. – jmodrak Jun 24 '14 at 13:57
  • Carefully read the comments. The only negativity here is coming from you. You asked a reasonable question, albeit an odd one and without a lot of background information. We've made some suggestions, as well as asked why this is such an issue in the first place (that background information). Upon being questioned, you've responded with a lot of negativity. If you don't want anybody to engage in conversation about your issue or try to help create a meaningful solution to the overall problem, why are you here? – David Jun 24 '14 at 14:00
  • The negativity I see is Instant-downvoting + `Instead of trying to fool the end user...` (where the client asks for this kind of functionality, but if you do not want to see it, you won't) + answers being mostly oriented against what I am trying to do, where I am quite convinced, this is doable, when I already did it (but not with whole lot of elegance). I need it done this way, only somehow more elegantly and post-build events are not allowed. It is in the question, so that is my point. – jmodrak Jun 24 '14 at 14:04
  • @jmodrak I thought the client asked you to prevent him/her from firing a missile by double clicking the application, not specifically "to rename the file .dll". My negativity was towards that specific solution and if it was my client, I would have advised against it. Despite being negative, I'm also trying to be helpful. – C.Evenhuis Jun 24 '14 at 14:11
  • @C.Evenhuis that is another thing, I was not the one who signed this kind of agreement, I am the one who is responsible for making it happen. – jmodrak Jun 24 '14 at 14:13
  • @jmodrak The compiler can be tricked into writing a .dll by specifying `/out myfile.dll` but I don't see where you can set this argument from within the IDE. Renaming still seems to have the least impact on your solution. – C.Evenhuis Jun 24 '14 at 14:23
  • @C.Evenhuis Exactly. The itchy part is, if I set it as Class Library, the IDE does not attach `EntryPoint` to it in the build process, otherwise, all looks good. If there was a way to attach `EntryPoint`, I would be able to start a new process and all would be fine and dandy. I am very afraid, I will have to stick with renaming, and post-builds (which complicates it even more, whereas the way it is being built at the moment makes me shrug, but be it the only option, I guess I will have to risk it though). Poor me :D – jmodrak Jun 24 '14 at 14:28

2 Answers2

1

Instead of trying to fool the end user, just let the console application stop if no command line arguments were provided. This is enough to prevent double-click destruction. Your application can then start the process with the right command line argument.

C.Evenhuis
  • 25,996
  • 2
  • 58
  • 72
  • Well, no, not allowed by design and not allowed by contract, if I had to be short. – jmodrak Jun 24 '14 at 13:50
  • So you don't want the obvious (post-build rename) but you're not allowed to do anything else. – C.Evenhuis Jun 24 '14 at 13:51
  • Am I not allowed? I don't know. There has to be some functionality, that we only are able to deliver, when run on separate process. Requirements are specified that way, so that this functionality has to be runnable only from this specific appliaction and we have the solution, I just want to kindly explore the other options, if there are any. I do not see, why all people here are saying : "you fool the user... " instead of some kind of "no, you can not do it the way you want - not to my knowledge" I thought I described the constraints quite well. – jmodrak Jun 24 '14 at 13:55
  • Well, a savvy user can still invoke the process with the same arguments. Process monitors and tools like ILSpy make that pretty easy. So if the requirement of "the user *can't* execute it" can be re-worded as "the user *probably won't* execute it" then that's fine :) – David Jun 24 '14 at 13:55
0

If allowed by contract, can you keep all logic in DLL files - including the "dangerous" stuff? Have only a simple console app "launcher" that requires a command-line parameter (as C.Evenhuis suggests).

This would seem to keep the "dangerous" code in DLL file where it can't be excecuted easily. The launcher would require a special (possibly secret) command line parameter.

For even more security, you could pass the "secret" to the launcher through STDIN.

If this doesn't meet the criteria, you'll have to go back to renaming the executable. You can add it as a post-build step.

David Crowell
  • 3,711
  • 21
  • 28