How change details of an exe file using wix bootstraper? - wix

I have a Visual Studio bundle file:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle
Name="Some Name"
Version="3.2.2"
Manufacturer="Some Company"
Copyright="Copyright: Some Company, Inc">
...
</Bundle>
</Wix>
After build exe details menu contains two parameters (File description and Product Name) and these parameters have the same value. There is a way make these values different using only WIX functionality?

As of Wix Version 3.10.2, you cannot set different values for the ProductName and FileDescription fields of the exe file description resource.
Looking at the WIX source code, specifically the file src\tools\wix\Binder.cs from WIX310-Debug.zip downloadable from here, shows the following code fragment for setting the exe file's resources:
Microsoft.Deployment.Resources.VersionStringTable strings = version[1033];
strings["LegalCopyright"] = bundleInfo.Copyright;
strings["OriginalFilename"] = Path.GetFileName(outputPath);
strings["FileVersion"] = bundleInfo.Version; // string versions do not have to be four parts.
strings["ProductVersion"] = bundleInfo.Version; // string versions do not have to be four parts.
if (!String.IsNullOrEmpty(bundleInfo.Name))
{
strings["ProductName"] = bundleInfo.Name;
strings["FileDescription"] = bundleInfo.Name;
}
Notice that ProductName and FileDescription are set to the same value.
If this is important you could request a new feature via the WiX issue tracking database: https://github.com/wixtoolset/issues/issues.

Related

How to Assign string in version attrbute of WIX project

I am having installer with version 1.2.3.4, which is hardcoded in wxs file as below:
<Product Id="B91BEF19-0975-DB9185E716FC" Name="Installer" Language="1033" Version="1.2.3.4" Manufacturer="XX" UpgradeCode="c2a8ba27-bb8-186cbcd4d743">
Now i need to change the version like "1.2.3.4_temp".i.e, assigning the string to version.
As we know version attribute takes x.x.x.x and x as integer.
Is any way to get the version as 1.2.3.4_temp?
Is any way to assign ProductName (as xxxx) to version in wxs file?
You need to use product version as a numeric value.
Though Wix toolset documentation says Version attribute as The product's version string, you need to look up at the Windows Installer documentation for details about Version attribute.
It says for ProductVersion : "String format of the product version as a numeric value. (Required)"
For details about ProductVersion, please go to this link.

Registration-Free COM for standalone VB.NET application - complex case

