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.
Related
The application with Connection-String encrypted the first time the user run the program. (RsaProtectedConfigurationProvider)
Using the classical "Shared Sub ToggleConfigEncryption(ByVal exeConfigName As String)" https://msdn.microsoft.com/en-us/library/89211k9b(v=vs.80).aspx?cs-save-lang=1&cs-lang=vb
After the installation and execution of the program on another computer I have two folders on AppData\Local\Apps....
one of this folder with the APP.Config encrypted and the other one with no encryption at all. I proved deleting this second file and the application still run fine.
But why this file exist with plain text after running the program?
Note: Program published using Visual Studio
I "solved" this situation creating only a portable app.
1) Publish the app on local mode
2) Rename the files inside the APP folder to get rid of the .deploy extension
3) Run the APP from the .exe file
I'm creating a WIX installer for a C# application.
In the application I use System.Configuration.ConfigurationManager.AppSettings[Setting1] to get settings.
My question is, where must I place the program.exe.config file on the machine in order for it to work?
I can't place it with the program in ProgramFiles directory, since those files are read-only.
I tried:
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);
config.AppSettings.Settings[Config1].Value = "Value1";
config.Save();
Unfortunately I don't know where it's looking.
Thanks your replies, Trevy
It should be in the same folder of the program.exe. Use wix to copy both program.exe and program.exe.config to the required folder.
If you need to edit the configuration file during the installation you will need to do it using a custom action in wix. Make sure you pass the file path to the custom action and write the code to read the configurations in that file and edit.
The problem isn't that the files there are readonly - the problem is that you are trying to update files in the Program Files folder with your config.Save, and you can't do that if you are a limited user, and you are always limited (even if you are admin) unless you elevate. The short answer is that:
If your app routinely updates files in restricted areas then it probably needs elevation, so give it an elevation manifest.
If however you require you app to be used by limited users and allow them to update that config file then don't install to Program Files. Choose User Appdata folder, for example. Windows is probably using your config file during program startup, so you can't separate it from the exe.
When I was creating an installer for my app, I found I couldn’t save my settings.
The reason is because the Program Files repository, from a practical point of view, is read-only (Applications should never run with elevated permissions). When installing a program, the only time we modify the MyApp.exe.config file is at installation/upgrade/repair time.
The config file has many sections. One of them is userSettings. This is where we store any data we need to modify during the lifetime of the application. When run for the first time, Windows creates a hidden file in the user’s AppData folder. That is why we can save user settings, even though the config file is in the same directory as the MyApp.exe
So the answer is, if we run into permission errors when trying to save our settings it means we are writing our settings to the wrong section of the config file. We need to place it in the userSettings section and nowhere else.
For convenience, Visual Studios has a settings editor (the settings tab of the properties page). It allows you to create strongly typed user and application settings. The generated class lets you save user settings, but not application settings for the above reasons.
In metro, the codes like following will throw exception:
String fileName = #"C:\Test\dd\ccc.jpg";
StorageFile file = await StorageFile.GetFileFromPathAsync(fileName);
However even if I check everything in capabilities, also File Picker was added and all file types allowed. I still can't access this file, the same exception will be thrown.
Does someone know how to read file in arbitrary file path? Is that possible in metro style application.
Not possible. You can get to the Libraries - pictures, documents, videos - and if the user puts that folder into one of those libraries (using Windows Explorer on the desktop side) you're all set. You can even write a desktop exe that will put the folder into the library, but you can't launch that exe yourself or be sure that the user hasn't changed the libraries by hand.
Look up SHCreateItemInKnownFolder for a starting point to the shell APIs for library work. I haven't tried calling those APIs from the Metro side; you can see if they help but my bet is they will not be available. If you don't like the COM interop to the shell APIs you could look at the source code to the Windows API Code Pack - I wouldn't want to bundle all of it with a Metro app, but you could copy parts of it to your application.
I am writing an application in VB.NET. In the app, I have a function which calls a Powershell script and places the resulting information in a text box.
I have two issues:
How to I ensure that when my app is published, the powershell script is included?
How do I reference the script in my code?
Currently, I simply give my function the full path to the script, which is in a folder on my Desktop. Obviously, this will not work once I deploy the app to other computers.
You will need to create a Setup project to get your script in place on your target system.
A first step is to change the Build Action to Content and Copy to Output Directory to Copy always.
Your Setup project can pick up the script from the VB app build result and put it in place when installing your app.
As for your question concerning the user configurable install path: The easiest way to handle this would be to add registry entry containing the selected program file path and have your app read the path from there.
If I try to build an application with the application class outside the default package, so the application file path is /app/AppClass.mxml instead of /AppClass.mxml (as would normally be the case), Flash builder cannot launch the application for debugging because it is looking for the SWF in debug/app/AppClass.swf and the SWF is being output to debug/AppClass.swf instead. Changing the output folder to debug/app makes it put the swf in debug/app, but then it puts the application configuration file "AppClass-app.xml" in /debug/app/app and then that can't be found.
Is there a way to change only the SWF output folder, or the location of the xml configuration file in the run-configuration?
You may use symbolic link to created swf file - http://en.wikipedia.org/wiki/Symbolic_link
for example for Windows :
cd project/path/bin-debug/package/path/
MKLINK ClassName.swf project/path/bin-debug/ClassName.swf
and it's work
or you can use symbolic link for folder:
cd project/path/bin-debug/package/
MKLINK path project/path/bin-debug/ /D
I think I remember this worked for me. But it was long time ago. And, yes, it is a known problem, I also recall Adobe people mentioning it as a limitation of FB.
In my Ant script, you'll need to do the adjustments to reflect your actual file names and directory structure. Also note that it will make it more cumbersome to debug it from FB. You'll need to use the debugging target in Ant, and then connect the debugger to the running application (so that some info, especially on the startup) will be lost. The only way you would be able to debug it, though I've never tried it, is with the commandline tools (I'm not sure of adl syntax for breakpoints / printing / stack frames, so idk how to do it.
Also, for the released application you will probably want to change the signing mechanism.