File.Replace not behaving as expected - vb.net

The following code should replace the executable and restart the application, which should work because the content should be replaced but not in the current running instance:
Dim tmppath As String = System.IO.Path.GetTempFileName
Private Sub YesBtn_Click(sender As Object, e As EventArgs) Handles YesBtn.Click
Dim client As New WebClient()
AddHandler client.DownloadProgressChanged, AddressOf client_ProgressChanged
AddHandler client.DownloadFileCompleted, AddressOf client_DownloadFileCompleted
client.DownloadFileAsync(New Uri("https://github.com/Yttrium-tYcLief/Scrotter/raw/master/latest/scrotter.exe"), tmppath)
End Sub
Public Sub client_DownloadFileCompleted(ByVal sender As Object, ByVal e As System.ComponentModel.AsyncCompletedEventArgs)
File.Replace(tmppath, Application.ExecutablePath, Nothing)
Application.Restart()
End Sub
According to MSDN,
Pass Nothing to the destinationBackupFileName parameter if you do not want to create a backup of the file being replaced.
However, what really happens is that it does create a backup (if the .exe is scrotter.exe, then the new backup is scrotter.exe~RF729c1fe9.TMP). Additionally, a new empty folder called "False" is created in the root directory.
All I want is to replace the running executable with my file and not have any backups or extra folders. Any ideas?

Pretty hard to explain this with the posted code, this smells like a some kind of 3rd party utility stepping in and avoiding the problem your code has. It will never work when you pass Nothing for the backup file name. It is required if you want to replace an executable file that's also loaded into memory. The CLR creates a memory mapped file object for the assembly so Windows can page-in the data from the assembly into RAM on demand. With the big advantage that this doesn't take any space in the paging file. That MMF also puts a hard lock on the file so nobody can alter the file content. That would be disastrous.
That's a lock on the file data, not the directory entry for the file. So renaming the file still works. Which is what File.Replace() does when you provide a non-null backup file name, it renames the assembly so you can still create a file with the same name and not get in trouble with the lock. You can delete the backup copy afterwards, assuming that your program still has sufficient rights to actually remove the file when it starts back up. That's unusual with UAC these days. Or just not bother, disk space is cheap and having a backup copy around to deal with accidents is something you can call a feature.
So get ahead and use File.Replace() properly, use the 3rd argument. Don't forget to delete that backup file before you call Replace().

I think the .exe is locked so long as your process runs - which instance runs is of no concern.
To avoid this, I would place the updater in a separate .exe and shut down your main apllication while updating.

Related

Exe working only if started manually but I want it to start automatically

I have done a simple VB application with this code:
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Dim procName As String = Process.GetCurrentProcess().ProcessName
Dim processes As Process() = Process.GetProcessesByName(procName)
If processes.Length > 1 Then
Process.GetProcessesByName("keyinput")(0).Kill()
End If
End Sub
Public Sub type(ByVal int As Double, str As String)
For Each c As Char In str
SendKeys.Send(c)
System.Threading.Thread.Sleep(int * 1000)
Next
End Sub
Sub vai()
Dim line As String = ""
If File.Exists("trans.txt") Then
Using reader As New StreamReader("trans.txt")
Do While reader.Peek <> -1
line = reader.ReadLine()
type(0.155, line)
'SendKeys.Send(line)
SendKeys.Send("{ENTER}")
Loop
End Using
File.Delete("trans.txt")
End If
End Sub
Private Sub Timer1_Tick(sender As Object, e As EventArgs) Handles Timer1.Tick
vai()
End Sub
Basically the timer in it check if a file exists, read it and type the content simulating the keyboard.
I want this exe to start automatically when user login, it does it, apparently, I can see the form1 pop up but doesn't really works. Everyting is fine only if I run it manually by double-clicking the icon. Why and what can I do? Thanks
ps. i already tried to execute it with windows task manager, or putting a shortcut in the windows startup folder, or calling it from a cmd
EDIT:
when app starts automatically , process is running, but windows form is showing like this
Instead starting manually is showing like this:
I don't know this for a fact but I suspect that the issue is the fact that you are not specifying the location of the file. If you provide only the file name then it is assumed to be in the application's current directory. That current directory is often the folder that the EXE is in but it is not always and it can change. DO NOT rely on the current directory being any particular folder. ALWAYS specify the path of a file. If the file is in the program folder then specify that:
Dim filePath = Path.Combine(Application.StartupPath, "trans.txt")
If File.Exists(filePath) Then
Using reader As New StreamReader(filePath)
EDIT:
If you are running the application at startup by adding a shortcut to the user's Startup folder then, just like any other shortcut, you can set the working directory there. If you haven't set the then the current directory will not be the application folder and thus a file identified only by name will not be assumed to be in that folder.
If you are starting the app that way (which you should have told us in the question) then either set the working directory of the shortcut (which is years-old Windows functionality and nothing to do with VB.NET) or do as I already suggested and specify the full path when referring to the file in code. Better yet, do both. As I already said, DO NOT rely on the current directory being any particular folder, with this being a perfect example of why, but it still doesn't hurt to set the current directory anyway if you have the opportunity.
It was a Windows task scheduler fault, that for some reason didn't executed the exe correctly at logon. I've solved the issue by using Task Till Down and everything works fine now.