I need your help.
I read whole internet about Registration-Free COM/DLLs but my problem is more complex.
I'm preparing an application in VB.NET which will be used in an environment in which users don't have admin rights, so I can't simpy install it or register COM. This COM is a LogParser library designed by microsoft.
DLL also doesn't have to be embeded - would be nice, but it may be also extracted from exe during startup - i'm ok with this approach
Generally in a main form i've got a button which invokes another form by:
LogParser_Form.Show()
This another Form 'Imports MSUtil', which is a Interop.MSUtil.dll and which is embeeded to exe by Fody Costura add-on.
Form contains also a class which has multiple declarations of variables defined in COM, eg:
Dim IISW3CLOG As New COMIISW3CInputContextClass
(there is more than one)
But this dll refers somewhere to bigger: LogParser.dll which is acutally a COM component which requires registration, so my LogParser_Form doesn't appear when button is clicked, but it throws an exception that COM component is not found...
Unfortunately Fody Costura or Ilmerge don't work for the COM...
I tried multiple tricks wich manifest files, etc, but no luck...
You are my last hope - please help me... How to embed this COM to exe without registering it?
I suppose that properly used manifest files may help, but I didn't find a way to successfully use it ...
Getting Registration-Free COM to work can be tricky, but works when configured properly. The key issue is creating manifests, which document all required dependencies. In your case, you'll need two manifests:
Client manifest for your application
Server manifest for the LogParser library. This part requires a tool for analyzing type libraries, such as the OLE/COM Object Viewer (oleview.exe). It allows looking into the embedded type library inside LogParser.dll.
Let's take the (slightly modified) C# example, which is documented in the LogParser help file. The client is named "logqryclient.exe" in this case, and the Runtime Callable Wrapper has been created via the type library importer (tlbimp).
using System;
using Interop.MSUtil;
namespace logqryclient
{
class Program
{
static void Main(string[] args)
{
try
{
// Instantiate the LogQuery object
ILogQuery oLogQuery = new LogQueryClassClass();
// Create the query
string query = #"SELECT TOP 50 SourceName, EventID, Message FROM System";
// Execute the query
ILogRecordset oRecordSet = oLogQuery.Execute(query, null);
// Browse the recordset
for (; !oRecordSet.atEnd(); oRecordSet.moveNext())
{
ILogRecord rec = oRecordSet.getRecord();
Console.WriteLine(rec.toNativeString(","));
}
// Close the recordset
oRecordSet.close();
}
catch (System.Runtime.InteropServices.COMException exc)
{
Console.WriteLine("Unexpected error: " + exc.Message);
}
}
}
}
To use this code without registering the COM classes, you'll first need to place the LogParser.dll into the same directory as the client executable.
Next, you'll need to create an accompanying server manifest (named "LogParser.manifest" here). This documents all necessary classes and marshalling information for the interfaces (required for thread switching). As mentioned earlier, you'll need a type library analyzer to gain access to the class and interface identifiers.
In the above case, you'll need identifiers for:
ILogQuery interface & LogQueryClass class
ILogRecordset interface
ILogRecord interface
Hence, the server manifest could look as follows:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="LogParser" version="1.0.0.0" />
<file name = "LogParser.dll">
<!-- LogQueryClass -->
<comClass
clsid="{8CFEBA94-3FC2-45CA-B9A5-9EDACF704F66}"
threadingModel = "Apartment" />
<!-- Embedded type library -->
<typelib
tlbid="{A7E75D86-41CD-4B6E-B4BD-CC2ED34B3FB0}"
version="1.0"
helpdir=""/>
</file>
<!-- Marshalling information for interfaces -->
<comInterfaceExternalProxyStub
name="ILogQuery"
iid="{3BDE06BC-89E4-42FD-BE64-832A5F33D7D3}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{A7E75D86-41CD-4B6E-B4BD-CC2ED34B3FB0}" />
<comInterfaceExternalProxyStub
name="ILogRecordset"
iid="{C9452B1B-093C-4842-ABD1-F81410926874}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{A7E75D86-41CD-4B6E-B4BD-CC2ED34B3FB0}" />
<comInterfaceExternalProxyStub
name="ILogRecord"
iid="{185FFF88-E24A-4984-9621-AA41BEAE8513}"
proxyStubClsid32="{00020424-0000-0000-c000-000000000046}"
baseInterface="{00000000-0000-0000-c000-000000000046}"
tlbid = "{A7E75D86-41CD-4B6E-B4BD-CC2ED34B3FB0}" />
</assembly>
To allow the client to find the server manifest and ultimately the LogParser library, embed the following client manifest into the "logqryclient.exe" client:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
type = "win32"
name = "logqryclient"
version = "1.0.0.0" />
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="LogParser"
version="1.0.0.0" />
</dependentAssembly>
</dependency>
</assembly>
Now, all required information is located in the manifests, so that you can run the code in registration-free configuration.

WIX: get version of setup upto buildversion

We can get the productversion in wix using !(bind.fileVersion.Product.exe). This returns the version as 3.8.2363.0. How can I get the version up to build version, i.e. 3.8.2363.
I followed Binding WIX FileVersion sub values? this link, but using
"!(bind.property.ProductVersion.Major)" do not solve my problem.
<?define ProductVersion123="!(bind.fileVersion.mainexe_dll)" ?>
<Product Id="{7BDF78BF-95E8-4ABB-8A0F-4A1483D7FDD1}" Name="SpreadsheetConverter !(bind.property.ProductVersion123.Major)" Language="1033" Version="!(bind.property.ProductVersion123.Major)" Manufacturer="ABC" UpgradeCode="$(var.ProductUpgradeCode)" Codepage="1252">
This gives error:
Unresolved bind-time variable Mainexe !(bind.property.ProductVersion123.Major).
Please Help.
Thanks
You have to realize what !(bind.property.X) does. It retrieves the value of the X property from the MSI's Property table. You have not setup a ProductVersion123 property in the MSI, you have created a WiX preprocessor variable ProductVersion123.
So what you have to do is assign the Product's Version attribute to $(var.ProductVersion123) (which sets the ProductVersion property of the MSI). Now you can access that with !(bind.property.ProductVersion), including the !(bind.property.ProductVersion.X) extensions.

Working example of WIX script that registers help in MS Help 2.0 needed

