I have a tool (created in C#) that launches another application using Process.start. This second application is a standalone application handling some external hardware using dlls and APIs.
Now whats happening is, when I launch the standalone application, it doesn't work until I copy paste all dll files (that are required by standalone application) in my tool's folder otherwise standalone application throws errors saying dll's missing.
It is also causing some performance issue with the standalone application too.
My assumption is : Because primary execution thread is from my tool and thus all spawned threads requires dll in the base thread (my tool's) folder. I don't want this. I am not sure what I have to do in this scenario.
If the only way to launch exe file in C# is using Process.start then how can I release the thread so that my tool don't track the standalone application ? (in case my assumption is correct)
If there is any other way to launch the exe file, please do let me know.
Help is much appreciated.
Kind Regards
Have you set WorkingDirectory appropriately?
It should be set to the location where your "another application" is located.
Related
I've developed a tool in C#.NET/Visual Studio, which uses an imported dll.
The dll will be copied to output folder, when the project is built.
It doesn't need to install the application, you can just copy the exe and dll to a local folder to start.
Now I want to start the application from a network share:
\\localhost\program\prog.exe
All is fine while I don't call a function from the external dll. Then it crashes with the following error window:
Program has stopped working...
Question: Is there a way to make it work without copying both to a local folder and without changing policies on client computers?
Answer: Mapping \localhost to Z: solved this problem.
Please feel free to ask, this is my first question ;-)
Best regards,
Christian
This sounds like a "caspol" issue. Network shares like \\localhost\program\ get reduced trust. Interestingly, from (some time ago), named shares actually get more trust - so one simple option is to map, say, z: as \\localhost\program, and access z:\prog.exe - you might find that this makes it work. Beyond that, the options are:
caspol changes to the each client machine
ClickOnce
of those, the latter is simpler. Then you simply run the ClickOnce application (rather than the .exe) - ClickOnce then basically makes it work. The user will, IIRC, need to click an "ok" the first time they run the application, but that's about it. You would need to ensure that the external dll is known the the ClickOnce deployment, i.e. it is in the project and marked to be shipped.
I've been working on a simple project that uses some common .NET classes, isolated storage, some resources and no external libraries.
Somehow the EXE generated (either in debug or release mode) no longer runs (stops working as soon as it's opened) without giving any details or displaying any exceptions.
It runs normally in visual studio, and there's a .application in the same folder that when clicked starts in install process.
I'm not interested in installation files, I just want it to be the way it was: running an EXE (it's easier to get testers when all you have to do is running it).
I have previous versions of the program, and all of them run normally through the EXE's.
I don't recall changing anything regarding framework, deployment or build. I revised it and there's nothing changed apart from using new objects from the .NET framework.
--[Update]--
Just checked the event viewer. Event data "not available" and answer "not available".
This is a classic example of when a personal version control system would have helped. It would have automatically kept every version of your code including the one right before you made the change that messed up your exe.
Anyway to fix your issue comment out the majority of the code untill it atleast runs. Add a simple output statement just to make sure it is doing something. Then slowly add back in more code.
I suggest you to run your exe file in a consol (cmd.exe) to see if your application displays errors or exceptions in it.
Check the <YourAppName>.Exe.Config file.
Probably it is not well-formed Xml.
I'd start with removing the setup project from the solution, rebuilding then run it in debug mode.
i developed an updater application for my windows app. They are different projects under the same solution and they run as different processes. when i run the app it checks for updates at startup (as another process). when i click update button it tries to download files to the installation location. (i am using the .exe in debug folder i don't create setup file) Everything works fine but the main application (app.exe) can't be overwritten because it is used by update process. but in update process i kill app.exe and app.exe goes from task manager too. i couldn't find anything, how main app.exe is used by update. has anyone any idea how update uses main app ? how can i watch it? in which line it starts using the other app?
Rename app.exe
Insert new app.exe
Close running, old app.exe
Start new app.exe
Check for renamed app.exe (in newly started app.exe)
Delete old, renamed app.exe
If the updater app has a reference to the main app exe, it will keep it locked. If that's the case, can you remove the reference to the main app from the update app project? This may need moving some code directly into the updater's source.
To find out who has a hand on your process you should start ProcessExplorer. There are some spy glasses in the menu bar. Just click on it and see which process holds a handle to your app.
Do you need to invent your own? There are existing solutions that you may be able to leverage that already do this. Microsoft ClickOnce supports this if it fits your deployment model.
A quick google search turns up a few things as well:
http://csautoupdater.sourceforge.net/
http://www.codeproject.com/KB/vb/Auto_Update_Revisited.aspx
I'm going to make a desktop application that will run in the background, meaning no visible window, and I'd like an option called: "Upload Text" to appear when a user right clicks a file.
Can someone point me in the right direction? I also have to make sure that if someone wants to uninstall the program at any point, that the shell modification is also cleanly eliminated.
The app will run Windows XP, Windows Vista and Windows 7. How different are these OS's in handling my shell dilemma?
This is a shell extension. You've tagged this question with the C# tag; you should know that writing shell extensions in a managed language is strongly discouraged:
Unfortunately unmanaged C++ is really
the only way to go here.
Writing in-process shell extensions
in managed code is actually a very
dangerous thing to do because it has
the effect of injecting your managed
code (and the .NET Framework) into
every application on the machine that
has a file open dialog.
The problems occur because only one
version of the .NET Framework can be
loaded in a process at any given time
(other shared components such as java
and msxml have the same property and
thus the same restriction).
If you write your shell extension
using the 2.0 .NET Framework and an
application built with the 1.1 .NET
Framework uses a file open dialog,
your shell extension will fail because
it can not run on an earlier version.
Things can get even worse if your
shell-extension manages to get loaded
in a process before another
applications managed code does: your
extension may force an existing
application onto a different runtime
version than the one it was expecting
and cause it to fail.
Because of these problems we strongly
recomend against using any
single-instance-per-process runtime or
library (such as the .NET Framework,
java, or msxml) in an in-process shell
extension.
That said, people have done it.
Here's a guide to creating shell extensions, using C++.
You could add your app to the SendTo folder.
What about a stand-alone program using SendTo?
Install the exe to "Program Files\mycompany\myprogram" and a shortcut to the exe into the SendTo folder. Then when a user right clicks on a file, selects SendTo, and then selects your program, your exe will be executed by Windows and the full path to the filename will be passed in via argv[1]. If they select n files they will be in argv[1]..argv[n].
If you want your program to be invisible then do not make the default form visible. You could optionally place an icon in the tray so the user could double click on it to see the upload progress. When the upload of argv[1] is complete, process argv[2]...argv[n] if they exists and exit. To cleanly uninstall, remove your program and the shortcut from the SendTo folder.
I've got a WinForms application that I am working on. There is one small piece of functionality that needs to be run as an administrator in Vista/Win7. I understand how I can set the requestedExecutionLevel for the application in the manifest. The trick is, I don't want to require the user to run the entire application as an administrator, just one part of it. So I would like to have most of the functionality run asInvoker.
If I put the admin functionality in a dll, is there a way to mark it as requireAdministrator? I tried to use MT to add a manifest to the dll, but that didn't seem to work. What do I need to do?
No there is no way to differentiate the execution level of an application on a DLL by DLL basis. This is a process wide setting. You'd have to invoke another process within your application that runs the code in that DLL with elevated privs.
One option you do have though is to use either the rundll or rundll32 program to run the DLL directly. This is a standalone windows program designed to load and run a particular DLL. You could elevate the rundll process and get the isolation you desire.
Googling for rundll will give you plenty of advice on how to use it :).
Elevation is per-process, so you can't have a DLL elevated by itself. You need to look at hosting the DLL in a separate, elevated process; or you can look at the elevation COM moniker, and do it that way.