I want to make .exe for desktop application which can only used once in whole life.Nobody can run it twice.
You can not do that reliably.
You may try simple stuff like writing a magic key in the registry or storing a magic file somewhere, but simple tools like Process Monitor will show your magic markers to anyone with Google skills.
You may try to delete the .exe when it is terminating, but if the user makes a copy before they execute your file, you loose again.
You may write a root-kit that prevents the system from launching your application twice, but that is not very nice and it can be detected and circumvented too.
You may create an online service where your application needs check for a one time license to execute, but that can be cracked and you will get a big mess keeping track of one time licenses.
But in the end, if someone really wants to run your application more than once they will figure out how to do it.
How much protection do you want?
Delete itself as it exits?
What you are talking about is a single instance application that can start up, and no other copy can run - the single instance start up code is based on creating a mutex, and if another copy is run, it checks to see if the mutex is allocated, if it is, it bails out and exits immediately. Have a look at this article on CodeProject that does exactly what you're looking for.
It's possible to use a combination of DPAPI calls (ProtectedData Class) to push a value into the registry to check for a second time, or alternatively encode a value on first run and check the result matches the machine you intend it to be run on (and exit if not).
See DataProtectionScope.LocalMachine. The result of the protected data will be almost always different per machine, so this works as a specific-machine check.
You could create a registry key. If the key exists abort execution.
Related
I have a scenario where I must delete a file. I don't know and don't care who holds the file. I must delete it and they can crush for all I care. (I don't want to kill the locking task)
the only solution that comes to my mind is to use http://www.emptyloop.com/unlocker/ command line interface.
MoveFileEx is not and option as I cannot restart the machine.
is there any more C#ish method/library for this?
im not thrilled using console application API
in case it is not clear.I know the risk involved and I don't need a lecture of why this is a bad practice. if you know how to do what I asked. thank you very much!
if you want to lecture why this is bad - just don't find someone else to bother##
I can't give you a solution but can point you into a direction.
Window's Process Explorer has a function that can make you search for handles:
When you then select that handle you go to the process owning that handle and you can right click on it and Close the handle and also relieve the lock that process has on that file.
So basically you need to find out which API calls Process explorer is using and execute them yourself in your application.
I think what you are asking for is impossible due to the nature of a lock.
How would you feel if another program could just snatch your files and wipe them as you were reading data?
I believe these unlockers detect the process and try to force it to release it's lock 1 way or another(maybe even shutting their process down).
While this may work for most applications some will be more aggressive (think virus scanners for example).
So maybe you need to ask yourself if you want to increase your chances of getting a lock or if you need to be absolutely sure to get a lock.
Edit:
Assuming you can terminate the locker process and you really want to clear those files(no matter the consequences) you could find the process that holds the lock and shut it down.
In this thread they give a few solutions for tracking which process holds a lock(in c# code) via either handle, win32 dll's or even plan .NET code.
Disclaimer Be aware that shutting down a process like this will have a terrible impact on the consistency of that program and you might even do more bad then good(suppose it's writing it's status the the database for example and halfway it gets terminated)
In another post, I am told that this is the way to run something at startup. A registry key is created:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
I am supposed to place a filepath under that key.
What file types are allowable (or recommended) at the end of that path? *.EXE? (native? managed?) *.BAT?
TIA
A simple way to run some thing at startup is to put the *.exe or *.bat in the folder
C:\Users\\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.
If there is no folder , create one and place the .exe/.bat
Pretty much anything allowed, recommended is a native application which doesn't drag in a lot of other stuff. I.e. link the CRT statically.
BTW, "I intend to place my app in a separate thread" doesn't make sense. An app gets its own process and thus its own thread anyway.
BTW2, "it only takes a few seconds" - I hope you mean milliseconds. At boot time, seconds are unacceptable.
I am trying to implement file based autoincrement identity value (at int value stored in TXT file) and I am trying to come up with the best way to handle concurrency issues. This identity will be used for unique ID for my content. When saving new content this file gets opened, the value gets read, incremented, new content is saved and the incremented value is written back to the file (whether we store the next available ID or the last issued one doesn't really matter). While this is being done another process might come along and try to save new content. The previous process opens the file with FileShare.None so no other process will be able to read the file until it is released by the first process. While the odds of this happening are minimal it could still happen.
Now when this does happen we have two options:
wait for the file to become available -
Emulate waiting on File.Open in C# when file is locked
we are talking about miliseconds here, so I guess this wouldn't be an issue as long as something strange happens and file never becomes available, then this solution would result in an infinite loop, so not an ideal solution
implement some sort of a queue and run all operations on files within a queue. My user experience requirements are such that at the time of saving/modifying files user should never be informed about exceptions or that something went wrong - he would get informed about them through a very friendly user interface later when operations would fail on the queue too.
At the moment of writing this, the solution should work within ASP.NET MVC application (both synchronously and async thru AJAX) but, if possible, it should use the concepts that could also work in Silverlight or Windows Forms or WPF application.
With regards to those two options which one do you think is better and for the second option what are possible technologies to implement this?
The ReaderWriterLockSlim class seems like a good solution for synchronizing access to the shared resource.
I've been having a hard time getting the output of a "sub-process" (one launched internally by a blackbox process that I'm monitoring via c# System.Diagnostics.Process)
I took the advice given by the answer of my previous post:
here. And there you can find the details of what I've been going through.
At this point, although I'm able to locate the ssh process spawned by process1.exe, that I'm monitoring. I can't redirect the output to my c# program, because it is an "already running process", and wasn't launched directly from C#.
It seems that, all the properties that you set on a System.Diagnostics.Process object, only take effect if you are explicitly launching that process from your c# application; if some other "unmanaged process" has launched the process, setting this redirection has no effect, because the process has already been launched by something that didn't specify the redirection I need.
Is there any way to redirect output of a process that has already been launched (a process launched by a program for which I have no scope to pre-specify redirection before this process is launched)?
Assuming there's no more straightforward solution, you could try to run a piece a code in another process through CreateRemoteThread(), explained here.
Instead of redirecting the output directly from the running process, can you capture the output as it leaves the process A at the intended destination, the pass it into your new process?
Perhaps you can look at this code. I found it when searching for a solution to do the same kind of thing; however, it was not really inter-process.
If that doesn't help you might be able to look at P/Invoking SetStdHandle and GetStdHandle which are supposed to be used when redirecting standard output. I think this is what the code sample linked to does to make the redirection happen.
Note: I just looked at this stuff and didn't actually get it to work properly. (I had a better solution available to me because I had access to the source code outputting to the console)
I've got the same conundrum. It's not an option for me to invoke anything internal in the slave process. It's already running, which code is beyond my control. But I do know it spits out Standard Output, which I want to monitor, process, etc. It's one thing I kick off the process, I can configure the redirection, but in this instance, the process will be launched secondarily to my kicking off the primary slave process. So I do not have that option. I haven't found a way for .NET Process to work under these conditions. Perhaps there is another way, maybe C++ is the way to go here? This would be marginally acceptable, but I would like to approach it from a .NET C# perspective if possible.
Is it possible to update an application to a new version without closing it?
Or is there a good way to do that without user noticing it was closed?
Typically applications notice on startup that an update is available, then ask the user whether it's okay to update. They then start the update process and exit. The update process replaces the files, then launches the new version.
In some cases you may be able to get away with updating some pieces of an application without a restart - but the added complexity is significant, and frankly it's better not to try in 99% of cases, IMO.
Of course, you haven't said what kind of app you're writing - if you could give more information, that would help.
The application needs to be closed before updating it, because updating an application generally means replacing the executable files (.exe, .dlls, etc.) with their newer versions, and this can't be done without closing the application.
As Jon said, in some cases, you can upgrade the application without closing it. But, this is not advisable, as it might cause failure in the updater, and the whole update might rollback.
Updater can be another executable which will first close the main application, then download the updates, apply them, start the main application, and exit (An example of this is Skype, FireFox, etc.)
You could separate the backend into a separate process/module and update the the backend by restarting it without the user realizing it.
Updating the front end will be a bit trickier, but could be avoided or delayed, if necessary.
A nice and clean way to achieve this would be using dynamic plugins.
You can code your application heavily plugin-based. When an update is needed, unload the plugin that needs to be updated, update the .dll file and load it back into the application.
However, making this invisible to the user may be a tough job, therefore it depends heavily on your design and coding.
I remember InTime having the ability to swap exe's live, however that had to be carefully coded. I know it's possible but as Jon Skeet said, you're likely better off not trying.
Unless you're doing some kind of automation or something very serious... even then, you should consider a failover so you can shut one down / restart if needed.
If you has some some sort of skeletal framework which launched your application and dlls, you could look at CreateDomain. It will take serious design efforts on your part though. Good luck!