I have tried to create a custom action for a Visual Studio Installer project to modify the permissions for a config file.
The Installer.cs is as follows:
public override void Commit(IDictionary savedState)
{
base.Commit(savedState);
// Get path of our installation (e.g. TARGETDIR)
//string configPath = System.IO.Path.GetDirectoryName(Context.Parameters["AssemblyPath"]) + #"\config.xml";
string configPath = #"C:\Program Files\Blueberry\Serial Number Reservation\config.xml";
// Get a FileSecurity object that represents the current security settings.
FileSecurity fSecurity = File.GetAccessControl(configPath);
//Get SID for 'Everyone' - WellKnownSidType works in non-english systems
SecurityIdentifier everyone = new SecurityIdentifier(WellKnownSidType.WorldSid, null);
// Add the FileSystemAccessRule to the security settings.
fSecurity.AddAccessRule(new FileSystemAccessRule(everyone, FileSystemRights.Modify | FileSystemRights.Synchronize, InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit, PropagationFlags.None, AccessControlType.Allow));
// Set the new access settings.
File.SetAccessControl(configPath, fSecurity);
}
public override void Install(IDictionary stateSaver)
{
base.Install(stateSaver);
}
public override void Rollback(IDictionary savedState)
{
base.Rollback(savedState);
}
public override void Uninstall(IDictionary savedState)
{
base.Uninstall(savedState);
}
Then I add the Primary Output (Installer class = true) into the Commit section of the setup project's Custom Actions.
When I run the installer, I get the following error:
Error 1001: Could not find file 'c:\mypath\myapp.InstallState'
Scouring the web I've found a few examples of similar experiences, but none of the solutions offered have worked for me.
Any ideas?
You can find a solution here
To quote:
The problem is that the MSI infrastructure is looking for the installation state file which is usually created during the Install
phase. If the custom action does not participate in the Install phase,
no file is created.
The solution is to add the custom action to both the Install and the
Commit phases, although it does nothing during the install phase.
I had this problem when I didn't specify a custom action in my installer project for all four overrides (Install, Uninstall, Commit, and Rollback). As soon as I specified my project output as the custom action for all four, the issue went away.
The only overrides in my installer class that did anything were Commit and Uninstall; I think that Install was in charge of creating the InstallState file in the first place, and since it was never called the InstallState file was never created.
Sometimes this happens when the installer class is not created correctly. Here is a tutorial which may help you: http://devcity.net/Articles/339/1/article.aspx
Make sure that your custom action follows the tutorial recommendations.
Sometimes, "Debugger.Launch();" is put at those overwritten functions for debugging. If you build the installer with the statement there, and during your installation, a dialog will popup to ask you whether debug is needed, if you press 'cancel debugging', you'll get this error dialog. Because you added the 'Debugger.Launch()' at your function, then that function will be considered as 'missed' by installer. So, don't forget to remove it.
Try installing this as in an administrator command prompt. This worked for me.!
For me, the issue was as simple as just adding a closing quote around one of the textbox names in my CustomActionData string.
I was using the "Textboxes (A)" and "Textboxes (B)" windows in the User Interface section. A has 1 box, EDITA1, where I get the path to a file, and B has 2 boxes, EDITB1 and EDITB2, for some database parameters. My CustomActionData string looked like this:
/filepath="[EDITA1]" /host="[EDITB1] /port="[EDITB2]"
It should have been:
/filepath="[EDITA1]" /host="[EDITB1]" /port="[EDITB2]"
(closing quote on [EDITB1])
I used the Install override in my Installer class to get the values (i.e. string filepath = Context.Parameters["filepath"];) and used it to write them to an INI file for my app to use once installed. I put the "Primary output" under all of the phases in the Custom Actions GUI, but did nothing with the InstallerClass property (default: True) and only set the CustomActionData string on the Install one. I didn't even include override functions in my Installer class, since I was doing nothing that was custom in the other phases.
create your post install executable as you would a console app ex: "mypostinstallapp.exe".
install the "mypostinstallapp.exe" with your msi product. maybe put it with the Application Folder or a shared folder if you want to use it with multiple installs.
in the custom actions (rightclick the msi project and view custom actions) and add an action in the Commit section. assuming you want it to run towards the end.
then select your "mypostinstallapp.exe" from the actions view and in its properties set InstallerClass False.
what I do in "mypostinstallapp.exe" is look for a cmd file and run it as a process.
so i can add stuff to the cmd file and try to forget about the custom action process.
Make sure in the output properties you check installer class to false
You can set a register key to the installation path. Click on the Setup Project, View Register, and set the value as: [ProgramFiles64Folder][Manufacturer][ProductName].
Then you can create a Console App to get in to the register and take this information and run your program. Just need to add as a custom action on Commit the Console App you created.
Try setting Installer class = false instead of true in the properties for your custom action. That fixed this problem for me.
Related
I have a C# console application that is deployed on client machines. While deploying in client machine I get System.TypeInitializationException.
In debug.log, I get the following errors:
Unable to locate required Cef/CefSharp dependencies:
Missing:CefSharp.BrowserSubprocess.exe
Missing:CefSharp.BrowserSubprocess.Core.dll
Missing:CefSharp.Core.dll
Missing:CefSharp.dll
Missing:icudtl.dat
Missing:libcef.dll
Executing Assembly Path:C:\myapp
The problem is that all files are present in the C:\myapp directory (as specified here). Therefore, I'm not sure why these files aren't being loaded up. Also msvcp120.dll, msvcr120.dll, vccorlib120.dll included in c:\myapp directory
As many people, I followed the steps in the official Quick Start article to setup the "Any CPU" configuration and I had the same problem with missing dependencies when performDependencyCheck was on.
This is because the article is actually incomplete!
For the "Any CPU" configuration to work, you need to follow all the steps in Feature Request - Add AnyCPU Support #1714 (especially the last one!):
Add <probing privatePath="x86"/> to your app.config as outlined in https://msdn.microsoft.com/en-us/library/4191fzwb.aspx
Set Prefer 32bit in your project properties see http://blogs.microsoft.co.il/sasha/2012/04/04/what-anycpu-really-means-as-of-net-45-and-visual-studio-11/
for some background
Set settings.BrowserSubprocessPath = #"x86\CefSharp.BrowserSubprocess.exe"; when calling
Cef.Initialize
example below:
[STAThread]
public static void Main()
{
var settings = new CefSettings();
settings.BrowserSubprocessPath = #"x86\CefSharp.BrowserSubprocess.exe";
Cef.Initialize(settings, performDependencyCheck: false, browserProcessHandler: null);
var browser = new BrowserForm();
Application.Run(browser);
}
Note: when using this code, I would still advise you to use performDependencyCheck: true since it will now report only genuine errors.
I meet the same problem today.
My CEFSharp program works fine when only opening my program, but it's failed when open the associating files.
When I double click to open an associating format file (eg: JPG format file), the application startup fails because of "Unable to locate required Cef/CefSharp dependencies" error.
I tried to set "performDependencyCheck: false", it works when right clicking to choose the My program to open the file. But when double click the jpeg file, the error still stay.
Then I tried to set the current directory to execute file path, it looks works, I think this issue rootcause sometimes is related with the current working folder not right.
private static void Main(string[] args)
{
try
{
string exeDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
if (exeDir != null)
{
Directory.SetCurrentDirectory(exeDir);
}
if (!Cef.Initialize(settings, performDependencyCheck: false, browserProcessHandler: browserProcessHandler))
{
throw new Exception("Unable to Initialize Cef");
}
I had the same issue. first I saw that the Cef.Initialize() function just don't work, so I enabled the performDependencyCheck option like this:
Cef.Initialize(BrowserSettings, performDependencyCheck: true, browserProcessHandler: null);
(According to this example https://github.com/cefsharp/CefSharp.MinimalExample/blob/master/CefSharp.MinimalExample.OffScreen/Program.cs)
and I saw I am missing some files.
Afterwards, the error kept showing up, even though I don't miss anything. so i disabled the performDependencyCheck option and it worked.(like this:
Cef.Initialize(settings, performDependencyCheck: false, browserProcessHandler: null);
Hope it will help you.
I've encountered a problem when I try to retrieve the valid states of all features within an MSI package using the Microsoft.Deployment.WindowsInstaller.Installer class.
I want to copy the ValidStates property of each FeatureInfo within a Session. However when doing so I get a "Handle is in an invalid state." exception.
If I print each of these values out using Console.WriteLine() or step through the code in Visual Studio there is no exception.
I am at a loss as to what is preventing me from doing this.
Thanks in advance!
My Code:
var featureDictionary = new Dictionary<string, string[]>();
if (string.IsNullOrWhiteSpace(mPath))
return featureDictionary;
try
{
Installer.SetInternalUI(InstallUIOptions.Silent);
using (var session = Installer.OpenPackage(mPath, true))
{
foreach (var feature in session.Features)
{
try
{
var states = feature.ValidStates.Select((state) => state.ToString());
featureDictionary.Add(feature.Name, states.ToArray());
}
catch (InstallerException ex)
{
Debug.WriteLine(ex.Message);
}
}
}
}
catch (InstallerException) { }
return featureDictionary;
The basic problem appears to be that you are opening the MSI as a file. Since you haven't posted its declaration, or how it is set, I'm assuming that mpath means it's a path to the file. Your OpenPackage method parameters seem to indicate this too. You're getting that error because you are trying to open the MSI file as a file during the actual install, and failing.
The way to get hold of the database for the running install is to use Session.Database.
You can't open the running MSI as a file during the install perhaps for the same reason you can't run an MSI file that you have open with Orca, a simple file sharing violation. When you step through with Visual Studio you're simply accessing the static file and getting default values and the file isn't being used for an install. The other issue is that there can only be one Session object per process (as the OpenPackage docs say) and you are attempting to get a second one while there is already a Session object associated with the handle of the install.
As a custom action it needs to be sequenced after CostFinalize.
Windows Installer conditional expressions such as !feature-state will tell you what state the feature is in, because it's usually better to avoid code where Windows Installer will just give you the answer.
I am new to the WiX installer.
I am using Session.Log to log some useful data for the process.
session.Log("Begin register the Vdds interface.");
But I am not sure where can find the log. Is there a default path where it logs? Or should I need to specify the path that I need to provide in installer .wxs file?
You will need to run your installer from the command line using msiexec.exe and then include the L command line option to specify where the logs are to be saved.
For example:
msiexec /i app.msi /l*v thelog.txt
For more information about msiexec's parameters see Command-Line Options
Session.Log adds your log to the standard MSI Log. In case you provided the /l*v <LogPath> switch during execution, logs of custom action would be found in LogPath.
In case you used Property MsiLogging with value as vx in installer,
it would generate Standard MSI Log in user temp location (type %temp% in run), with LogName looking like MSI*.LOG, automatically even without the /L*v switch. LogPath could be overridden though with the /L*v switch.
Things you must know:
session.Log does not log when executed by any UI action.
Sometimes the installer cannot generate the MSI* log because of memory leak issues. In this scenario, you could restart the explorer.exe process.
session.Log works like session.Message with Info level:
public void Log(string msg)
{
if (msg == null)
throw new ArgumentNullException("msg");
using (Record record = new Record(0))
{
record.FormatString = msg;
int num = (int) this.Message(InstallMessage.Info, record);
}
}
You can use dirty trick: define a property in the referencing module and set its value in CA to a message You want to log. It seems that WIX logs changes of properties:
<Property Id="WIX_MAGIX_TRICK_PROPERTY" Value="0" />
and in CA:
session["WIX_MAGIX_TRICK_PROPERTY"] = "message to log";
The result should be similar to this:
MSI (c) (78!34) [09:48:13:770]: PROPERTY CHANGE: Modifying WIX_MAGIX_TRICK_PROPERTY property. Its current value is '0'. Its new value: 'message to log'.
Running the msi with the arguments: /L!*vx solved this for me.
E.g.
msiexec /i MyMsi.msi /L!*vx install.log
Now all my calls to Session.Log("..") now show in install.log
I am not sure where session.Log logs messages. However session.Message:
Record record = new Record();
record.FormatString = string.Format("Something has gone right!");
session.Message(InstallMessage.Info, record);
shows up in the log file generated by:
msiexec /i app.msi /l*v thelog.txt
It is sometimes desirable to have your application open the default application for a file. For example, to open a PDF file you might use:
System.Diagnostics.Process.Start("Filename.pdf");
To open an image, you'd just use the same code with a different filename:
System.Diagnostics.Process.Start("Filename.gif");
Some extensions (.gif for example) just about always have a default handler, even in a base Windows installation. However, some extensions (.pdf for example) often don't have an application installed to handle them.
In these cases, it'd be desirable to determine if an application is associated with the extension of the file you wish to open before you make the call to Process.Start(fileName).
I'm wondering how you might best implement something like this:
static bool ApplicationAssociated(string extension)
{
var extensionHasAssociatedApplication = false;
var condition = // Determine if there is an application installed that is associated with the provided file extension.;
if (condition)
{
extensionHasAssociatedApplication = true;
}
return extensionHasAssociatedApplication;
}
I would recommend following the advice in David's answer BUT since you need to detect an association:
To check whether a file has an association you can use the native function FindExecutable which is basically what Windows Explorer uses internally... it gives a nice error code (SE_ERR_NOASSOC) if there is no association. Upon success it gives a path to the respective executable.
Thee DllImport for it is
[DllImport("shell32.dll")]
static extern int FindExecutable(string lpFile, string lpDirectory, [Out] StringBuilder lpResult);
Another option would be to walk the registry for example (not recommended since complex due to several aspets like WoW64 etc.):
The real association is stored in the key that HKEY_CLASSES_ROOT\.pdf points to - in my case AcroExch.Document, so we checkoutHKEY_CLASSES_ROOT\AcroExch.Document. There you can see (and change) what command is going to be used to launch that type of file:
HKEY_CLASSES_ROOT\AcroExch.Document\shell\open\command
#Yahia gets the nod. I'm posting my quick solution for posterity so you can see what I went with. There are lots of possible improvements to this code, but this will give you the idea:
public static bool HasExecutable(string path)
{
var executable = FindExecutable(path);
return !string.IsNullOrEmpty(executable);
}
private static string FindExecutable(string path)
{
var executable = new StringBuilder(1024);
FindExecutable(path, string.Empty, executable);
return executable.ToString();
}
[DllImport("shell32.dll", EntryPoint = "FindExecutable")]
private static extern long FindExecutable(string lpFile, string lpDirectory, StringBuilder lpResult);
In a situation like this the best approach is to try to open the document and detect failure. Trying to predict whether or not a file association is in place just leads to you reimplementing the shell execute APIs. It's very hard to get that exactly right and rather needless since they already exist!
You will have too look at the registry to get that information.
You can follow from:
HKEY_CLASSES_ROOT\.extension
and it usually leads to something like HKEY_CLASSES_ROOT\extfile\Shell\Open\Command
and you will come to the command to open the file type.
Depending on what you are doing, it may be ideal to just ask for forgiveness ( that is, just open the file and see)
All of that information lives in the registry.. you could navigate to HKEY_CLASSES_ROOT, find the extension and go from there to find the default handler. But depending on the type of file and the associated handler(s) you'll need to wade into CLSIDs and whatnot... you're probably better off catching an exception instead.
This information is in the registry. For example:
# Mount the HKCR drive in powershell
ps c:\> new-psdrive hkcr registry hkey_classes_root
ps c:\> cd hkcr:\.cs
# get default key for .cs
PS hkcr:\.cs> gp . ""
(default) : VisualStudio.cs.10.0
...
# dereference the "open" verb
PS hkcr:\.cs> dir ..\VisualStudio.cs.10.0\shell\open
Hive: hkey_classes_root\VisualStudio.cs.10.0\shell\open
Name Property
---- --------
Command (default) : "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" /dde
ddeexec (default) : Open("%1")
I have a c# program which open *.postfix file.
If a user runs a (.lnk)shortcut which points to my type of file, my program will open the target.
So, how could my program know it is started by a (.lnk)shortcut (and get it's file path)?
In some circumstances,i need to replace the .lnk file.
Thanks!
Edited
First, thanks to guys who answered my question.
By following #Anders answer, i find out my problem lays here.
I made some changes to windows registry, so browser knows to throw customized protocol string to certain program.
some thing like this..
[InternetShortcut]
URL=myProtocol://abcdefg.....
That's maybe why i lost lpTitle. :(
I'm going to try this way:
Whenever my program invoked, of course fed with %1, program checks current opened explorer(Window), and try to get it's current path with IWebBrowserApp. With that path and desktop of course, scan and analyze *.lnk to determine which one to replace.
I think this will probably work, but not be sure. I will try.
continued
In native code you can call GetStartupInfo, if the STARTF_TITLEISLINKNAME bit is set in STARTUPINFO.dwFlags then the path to the .lnk is in STARTUPINFO.lpTitle. I don't know if there is a .NET way to get this info, you probably have to P/Invoke...
You don't. There's no way to do it. End of story.
So this has been brought to my attention due to a recent downvote. There's an accepted answer showing an idea that gets the path to the launching shortcut most of the time. However my answer is to the whole. OP wants the link to the shortcut so he can change it. That is what can't be done most of the time.
Most likely case is the shortcut file exists in the start menu but is unwritable. However other cases involve the shortcut coming from another launching application that didn't even read it from a disk but from a database (I've seen a lot of corporate level restricted application launch tools). I also have a program that launches programs from shortcuts not via IShellLink but by parsing the .lnk file (because it must not start COM for reasons) and launching the program contained. It doesn't pass STARTF_TITLEISLINKNAME because it's passing an actual title.
If you're using Visual Studio Setup Project to build an installer and do the file type association, you should follow these instructions http://www.dreamincode.net/forums/topic/58005-file-associations-in-visual-studio/
Open up your solution in Visual studio.
Add a Setup Project to your solution by file , add project,New project, Setup & Deployment projects,Setup project
Right-click on your setup project in the "Solution Explorer" window,Select view,then select file types.
you'll see the "file types" window displayed in Visual studio.At the top of the window will be "File types on target machine"
Right-click on "File types on target machine".the menu will pop up with Add "file type" Click on this.
you'll see "New document Type#1" added,and "&open"underneath it.
The "new document type#1" can be anything you want - change it to something descriptive.although the user never sees this,never use something common- be as unique as possible,Because you can overlay current file associations without even realizing it.For example,you might think"pngfile" might be a useful name- but using that will now send all"*.png" files to your application,instead of to an image viewer.A good practice maybe "YourCompantName.Filetype",where your company name is your name of your company's name, and "Filetype" is a descriptive text of your file.
In the "properties" window for your new type,you will need to change a few properties.:
Command:Change to the application that you want to run.If you click on the "..." and you will proberly want to locate and use the "primary Output..." File
Description: This is the description of the file type(if it doesn't describe it's self"
Extensions:This your list of extensions for you chosen Program.Separate each one with a ","
Icon:This will associate the icon with your file type,This shows up in the window explorer.
Now we move to that "&open ".This is an action that is available if your right-click on the file.The default action("&Open" is currently set as the default) is what happens when you double click on the file.Right click on your "New document type#1" to add actions,but for the moment,lets define our "&open" action
Click on "&Open".You will see in the properties window "Name","Arguments","Verbs". Verb is hidden from the user,but is the key that is stored in the registry.Leave it same as the name,But without the "&".The default for"Arguments" is "%1",Which means to pass the full path and filename to your application.You can add other stuff here as well,if you need to pass flags to your application to do special stuff.All this infomaton is getting passed to your application on the command line,so you'll need to be familiar with the "Environment.CommandLine" object.
If you need to set a different action as your default,just right click on the action and "set as default"
Basically, you'll pass the file path as an argument to your program. Then if it's a console application or Windows Forms , you should check the arguments in Program.Main
static void Main(string[] args)
{
//if file association done with Arguments %1 as per forum post above
//you file path should be in args[0]
string filePath = null;
if(args != null && args.Length > 0)
filePath = args[0];
}
For a WPF application you'll need to handle that in the StartUp event for your Application
void App_Startup(object sender, StartupEventArgs e)
{
string filePath = null;
if ((e.Args != null) && (e.Args.Length > 0))
{
filePath = e.Args[0];
}
}