I have a strange problem using vb.net (vs2010) and SQLite database: I made an install package with Setup and Deployment project, everything seems to be working fine. My SQLite databse installs under CommonApplicationData folder and the software under ProgramFiles\ProductName. In the setup project I set a custom action, the user have a choice to run software after install:
/StartApp="[CHECK]"
Private Sub MyInstaller_Committed(ByVal sender As Object, ByVal e As InstallEventArgs)
Dim productName As String = Context.Parameters("ProductName")
StartAfterInstall = Me.Context.Parameters.Item("StartApp")
If StartAfterInstall = "1" Then
Directory.SetCurrentDirectory(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location))
Shell(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "\FB.exe")
End If
End Sub
In ApplicationEvents.vb I set at StartUp:
AppDomain.CurrentDomain.SetData("DataDirectory", Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData))
And here comes the strange behaviour: if the user starts application after install, the program connects to another(?) database, not to installed under CommonApplicationData. If the user inserts data, seems everything working fine.
After closing the application and starting new from the desktop/programfiles/users program menu connects the program to the database installed under CommonApplicationData, but he can't see the changes he made launching application after installation. So starting program from desktop/programfiles/users program menu => everything fine, but the first (automatic) start after install is a problem. I can't find out what happens, any ideas?
Has your Installation Administrator-Privileges?
If yes, the following probably happens:
you are writing to ProgramFiles. Windows redirects this to the administrator %appdata%\roaming folder because writing to ProgramFiles is considered bad.
It goes to the administrator account because the installation had administrator-privileges.
When you start your program from the user account, the user-specific %appdata% Folder is used, which is empty.
Do solve that problem:
do not launch your program from the installer.
Create a directory for your program in %appdata% and usw it.
Related
I created a simple bootstrapper for my application using WixSharp.
namespace TestBootstrapper
{
class Program
{
static void Main()
{
var package = new MsiPackage("../testmsi.msi")
{
DisplayInternalUI = true,
Id = "MyId",
Compressed = true,
Visible = true
};
var bootstrapper = new Bundle("MyTestInstaller", package)
{
Version = new Version("1.0.0.0"),
UpgradeCode = new Guid("1FCC927B-7BB0-4FB0-B81E-2D87012E470B"),
PreserveTempFiles = true,
DisableModify = "yes",
DisableRemove = true
};
bootstrapper.Build("Installer.exe");
}
}
}
I logged as admin and installed the application (using Installer.exe) and there were no errors in Event Viewer during installation. When I clicked shortcut the application runs as expected.
If I run testmsi.msi as standard user or admin it installed without any errors and if I clicked shortcut the application runs as expected.
I logged as standard user and installed the application (using Installer.exe). There were no errors in Event Viewer during installation. But when I clicked shortcut installer runs again.
So, why installer runs and how to prevent this behavior?
It's a repair, which may be good or bad depending on what is being re-installed. The application event log should have MsiInstaller entries that say something about what is being repaired. It's not necessarily a bad thing that needs to be prevented.
Assuming you did a per-machine install, if you installed (for example) a file into the User's Application Data folder from your MSI, and then you log on as another user and run the app, then the file is obviously missing for that user. So Windows Installer will do an install for that missing part of the app. The file is probably required for all users of the system, yes? Windows assumes that if you install a file (or registry entry) into a user profile location then everyone that logs on needs this file, so it gets installed by "repair" when another user logs on and uses the shortcut.
There are other scenarios where a repair is not so good. If you do something to remove a file that you installed then Windows will attempt to restore it. If you do a per-user install but then log on as another user and try to use the app that's not an intended use of the product - installer per machine to do that.
I just discovered something that might help -
If you are not installing any programs to the Application directory (for example only installing to Local App data), Windows Installer generates an error message because the Application directory doesn't exist.
If you add ANY file to the Application directory, or create it manually, the shortcut will work properly.
-I have the Connection Strings defined for System.Data.SQLite.SQLiteConnection
-I never configured the RsaProtectedConfigurationProvider so I guess this is the default provider and the code
'Declaration
<PermissionSetAttribute(SecurityAction.Demand, Name := "FullTrust")> _
Public NotInheritable Class RsaProtectedConfigurationProvider _
Inherits ProtectedConfigurationProvider
is not needed
-Instead of using the classic code of
ToggleConfigEncryption
https://msdn.microsoft.com/es-es/library/ms254494(v=vs.110).aspx
I'm using this code when I load the form to encrypt the ConnectionString section:
Dim appconfig As Configuration = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None)
Dim constringsec As ConnectionStringsSection = appconfig.ConnectionStrings
constringsec.SectionInformation.ProtectSection("DataProtectionConfigurationProvider")
Taken from https://juan-cuenca.blogspot.com.uy/2015/01/encriptar-archivos-de-configuracion.html
When I run my app from Visual Studio the program works and I can find on my Debug folder the file
myApp.exe.xml and also the file myApp.vshost.exe.xml are both with
<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sB....
</CipherData>
</EncryptedData>
So I think the encryption is working fine at Debugging time.
The problem:
-When I publish my app on my web server and then install the app like any Windows app the program still works, but on my C:\Users\MyUserName\AppData\Local\Apps\2.0\
the file myApp.exe.xml is still with plain text on the ConnectionString section.
(And the other file myApp.vshost.exe.xml is not there)
Do I need to do something more on the code or Publish configuration?? (Maybe one "after install" code?)
Or is something about Windows permissions?
Update info
Well now It's working but with a extrange behavior. 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?
I'm using c#, .net 4, WIX 3.5, Windows Vista.
I have made my application compatible with RestartManager by p/invoking the RegisterApplicationRestart method and by handling the WM_QUERYENDSESSION and WM_ENDSESSION window messages (I return new IntPtr(1);).
If I try to update my application manually, then everything works as it should:
Launch application;
Launch msi file containing new app version;
During the installation/update, I'm prompted to close the running application;
Upon continuing the running app is closed, install completes, and the app is restarted;
If I try to update my application from the application itself, then I run into problems:
1) Launch application;
2) Download the new msi file;
3) Launch msi file with:
using (System.Diagnostics.Process p = new System.Diagnostics.Process())
{
p.StartInfo.UseShellExecute = false;
p.StartInfo.FileName = "msiexec";
p.StartInfo.Arguments = "/i \"" + downloadPath + "\" /passive";
p.StartInfo.UserName = "Administrator";
p.StartInfo.Password = securePassword;
p.Start();
}
4) Because I'm using passive mode, the application is closed automatically;
5) After the installation, my application is not restarted and under Event Viewer I have an
Event 10007 - Application or service 'MyApp' could not be restarted.
I have tried:
Not to use passive mode for msiexec;
Launch msiexec via cmd.exe (cmd.exe /C "msiexec /i ....") - in the hopes that launching msiexec from another process would solve the problem;
Wait for 60+ seconds before launching the msi update (shouldn't be relevant in my scenario, but MSDN documentation has something about it...)
But none of the above has worked (always the same result).
Having to launch the setup with elevated permissions might have something to do with the issue, because during the manual update I get a warning in the Event Viewer - Application MyApp (pid 3220) cannot be restarted - Application SID does not match Conductor SID.
Despite this, restarting the app still works. Googleing the warning yields no good/specific results, only that this warning is probably caused by running the msi in an elevated prompt.
How do I fix (or workaround) this issue, so that I can update my application from the application itself and restart my application afterwards?
Edit - extra testing:
There doesn't seem to be a need to respond to WM_QUERYENDSESSION and WM_ENDSESSION messages, because application restart during a manual upgrade works without them, so we can rule them out;
If I don't provide administrator credentials to the application initiated upgrade and instead I type them in during the upgrade, then app restarting works;
If I run an elevated command prompt and initiate an application upgrade from there (manually), then app restarting still works;
In order for application upgrade to work at all under Standard user accounts (so far I tested under an Administrator account with UAC), then I also have to set p.StartInfo.LoadUserProfile = true;. Otherwise nothing happens. (application restart still doesn't work though);
I tried all other process StartInfo parameters that I could set - WorkingDirectory, Redirect, Verb
(= "runas") - no change in results;
I installed Vista SP2 onto the virtual machine that I have been testing on (so far ran SP1), but no change;
I performed an "automatic" application upgrade with verbose logging. In the end there was an error message - RESTART MANAGER: Failed while restarting applications. Error: 352. That error code is very generic (http://msdn.microsoft.com/cs-cz/library/aa373665), inorder to get more detailed info I would have to write my own installer that would call RmGetList after the error, then I might get more details (this though is something I'm not willing to do);
Edit 2 - msi log file:
http://mommi.planet.ee/muu/log.txt
Assuming that the manual process indeed works without any problem it seems that your need for Administrator privileges in combination with the "updating itself" leads to these problems. I see the following options:
create a batch file to execute the update
When you want to update call this batch file (with elevated privileges), make the app close itself... the batch file should wait some seconds, then check whether the app is still running (and close it in case) and then run the commandline you need to run msiexec - don't restart the app from within msiexec but after a successfull run of msiexec from the batch file.
create a batch file which is always used to start the app
When the time comes to update you just end the app. Either the batch file check for an available update and applies it, starting the app after successfull update OR the app set some environment variable which is then accordingly processed by the rest of the batch file.
I have a ClickOnce application that about 120 customers are using. This week, I found out two customers declined an update in January and were stuck on an old version. I discovered this by deleting an ASP script the old versions used on our server. The customers that aren't updating get a 404 and call to ask why.
One customer clicked our install button again and got the latest version no problem. The other clicked our install button and gets an "Application validation did not succeed" error. The details of the error are SomeImage.gif "has a different computed hash than specified in manifest."
I don't want to deploy a new version because that usually results in phone calls asking, "did you add what I asked for yet?"
I figure I should be able to uninstall the application completely and resintall with the one problem user. Nope. The error persists. How can I remove whatever the Windows uninstall process leaves behind that would cause this error to persist?
Update:
I found the folder C:\Users\User\AppData\Local\Apps\2.0 on the customer's Windows Vista computer, and deleted it. We ran the installer again, and the error persisted after redownloading the application. I'm not 100% confident that this folder contained the whole program, though, but it is the only location on disk I could find that contained some resemblance of our application.
Track down mage.exe in the Visual Studio tools folder (C:\Program Files\Microsoft SDKS\Windows\v7.0A\bin). Copy it to the user's computer. Try this:
mage.exe -cc
This clears the ClickOnce applications. I would also delete the \apps\2.0 folder AFTER you do this -- this is the cache created and used by ClickOnce applications.
Then reboot the computer.
This may or may not help. My error messages weren't exactly as you describe, but I was eventually able to remove the final traces on my machine by going to:
HKEY_CLASSES_ROOT\Software\Microsoft\Windows\CurrentVersion\Deployment\SideBySide\2.0
I deleted all grandchild keys that bore names similar to my application. After that I was able to install and run the latest version.
This is on Windows 7 64 bit.
Try doing a "Clean Solution" and then doing another Build. If you publish without incrementing the version number I don't think existing installs will get an update message.
If you've already run the uninstall and it hasn't sorted it, try deleting the files in
C:\Documents and Settings\<userName>\Application Data\
You'll have to do some looking around to find your application, but it shouldn't be too hard.
In the past I've used the below code to avoid the users having to click the update button, this will install it without them even knowing.
Private Shared Function UpdatedApp(ByVal AppLog As Logger) As Boolean
Try
' Check to see that this program has been delpoyed
If Deployment.Application.ApplicationDeployment.IsNetworkDeployed Then
Dim CurrApp As System.Deployment.Application.ApplicationDeployment = System.Deployment.Application.ApplicationDeployment.CurrentDeployment
AppLog.WriteLine("Application Version : {0}", CurrApp.CurrentVersion)
AppLog.WriteLine("Checking for updates")
' If theres a update then Install it
If CurrApp.CheckForUpdate() Then
AppLog.WriteLine("An updated version is available. This update will now be applied.")
' Update the app to the current version
CurrApp.Update()
' Upgrade the settings (that is, the connection string).
My.Settings.Upgrade()
AppLog.WriteLine("Version {0} is now installed, the application will now restart", CurrApp.UpdatedVersion)
Return True
End If
Else
AppLog.WriteLine("Application version: *Dev Version*")
End If
Catch ex As Exception
AppLog.WriteLine("The application is unable to check for updates. The program will execute on a possibly outdated version. Error {0}", ex.ToString)
End Try
' Always return false unless the update has been applied (even if the update throws an error)
Return False
End Function
Have you attempted to rollback a version with the ClickOnce Application? You can do this when you got to the Programs and Features and then uninstall on your app.
This should then leave your App in a state where it would then request the latest update again.
I'm trying to run some VBSCRIPT from within my application. This works fine when I run my program from within VB. But once I add "UIAccess=true" to my manifest and digitally sign my exe with my certificate, I am unable to run the code any more. It gives errors when I try to interface with any program saying "429: ActiveX component can't create object: 'myApp.Application'". Anyone have any idea why it would run fine in the IDE but not with an application with uses UIAccess? Here is the code:
Dim scriptRunner As New MSScriptControl.ScriptControlClass
scriptRunner.Language = "VBScript"
scriptRunner.AllowUI = True
scriptRunner.Timeout = 3000
scriptRunner.AddCode(scriptStr)
scriptRunner = Nothing
In googling around, I found this website.
it says
Applications with the uiAccess flag set to true must be Authenticode signed to start properly. In addition, the application must reside in a protected location in the file system. \Program Files\ and \windows\system32\ are currently the two allowable protected locations.
maybe it works in your IDE because your IDE is within \program Files\, but outside of your IDE you are running the signed application NOT within \program files or \windows\system32