I would like to read these three values from my application.exe in my Inno Setup script.
[assembly: AssemblyCompany("My Company")]
[assembly: AssemblyProduct("My Great Application")]
[assembly: AssemblyFileVersion("9.3.2")]
Does anyone know how this might be accomplished?
I know I can get the last one using GetFileVersion("path/to/greatapp.exe")
is there something similar for the first two?
Use the GetStringFileInfo() function provided by the Inno Setup Preprocessor (ISPP) as follows:
GetStringFileInfo("path/to/greatapp.exe", "CompanyName")
GetStringFileInfo("path/to/greatapp.exe", "ProductName")
GetStringFileInfo("path/to/greatapp.exe", "FileVersion")
As you have already mentioned, you can use the GetFileVersion() function instead of #3 above.
Also, have a look at the ISPPBuiltins.iss script file included with your Inno Setup installation. It contains a GetFileCompany() function to use instead of #1 above and you can implement #2 above in a similar fashion.
I dont know Inno Setup but I guess it supports custom actions like the other setup tools (Visual Studio, Wix, InstallShield or Wise).
So, you will need to create a custom action to read this information from the assembly. In your custom action, you need to add the following code to fetch the assembly attributes:
Assembly assembly = Assembly.LoadFrom (#"path\to\greatapp.exe");
object[] attributes = assembly.GetCustomAttributes(true);
if (attributes.Length > 0)
{
foreach (object o in attibutes)
{
//Do Something with the attribute
}
}
Related
I was just trying out the Windows app sample for the Recipe Property Handler which is available here and I modified it to be used on .doc files instead of .recipe files:
const WCHAR c_szRecipeFileExtension[] = L".doc";
But, this seemed to overwrite the previous Office handler's properties with itself, which begs the question, does the Windows shell support multiple shell property handlers, or can you only use one at a time for a given file type? If its possible, what am I missing from the code or logic in the sample?
I couldn't find a concrete answer on MSDN for this question.
No.
But there is a variant you can use (I dont like it but I dont see any additional variant). Save previous Property handler CLSID when you register your own. And when shell request the property that you cannot process - just create instance of previous handler and pass request to them.
CoCreateInstance(SavedCLSID, nil, CLSCTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IPropertyStore, PS)
PS.QueryInterface(IInitializeWithStream, IWS)
IWS.Initialize(Stream, Mode)
PS.GetValue(AUnknownKey)
I've just created a custom dialog with a checkbox asking if the user wants to create a desktop shortcut. I used to always include a shortcut I'm not using the AskText() function as I plan on adding more pieces to this page later and want to simplify these few options to this one page.
I get an item on my desktop when I run, but it's not what I expect. The target seems to be pointing to a location on the desktop itself and not the actual executable. Also, this shortcut does not delete on uninstall (I'm assuming this needs to be handled separately anyway) and the shortcut needs admin rights to be manually deleted (which I don't want, for obvious reasons).
Below is my InstallScript code. It is in a custom action that was inserted after InstallFiles.
function MyFunction(hMSI)
STRING szProgramFolder, szItemName, szCommandLine, szWorkingDir;
STRING szShortCutKey, szProgram, szParam, szIconPath;
NUMBER nIcon, nResult;
begin
szProgramFolder = FOLDER_DESKTOP;
szItemName = "myProgram";
szProgram = INSTALLDIR + "myProgram.exe" ;
LongPathToQuote (szProgram, TRUE);
szCommandLine = szProgram;
szWorkingDir = INSTALLDIR;
szIconPath = "";
nIcon = 0;
szShortCutKey = "";
nResult = AddFolderIcon (szProgramFolder, szItemName, szCommandLine,szWorkingDir,
szIconPath, nIcon, szShortCutKey, REPLACE);
end;
I'm not quite sure where I'm going wrong here, although my knowledge of InstallShield (let alone InstallScript) is very limited.
As it turned out, this is a deferred custom action, hence the INSTALLDIR variable is not initialized (nor any other Windows Installer built-in variables). Change it to an Immediate-type custom action (and relocate it to an appropriate location in the execution sequence) and it should work.
To fix the shortcut's parameters, start by ensuring they are correct. Debug your function to verify you are actually passing what you want to. As commented, INSTALLDIR may not be available directly to an InstallScript custom action. A simple way to "debug" would be to add calls like MessageBox(szCommandLine, 0); to key points in your code. If you find you are passing something like C:\Program Files\Company\ProductmyProgram.exe, consider using the ^ operator to concatenate your paths: szProgram = INSTALLDIR ^ "myProgram.exe";.
To uninstall the shortcut, you have to understand that custom actions in MSI projects are not automatically reversed. So use a different approach. Either explicitly code up its removal during uninstall in another action, switch to pure InstallScript where logging will reverse your actions, or go with a proper MSI-based approach. For the last of those, define the shortcut in its own component, and give the component a condition that correlates to a property you set in your UI (or via AskText for now), or skip the condition and just use feature selection by putting the component in a child feature. Then Windows Installer will track and remove the shortcut for you.
I am creating a new module in Prestashop 1.6 which displays some data on the products page in the info box. I have created a new hook in the install method of the module like this: $this->registerHook('combinationDescription') and created the hookDisplayCombinationDescription function for assigning some smarty variables and displaying them with a tpl file.
After installing my module the hook is registered into the database so its usable.
Manually I can insert code into the product.tpl file just like: {hook h="hookDisplayCombinationDescription"} and I think it's working, but I would like to make this step automatically when the module gets installed. How can I do that?
My guess would be that to edit the product.tpl file from the install method of the module but it's a bit dirty method for me. Is there some other nice way to do that?
If you made a custom hook you need to insert its execution somewhere manually: into .tpl or into overrided ProductController.php (if it is an action hook). Prestashop can't execute it automatically for it doesn't know where do you want to execute it.
But you can use the default Prestashop 1.6 hooks to make your part of the code hooked and ready after the module installation. For the product page are these:
displayLeftColumnProduct
displayRightColumnProduct
displayProductTab
displayProductTabContent
displayFooterProduct
displayProductButtons
displayProductPriceBlock
actionProductOutOfStock
You can use one of these hooks and position your content with css (or javascript - to any part of the page).
If you make any custom hook then you have to make it executable first.Prestashop can't execute custom hooks automatically.But for displaying some data on product page you can use predefined prestashop hooks.Some are following
displayProductButtons
displayProductTab
To use these hooks, first you have to register hooks in install function like
public function install()
{
if (!parent::install() || !$this->registerHook('displayProductButtons')){
}
}
and in the same file you have to make a function like
public function hookDisplayProductButtons($params)
{
}
Now in that function you can assign some smarty variables which you want to access or show in your tpl file like
public function hookDisplayProductButtons($params)
{
$this->smarty->assign(array(
'product_name' => 'abc'
));
}
Now in your tpl file you can access that
If you want to add new custom hook and execute them when your particular module is active or installed.
Please follow the following steps:
Add you new custom hook code any where you want to perform your action.
Then, you can insert entry for that new custom hook into database at the time of installing module.
Now, your hook will execute as per your need.
Delete the same entry of hook from database at the time of uninstalling module so that hook could not be executed after uninstalling module.
I am not sure for, Is any other solution available to fulfill your need in prestashop?
I am using MsiGetProperty to get string parameter value from the installer.
And after that I am calling a managed dll and I pass the that value:
nvBufferSize = MAX_STRING;
MsiGetProperty (hMSI, "DBHMS", sDbHost, nvBufferSize);
when I pass the value of sDbHost is like this when I receive it from managed code:
srvdata-02NULNULNULNULNULNUL......
however in the interface I wrote just "srvdata-02".
With that same code it was fine with Installshield 2010, now I am upgrading it to installshield 2012.
Do you have any solution with that please?
There were some behavior changes to MsiGetProperty awhile back. Try setting nvBufferSize to MAX_SIZE instead of MAX_STRING. Also check the return code of MsiGetProperty to see if it equals ERROR_MORE_DATA or if it's returning some other code. Finally check the value of nvBufferSize to see how many bytes are needed.
BTW, if you are just trying to marshal a property over to managed code, you might want to conisder looking into Deployment Tools Framework (DTF) in Windows Installer XML (WiX). This is a very nice SDK that allows you to write managed code custom actions and package them up as if they are native Win32 libraries. InstallShield can then easily use this as an MSI DLL custom action.
DTF provides an interop library and a session object that can be used like:
Deployment Tools Foundation (DTF) Managed Custom Actions
Reasons DTF is Better
As ridiculous as it may seem, here's a working InstallScript solution for you:
nvBufferSize = MAX_STRING;
nResult = MsiGetProperty( ISMSI_HANDLE, szPropertyName, svValue, nvBufferSize );
if( nResult = ERROR_MORE_DATA ) then
MsiGetProperty( ISMSI_HANDLE, szPropertyName, svValue, nvBufferSize );
endif;
The first attempt returns the actual buffer size needed. If it is more then max string (1024?), the second call gets the whole thing.
Alternatively, I found I could assign nvBufferSize to larger value right off the bat e.g. 4096 and use that with a single call (assuming the data was no longer that limit). The double call, however, is more fool proof.
According to: https://msdn.microsoft.com/en-us/library/aa370134(v=vs.85).aspx the api function is actually designed to return the buffersize by passing an empty literal ("") instead of a string variable. InstallScript 2013 throws a compilation error at you if you try that though...
I'm totally new to this gradle, teamcity and groovy.
I'm tryign to write a plugin,which will get the value from svninfo. If the developer wants to override the value(in build.gradle) they can override something like this.
globalVariables{
virtualRepo = "virtualRepo"
baseName = "baseName"
version = "version"
group = "group"
}
Here i provide the extension called globalvariable.
Now, The jars to be produced shd hav the name according to the values from the build.gradle..
How to get the value from build.gradle in the plugin inorder name the jar???
Not sure I understand the question. It's the plugin that installs the extension object, and it's the plugin that needs to do something with it.
Note that the plugin has to defer reading information from the extension object because the latter might only get populated after the plugin has run. (A plugin runs when apply plugin: is called in a build script. globalVariables {} might come after that.) There are several techniques for deferring configuration. In your particular case, if I wanted to use the information provided by the extension object to configure a Jar task, I might use jar.doFirst { ... } or gradle.projectsEvaluated { jar. ... }.
Before you go about writing plugins, make sure to study the Writing Custom Plugins chapter in the Gradle user guide. A search on Stack Overflow or on http://forums.gradle.org should turn up more information on techniques for deferring configuration. Another valuable source of information is the Gradle codebase (e.g. the plugins in the code-quality subproject).