Can't delete .xlsx file - Next Step?

I'm getting an IOException (file in use by another process) error when trying to delete an .xlsx file. I moved the delete code to the front of Form_Load() just to make absolutely certain that nothing else I was doing was trying to open or read it.
Process Explorer can't find any references to the file to see what else might be trying to use it.
The file properties indicate that the user and system have full control.
I don't know what to look at next.
Private Sub PreEdit2_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
My.Computer.FileSystem.DeleteFile("\\HOSTNAME\Folder\Import Data\Other Import Files\" & "9710.xlsx")
I tried a local reference to the file just for good measure.
My.Computer.FileSystem.DeleteFile("C:\Folder\Import Data\Other Import Files\" & "9710.xlsx")
Really stumped here. Any suggestions sincerely appreciated.
EDIT:
Modified my program to delete all kinds of other files in the same directory. They delete with no problem.
Created an empty test program with one line that tries to delete the file
and it gets the same IOException.
So, my program isn't doing it. The error says something else is using the file, no monitoring program I have used shows the any process involved with the file, and File Explorer can delete it? Strange things are afoot at the Circle K.
EDIT 2:
I have moved the file and tried deleting it in lots of different directories. I can delete it everywhere else I try it. The only place I don't seem to be able to delete it (with my new single purpose test program) is in the directory it was originally copied to. It should be remembered that all of the other files in that directory I can use the program to delete with no problem.

Files not opening as read-only in VB.NET when read-only attribute set

I'm having trouble with a bit of code designed to intentionally open files as read-only. My team often needs to be able to peek into each others' files without locking the file owner out, so in a form being designed for document management I want users to be able to open files optionally as read-only.
Coming from VBA I'm still somewhat new to VB.NET and also bitwise operations generally, but I believe the "read-only" interpretation of this code from MS Docs has been correctly implemented:
Dim attributes As FileAttributes
attributes = File.GetAttributes(path)
If Not (attributes And FileAttributes.ReadOnly) = FileAttributes.ReadOnly Then
' Make file readonly.
File.SetAttributes(path, File.GetAttributes(path) Or FileAttributes.ReadOnly)
End If
' Open the file
System.Diagnostics.Process.Start(path)
' Reset the file to read/write.
attributes = RemoveAttribute(attributes, FileAttributes.ReadOnly)
File.SetAttributes(path, attributes)
When I use "GetAttributes" before and after the line to open the file I get a return of 1 or sometimes as 33, which the FileAttributes enumeration documentation suggests is correct for what I'm trying to do. Before and after the attribute change "GetAttributes" returns 128 or in certain cases 32, which also should be correct.
However despite the fact the above code appears correctly implemented and seems to be producing the correct affect in the file's attributes, files opened this way (namely Excel files) open as read-write. I'm also fine with other ways of opening a file read-only provided that it can be used equally well on any document you would commonly encounter in an office setting (Excel, Word, etc.) with its default program. That being said, I've tried several methods and haven't had any success, and this one by far has seemed the cleanest and most promising.
Thanks in advance!
As described in comments, the file attributes are restored to their
previous state right after the Process.Start() command: the
application that opens the file has not been started yet; when it
finally access the file, the read-ony attribute has already been
removed.
A possible solution is to subscribe to the Process.Exited event and restore the original file attributes when the Process termination is notified.
A modified version of your code: the EnableRaisingEvents property causes a process to raise the Process.Exited event. I subscribed to the event using an in-line delegate (a Lambda), but I added an example that uses a standard delegate method using the AddressOf operator (since you said you have to learn about events).
Since we want to run a file and not an executable, we need to also set UseShellExecute = True, so the Shell will find and execute the registered application associated with the file extension.
If UseShellExecute = True is not specified, an exception is raised (the file is not an executable).
The name of the file to execute is assigned to the Process.StartInfo.FileName
When the Process terminates, the Exited event is raised. In the event handler, the file attributes are restored to the previous state.
Private Sub SomeMethod(filePath As String)
' filePath is File's Full path
Dim attributes As FileAttributes = File.GetAttributes(filePath)
File.SetAttributes(filePath, (attributes) Or FileAttributes.ReadOnly)
Dim proc As Process = New Process()
proc.StartInfo.FileName = filePath
proc.StartInfo.UseShellExecute = True
proc.EnableRaisingEvents = True
AddHandler proc.Exited,
Sub()
File.SetAttributes(filePath, attributes)
proc?.Dispose()
End Sub
proc.Start()
End Sub
If you want to use a standard method as the Exited event handler, you have to declare the filePath and attributes variables in a different scope. Neither can be a local variable, they won't be accessible from the method delegate.
If you need to run just one file, these can be instance fields (declared in the scope of the current class).
If you instead can have multiple processes running different files, all waiting for the associated applicationt to terminate, these informations should to be stored in a list of objects, a Dictionary or a similar container.
For example, using a Dictionary, declared as a Field:
(the Dictionary Key is the File path. If a file can be opened multiple times - a .txt file maybe, use a different identifier)
Private myRunningFiles As New Dictionary(Of String, FileAttributes)
' (...)
Private Sub SomeMethod(filePath As String)
Dim attributes As FileAttributes = File.GetAttributes(filePath)
If Not myRunningFiles.ContainsKey(filePath) Then
myRunningFiles.Add(filePath, attributes)
Else
' Notify that the file is already opened
Return
End If
Dim proc As Process = New Process()
' (... same ...)
AddHandler proc.Exited, AddressOf OnProcessExited
End Sub
Protected Sub OnProcessExited(sender As Object, e As EventArgs)
Dim proc = DirectCast(sender, Process)
Dim filePath = proc.StartInfo.FileName
Dim attributes = myRunningFiles(filePath)
File.SetAttributes(filePath, attributes)
myRunningFiles.Remove(filePath)
proc?.Dispose()
End Sub
Thanks to #Jimi I was able to come up with the solution. In my application Excel files are the most important to open in ReadOnly so I'm happy with an Excel-only solution for the time being. While his answer for using and releasing attributes was great it had the problem of not restoring the attributes to their default until the file is closed, which to my understanding would cause others to also open the file ReadOnly while the file is open. The point of this in my application is to "peek" at a file without locking other users on a network out of ReadWrite access, so unfortunately his-well-thought out solution won't work.
I was however able to use the /r switch with a bit of investigating. It was a bit tricky (for someone of my skill level) since some switches need to be placed before the file path and some after. Solution below:
Process.Start("EXCEL.exe", "/r " & Chr(34) & path & Chr(34))

Monitor Executable Use

My goal is to set up a service to watch a network folder containing about 200 .exe files. What I'd like is to have the service update a log each time one of the .exes is launched. Basically I'd like to log usage of each application by recording every time one one of them is used.
I've tried using the FileSystemWatcher class to accomplish this, code below, figuring that the LastAccess filter would do the trick, but it seems it won't. When I run this code no event is raised when the applications are opened.
Is there some way of using the FileSysteWatcher class to do this kind of monitoring? Is there any way to do what I'm attempting?
Private Sub StartWatch()
Dim exeWatcher As New FileSystemWatcher
exeWatcher.Path = "<path>"
exeWatcher.Filter = "*.exe"
exeWatcher.IncludeSubdirectories = True
exeWatcher.NotifyFilter = (NotifyFilters.LastAccess Or NotifyFilters.LastWrite Or NotifyFilters.FileName Or NotifyFilters.DirectoryName Or NotifyFilters.Attributes)
AddHandler exeWatcher.Changed, AddressOf ExeChanged
exeWatcher.EnableRaisingEvents = True
End Sub
Private Sub ExeChanged(source As Object, e As FileSystemEventArgs)
Console.WriteLine("File: " & e.FullPath & " " & DateTime.Now.ToString())
End Sub
Take a look at this Stack Overflow answer, which involves monitoring WMI Win32_Process instance creation events (basically, when WMI registers that a new process has been created). This is probably the most effective way outside of a C++ kernel hook to find out when a process has started.
At that point, you just need to use a regular expression to test the file path against to see if it's originating from that folder, and respond appropriately if it is.
The file system watcher cannot be used to accomplish this because it doesn't know why the file is being accessed. It could be accessed to show the properties of the executable or someone copied it to their local hard drive.
If your goal is to see what machines are running your executable, you can use Windows Management Instrumentation (WMI) to remotely query a machine for Win32_Process and determine if your process is running there.

Releasing memory held in objects in VB.NET

I am using a 3rd party DLL from pdf-tools to parse PDF files inside my VB.NET application and write the extracted data to a SQL localDB database. I'm giving the user two options: to select a PDF file for parsing or to point to a folder and the application will loop through all PDF files inside it. Both options call the same procedure doPDFFile() as below.
The problem is: if I import a number of files individually by selecting a file every time, the program runs fine. However, If I select a folder that contains the same files, the memory used by the program will keep growing further and further. In Windows task manager, it can reach to 1 GB after importing around 30 files.
I used ANTS memory profiler from redgate, and it showed that one object called "GraphicsState" which is part of the pdf-tools object is growing too big when looping inside a folder. This does not happen if I select the same files one by one. Besides the memory problem, the application becomes very slow after parsing some files. My questions is: why is this happening? and how to prevent it? The user should be able to point the program to a folder with hundreds of PDF files, how can I achieve this?
Below is a snapshot of the code:
'When user selects one file
Private Sub OpenToolStripMenuItem_Click(...)
OpenFileDialog1.FileName.ToString
doPDFFile()
End Sub
'When user selects a folder
Private Sub LoopToolStripMenuItem_Click() Handles LoopToolStripMenuItem.Click
FolderBrowserDialog1.ShowDialog()
sPath = FolderBrowserDialog1.SelectedPath
For Each fileName As String In IO.Directory.GetFiles(...)
sPath = fileName
doPDFFile()
Next
End Sub
Inside the doPDFFile() procedure, I'm doing the following, I'm using the document object from pdf-tools and I'm passing it byRef to another procedure:
Public Sub doPDFFile()
Using document As New Pdftools.PdfExtract.Document
document.open(sPath)
findFirstPage(document) 'passing by reference
ParseFirstPage(document) 'passing by reference
'storing the parsed text in an array
'.......
do
'extracting the colors from the graphicsStateObject inside the document object:
Using objGraphicsState As Pdftools.PdfExtract.GraphicsState = content.GraphicsState
sColor = objGraphicsState.FillColorRGB
End Using
'save text and color in an array of objects
until endOfText
end using
end sub