I've made an application that gets installed/deployed to /Program Files/STUDYvault/ called "STUDYvault Client.exe" and in the app, a button triggers/calls a .cmd that's in the same directory, called 'Scripts System.cmd'
Private Sub SynchroniseToolStripMenuItem_Click(sender As System.Object, e As System.EventArgs) Handles MenuBackup.Click
System.Diagnostics.Process.Start("SCRIPTS SYSTEM.cmd")
End Sub
The .CMD just runs basic xcopy commands for backups. When the software is executed manually, it sees the .cmd within the same directory, however, when it is run by the system (eg startup, either by registry key or via shortcut in the startup folder) (I tried both Inno Setup AND NSIS), it crashes with an Unhandled Exception, 'Cannot find the file specified'. I'm thinking the OS is executing the .exe but running it in say /Windows or /System32 or something. It doesn't seem to be an issue with the visual studio app (it runs when executed manually, and finds the .cmd no matter what the directory) or the installer (it's basically just extracting to /Program Files and putting a link in the startup part of the registry)
My friend and I thought up a workaround, although it's quite nefarious. One could force the user to install the software to C:/Program Files/STUDYvault and have it unchangeable, and then in the app have it point to C:/Program Files/STUDYvault/Scripts System.cmd instead of just "SCRIPTS SYSTEM.cmd" - could this work also?
I'm sure I'm just missing something stupidly small, because the application fires the following code fine when installed:
Private Sub HivemindTechToolStripMenuItem_Click(sender As System.Object, e As System.EventArgs) Handles HivemindTechToolStripMenuItem.Click
System.Diagnostics.Process.Start("http://my-website.com.au")
End Sub
EDIT:
Alright, I've developed a work-around for anyone having this issue. It seems to be rights-related or where the system is executing it from; so it's calling on the .CMD from wherever that is (most likely not its install directory) - so in-app I've had it call on:
Private Sub SynchroniseToolStripMenuItem_Click(sender As System.Object, e As System.EventArgs) Handles MenuBackup.Click
System.Diagnostics.Process.Start("C:\\Program Files (x86)\\STUDYvault\\SCRIPTSYSTEM.cmd")
End Sub
Which is the install directory, and then in the installer (Inno Setup) I've used the following for defining the install directory under [setup]:
DefaultDirName={sd}\Program Files (x86)\STUDYvault
DefaultGroupName={#MyAppName}
DisableProgramGroupPage=yes
DisableDirPage=yes
Here, DefaultDirName=SD\DIRECTORY defines that it will be force-installed to Program Files (x86) (Fine for 64-bit Windows users, 32-bit users will have to deal with a second Program Files folder but x64 is the most common install in this day and age anyway so we won't have an issue there); DisableDirPage=yes hides the install page that asks the user where they want to install it - most users will leave it as-is but for the more curious user who may want to change it, this WILL break the install, seeing as it's calling on /Program Files (x86)/STUDYvault in-app.
It's a relatively dirty fix, and I feel like Dr. Evil here, but ...it works. Hopefully this will help anyone having a similar issue in the future.
Use this
Process.Start(Application.StartupPath & "\SCRIPTSYSTEM.cmd")
You can get location of the executable file by using Environment.CurrentDirectory. Using this property we can make the code works regardless of executable folder location (as long as cmd file exist in the same folder, of course). So this maybe a more proper way to get the job done :
Dim batchFilePath As String = Path.Combine(Environment.CurrentDirectory, _
"SCRIPTS SYSTEM.cmd")
System.Diagnostics.Process.Start(batchFilePath)
You may want to improve it further by adding logic to check if cmd file actually exist in the location pointed by batchFilePath (you can use System.IO.File.Exists() to do that).
Related
I'm developing a VB.NET Windows Forms app to edit files of with extension *.fltp, and I want to use ClickOnce deployment. But the File Association part of my manifests doesn't seem to work.
From my time programming in C++, my understanding is that double-clicking a file in Windows Explorer causes Windows to undertake the following actions:
Scan the registry for the file extension (say, *.doc)
Discover in the registry that the file extension is registered to a command-line scheme (in this case, winword.exe %1)
Run that command-line (i.e. winword.exe "Untitled.doc").
Now, ClickOnce doesn't offer such fine-grained control; in MSVS, I just go to the Publication options and get to associate my app with *.fltp. I assumed it follows the general pattern of putting App.exe %1 in the registry, and wrote my application to that spec.
When I deploy the application, it seems as though the application is registered to *.fltp files: their icon and description changes, and double-clicking on them in Windows Explorer opens the app.
But the command line is blank, so my app just opens a blank new document! When I place in one of my files
Private Sub Init(sender As Object, e As EventArgs) Handles MyBase.Load
MsgBox(Command)
End Sub
the deployed app just shows an empty messagebox. (The same behavior shows if I use System.Windows.Forms.Messagebox.Show, System.Environment.GetCommandLine, or My.Application.CommandLineArgs — it's not the legacy VB functions that are at fault.)
The registry entries are similar to those for a C++ app, but not identical, so I can't figure out what they do.
How can I tell which file the user double-clicked on?
You've correctly deduced that ClickOnce doesn't pass the file as a command-line argument.
The problem here is that ClickOnce (typically) checks for app updates right when the app starts. So if ClickOnce used the fixed registry schema you describe for C++ apps, Windows might start the app with a file location on the command line, ClickOnce realize it needs to update the app, quick download the new executable and update the registry, and start the updated executable in a new process, accidentally squashing the command-line along the way. So it stashes the file in an Appdomain, does any update stuff necessary, and then starts the app in the child Appdomain.
TL;DR: You want AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData instead of the command line.
I'm working on a golang project that has to read files from a sub directory...
When debugging my program it (not sure what it is yet) is unable to locate the files when provided a relative path. Im using io.util.ReadFile(RELATIVE_PATH) for this operation.
This problem doesn't occur when running the program from the terminal.
This has lead me to believe intellij does something behind the scenes debugging/running where it messes with the directory structure (moves it into a temporary location?). If this is the case, how would I go about configuring intellij so that the sub directories are included in the magic or removing the magic so the program is debugged from the directory it lives in.
I'm new to golang/intellij so any help would be appreciated.
Click on "Edit Configurations"
and change the "Working directory" path to where your program should "live in".
i am making a 'simple' program that on button click does this:
Private Sub Button4_Click(sender As Object, e As EventArgs)
Dim proc As New System.Diagnostics.Process()
proc = Process.Start("resources\navcoder.exe", "")
proc.WaitForExit()
End Sub
all works fine when testing in visual studio but not once i publish and install, even if the resource folder is in the install directory.
if i change it to:
proc = Process.Start("c:\resources\navcoder.exe", "")
it works fine, but i obviuosly needs to have the folder there with the required files in it.
what am i doing wrong?
A lot of people seem not to realise what resources are. The whole point of adding a resource to your project is to have the data it contains compiled into your EXE. The Resources folder in your project is just a place to store the original source files. It doesn't exist as far as the application is concerned, just as your VB source code files don't exist. When you build your project, the data in those resources is compiled into your EXE so they are no longer files and can no longer be used as files.
That's why you don't embed other EXE files as resources. You could extract the resource and save it as a file first but I would recommend against that. Add a new folder to your project and add the EXE file and any dependencies to that folder and set their Build Action to Content. They will then be copied to your output folder as is. You can then execute the EXE file because it is an EXE file. You should also use Application.StartupPath as the root of the file path rather then relying on the current directory being what you think it will be.
You should always check for existance, if its a web app, would do this in the application start in the global asax. If you are running this under a different user account, check the account has permissions. Otherwise even if the directory exists, it will fail if it cant access it or does not have permissions to execute the file.
Might be able to tell you more if you give the actual exception. I.e Unauthorized or does not exist.
We are using a really old Intel math library (nsp.dll and family) and it's location must be specified in the Windows PATH variable. Previously we installed these dll's in the Windows/System32 folder so everything was fine. Now we would like to install these dll's in another folder, the reason is we are migrating to Windows 7 and do not want to place dll's in the System32 folder. I found the SO answer as to how to change the PATH variable (thanks for that) and that does work. After installing I checked the PATH and our folder was NOT added to the PATH, I check the reg key and our folder WAS added. But....it appears that when we register our OCX that uses those dll's, the path is not changed yet. When I rebooted the PATH has our added path.
So, it seems I'm in a catch-22, I need to change the PATH and also use the new PATH during the install. Do I need to require a reboot and some how register that OCX after the reboot? Or is there another way?
After the reboot, running cmd as Administrator allowed me to register the OCX in the new folder. But I would like to have the installer do this automatically.
Thanks.
Make sure that you have the following setting in your script:
[Setup]
ChangesEnvironment=yes
This will allow the PATH change to take effect without a reboot.
However it will only affect new processes started by the shell. If you have an existing cmd window, or you try to start the application at the end of the install without using the shellexec flag, it will still see the old PATH.
And double-however: you cannot legally change the path where a COM DLL or OCX file is installed and registered. These must without exception be installed in the location specified by the vendor. Hence you must continue to install it in {sys} anyway. (At least if you're still using system-wide registration. There is an alternative that does let you move it, if you look up "registration-free COM", but it comes with a lot of caveats and is seldom worth the effort.)
Also note that "because Windows 7" is not a valid reason to move something anyway.
I have added COM control AxWindowsMediaPlayer to form in vb.net.
and just have following code
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
WMPlayerVideo.URL = "abase.mp4"
End Sub
End Class
abase.mp4 file is kept in directory where exe is there. Every thing runs fine on dev m/c but on client machine application is not lauached.
When Interop.WMPLib.dll and Interop.WMPLib.dll are copied to the exe file directory then application is lauched at least but file is not played automatically and even on pressing play button its not played.
Is some dll registration required to make it work? or some references needed in project?
or some changes on user machine?
Copying the DLLs is required, it cannot work otherwise. Which leaves the location of the file. You are only giving the relative location of the file, not the full path (like "c:\mumble\foo.mp4"). On your machine, this file needs to be stored in the bin\Debug folder of your project directory to make it work. Another machine you deploy your program to isn't going to have a bin\Debug (or Release) folder. It still needs to be present in the same directory as the EXE. Maybe you forgot to copy the .mp4 file?
Clearly you'll want to provide the user with a way to select the file. Use OpenFileDialog.