Can anybody give an example of WIX script to register custom help in visual studio help? I,ve searched for some tutorial, but the only thing that I found was VS schema reference. Everything I tried to do did not work. I use WIX 3.0.
I hope this answer is not too late.
You're going to need:
Your help collection (and some details, such as the internal collection name).
Orca
Some merge modules included as part of the Visual Studio SDK
First thing you want to do is create the Wix code that will hold your help collection.
<DirectoryRef Id="MyHelpDirectory">
<Component Id="MyHelpCollection" Guid="INSERT_GUID_HERE">
<File Id="MyHelpCollection.HxS" Source="..\MyHelpCollection.HxS" KeyPath="yes" />
<File Id="MyHelpCollection.HxA" Source="..\MyHelpCollection.HxA" />
<File Id="MyHelpCollection.HxC" Source="..\MyHelpCollection.HxC" />
<File Id="MyHelpCollection.HxT" Source="..\MyHelpCollection.HxT" />
<File Id="MyHelpCollectionFIndex.HxK" Source="..\MyHelpCollectionFIndex.HxK" />
<File Id="MyHelpCollectionIndex.HxK" Source="..\MyHelpCollectionIndex.HxK" />
<File Id="MyHelpCollectionKIndex.HxK" Source="..\MyHelpCollectionKIndex.HxK" />
<File Id="MyHelpCollectionNamedUrlIndex.HxK" Source="..\MyHelpCollectionNamedUrlIndex.HxK" />
</Component>
</DirectoryRef>
Next, you want to make a copy of the MSHelp2_RegTables_RTL_---_---.msm merge module. (It can be found at C:\Program Files\Microsoft Visual Studio 2008 SDK\HelpIntegrationWizard\MSHelp2) and open it with Orca.
Here you want to edit the HelpNamespace table in the merge module. You're going to want to fill a record with the following information:
NamespaceKey = Company.MyHelp.1033 (You can get this from the person who created your help collection.)
NamespaceName = Company.MyHelp.1033
File_Collection = MyHelpCollection.HxC (Note that this is the Id attribute of the HxC file declared in the Wix code above.)
Description = My Help Collection
Now you want to edit the HelpFile table:
HelpFileKey = MyHelp (Taken from the NamespaceKey above.)
HelpFileName = MyHelp
LangID = 1033
File_HxS = MyHelpCollection.HxS (Note that this is the Id attribute of the HxS file declared in the Wix code above.)
File_HxI = MyHelpCollection.HxI (This is the Id attribute of the HxI file if your collection uses an HxI file. The collections I use do not use HxI files.)
File_HxQ = N/A
File_HxR = N/A
File_Samples = N/A
Next you want to edit the HelpFileToNamespace table:
HelpFile = MyHelp (Note that this must match the value defined in the HelpFile table above.)
HelpNamespace = Company.MyHelp.1033 (Note that this must match the value defined in the HelpNamespace table above.)
Finally, you want to edit the HelpPlugin table:
HelpNamespace_ = Company.MyHelp.1033 (Once again, keep this consistent)
HelpNamespace_Parent = MS_VSIPCC_v80 (For VS2005)
= MS.VSIPCC.v90 (For VS2008)
File_HxT = MyHelpCollection.HxT (Id attribute for HxT file from Wix)
File_HxA = MyHelpCollection.HxA (Id attribute for HxA file from Wix)
File_ParentHxT = FL_vsipcc_hxt_86880________.3643236F_FC70_11D3_A536_0090278A1BB8 (For VS2005)
= FL_vsipcc_hxt_86880_86880_cn_ln.3643236F_FC70_11D3_A536_0090278A1BB8.48273237_1399_45CF_801C_338E1AB00E90 (For VS2008)
You can now save your copy of the MSHelp2_RegTables_RTL_---_---.msm merge module. It's probably a good idea to rename it to something like MyHelpCollection.msm.
Now you just have to include this merge module in your wix project, in addition to the VSIP merge module for the version of VS you're targeting:
<Merge Id="MyHelpCollectionMerge"
Language="1033"
Disk="1"
SourceFile="PATH_TO_THE\MyHelpCollection.msm" />
<!-- For VS2005 -->
<Merge Id="VS2005VSIPMerge"
Language="1033"
Disk="1"
SourceFile="C:\Program Files\Microsoft Visual Studio 2008 SDK\HelpIntegrationWizard\VS_2005\VSIPCC_Collection_Files_RTL_---_---.msm" />
<!-- For VS2008 -->
<Merge Id="VS2008VSIPMerge"
Language="1033"
Disk="1"
SourceFile="C:\Program Files\Microsoft Visual Studio 2008 SDK\HelpIntegrationWizard\VS_2008\VSIPCC_Collection_Files_RTL_---_---.msm" />
Adapted from MSDN Walkthrough

MSBuild XMLUpdate Question

I am using the XMLUpdate to update an xml formatted file in MSBuild. It updates fine but adds <?xml version="1.0" encoding="utf-8"?> at the top after update. Here is my statement that updates
<Import Project="C:\Program Files\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<XmlUpdate XmlFileName="$(AppName).alx" Xpath="/loader/application/version" Value="$(AppVersion)" />
Is it possible to update without the xml element at the top?
Thanks
Ponnu
The <?xml ...> is more of a descriptor than a real XML element. It describes your document and, for example defines the encoding. It won't interfere with your existing elements. I think it is even a standard feature of a XML document (but I don't have the specs handy)