Code snip:
<Component Id ="zyx" Guid="{4820d7d5-30a0-448c-a80e-83609c92f235}">
<File Id="DLLGAC" Assembly=".net" KeyPath="yes" Source="folder\pqr.xyz.dll"/>
</Component>
I'm trying to upgrade older version of assembly using above code but getting error
skipping installation of assembly component: {4820d7d5-30a0-448c-a80e-83609c92f235} since the assembly already exists
From my experience version of your library must be higher than installed library. And there's no option to copy with overwrite. So if library is yours - change version of library to higher.
If not:
In my case someone added to installer modified 3rd party with some higher version and it was impossible to replace it with official new version. Only way to solve it was custom action with simple File.Copy with overwrite.
How to create custom actions
<Component Id="zyx" Guid="{BB23E1A4-9270-41AA-9266-4D15506E1C63}" Win64="yes">
<File Id="DLLGAC" Source="folder\pqr.xyz.dlll" KeyPath="yes" Assembly=".net"/>
</Component>
After changing the code format it's working which is strange but it works :)
Related
I have a component
<Component Id="ProductComponent" Guid="7935315f-4242-4c7a-a02c-6fd256805356">
<CreateFolder/>
<File
Id="propFile"
Name="aaa.properties"
DiskId="1"
Source="$(var.Project.TargetDir)"
Vital="yes"
KeyPath="yes" ></File>
<?endif?>
</Component>
I want to copy the file just on install , not upgrade.
But I can't find how to do it.
Any idea?
Have you tried using Condition element. I think you can provide a Condition inside Component element to check whether product is already installed or not. If not installed, then create file.
<Component Id="ProductComponent" Guid="7935315f-4242-4c7a-a02c-6fd256805356">
<Condition> NOT Installed </Condition>
<CreateFolder/>
<File
Id="propFile"
Name="aaa.properties"
DiskId="1"
Source="$(var.Project.TargetDir)"
Vital="yes"
KeyPath="yes" ></File>
</Component>
This is a weak spot of MSI (which WiX uses).
MSI installs a file
User modifies the file
MSI goes to install the file. Should it:
a) overwrite and lose user data
b) not overwrite and lose new applciation data
c) merge --- MSI doesn't support this.
If the user data is only one or few attributes there are tricks with custom actions to harvest the user data and reapply it but this is very tricky stuff.
IMO, the best way to approach this is never keep user data in a file installed by the installer. Take app.config appSettings element as an example. It was an atttribute that allows you to extend the file with another file that overrides the settings in the first file. Using this pattern the installer can lay down the app config and the application can create the override file and everything just works because MSI doesn't have to deal with the problem at all.
I have an installer that consists of lots of files in individual components that installs correctly.
I have now been told that one of these files needs to be registered only if it doesn't already exist and hasn't yet been registered.
I have use heat to generate the appropriate entries for the file;
<Component Id="AXSListenerdll" Guid="b1f80295-8806-4f6a-bf28-0ee35540317c">
<File Name="AXSListener.dll" KeyPath="yes" Vital="yes">
<TypeLib Id="{CE807033-6BEE-44D3-A86A-E9BC1D0716A4}" Description="AXSListenerLib" Language="0" MajorVersion="1" MinorVersion="0">
<Class Id="{C66BC66D-546E-4E74-A69F-BA97E4117E6B}" Context="InprocServer32" Description="IImplementedAlarmTypesCollection Class" ThreadingModel="both" Programmable="yes">
<ProgId Id="SymEvents.IImplementedAlarmTypesCollection.1" Description="IImplementedAlarmTypesCollection Class">
<ProgId Id="SymEvents.IImplementedAlarmTypesCollection" Description="IImplementedAlarmTypesCollection Class" />
</ProgId>
</Class>
</TypeLib>
</File>
</Component>
My question is, how do I prevent this particular file from being installed if it is already there and registered.
I just having a bit of a mental block about this.
I'm sure the answer must be obvious, I just can't see it!
Thanks in advance.
By default, Windows Installer uses file versioning to decide if this file needs to be installed/reinstalled. As an example, if the MSI has version 1.0.0.0 to install and 1.0.0.0 is already there then it won't reinstall. When it installs, it will reapply the registry entries for the DLL.
The requirement provided to you is a little weird / wrong. It could be read as if the MSI has file 2.0 but 1.0 is already present, don't install. That's not a good design and MSI doesn't operate that way.
I'm writing an installer pack for a product using Wix, the whole thing is in x86, but now i need to add a key to the x64 part of the registry. I looked around and found this stack answer which I thought would solve my problem. But I'm getting a ICE80 error (not a warning) which tells me that I basically need to change my Package Platform attribute to x64.
I would however rather avoid that because as I mentioned it's only one registry key that needs to be in x64.
So my question is: Is there another way to resolve the ICE80 error or do I need to build two msi packages, one for x86 and one for x64.
Here is some of my code to further illustrate what I'm trying to do:
<Component Id="Foo" Guid="{GUID}" Win64="yes">
<RegistryKey Root="HKLM" Key="Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles">
<RegistryValue Type="integer" Name="Hello" Value="1"/>
</RegistryKey>
<Condition><![CDATA[VersionNT64]]></Condition>
</Component>
<Component Id="Bar" Guid="{GUID}">
<RegistryKey Root="HKLM" Key="Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles">
<RegistryValue Type="integer" Name="Hello" Value="1"/>
</RegistryKey>
</Component>
Any help is appreciated!
Windows Installer doesn't support a 32-bit package writing to the 64-bit registry (or file system). A 64-bit package can write to both 32-bit and 64-bit portions.
Perhaps it didn't work then. I am using Wix v10 and in my x86 WIX project, and adding Win64="yes"initially generated ICE80 error. Once I suppressed that warning (in Visual Studio, "Tool Settings" -> "Suppress specific validation:" column), I no longer get that error. When I ran the x86 installer on Windows 2012 R2, those x64 reg keys were created.
Add Win64="yes" to the registry entry you want to put in the 64-bit in the registry..:) I have not included the condition in my own and it works perfectly with just the Win64 attribute.
I am trying to register a new filter with Windows Desktop Search. Ideal way to achieve do this would be registering new filter with existing persistent handler CLSID. But this cannot be done since .html PersistentHandler CLSID, {eec97550-47a9-11cf-b952-00aa0051fe20}, is protected under WRP (More about the problem).
As a workaround, I am trying to create a different CLSID that does the same job as {eec97550-47a9-11cf-b952-00aa0051fe20}.
This is the sample code I am following. I am quite new to WiX and editing Windows registry.
<File Id="HTMLfilter.DLL">
<Class Id="$(var.CLSID_HtmlIFilter)" Context="InprocServer32" ThreadingModel="both" Description="Html Filter" />
</File>
Could someone help me regarding these;
How to create a CLSID that is not affiliated to any file? Since my
new CLSID is doing the work of above mentioned CLSID, I think this is
how it should be.
How to create a a sub-directory named PersistentAddinsRegistered
instead of InprocSever32
Thanks
Have a look at this page here shows how to add COM objects to installers
I suggest export selected branch to registry file (Export all or part of the registry to a text file).
Then using Heat.exe harvest registry file and include its output in your project.
This is an example
<Fragment>
<DirectoryRef Id="TARGETDIR">
<Component Id="cmp6E2CE62C9ADECD355465514E3C8F354E" Guid="PUT-GUID-HERE" KeyPath="yes">
<RegistryKey Key=".ascx\PersistentHandler" Root="HKCR">
<RegistryValue Value="{eec97550-47a9-11cf-b952-00aa0051fe20}" Type="string" />
</RegistryKey>
</Component>
</DirectoryRef>
</Fragment>
I am creating an installer using WiX which contains few dlls. In the original script first gacutil.exe and then regasm for each dll is called. I am having a problem when transfering this idea into WiX. Here is the code fragment for installing into GAC :
<Component Id="GMAG.Core.Serialization.dll" Directory="_2.2.8.0" Guid="{my_guid}">
<File Id="my.dll" Source="my_src" Assembly=".net" KeyPath="yes" Checksum="yes"/>
</Component>
Now the question is how WiX will perform the assembly registration? My problem is:
I can't create another <File Id="my.dll" Source="my_src" KeyPath="yes"/> in the same component cause there must be only one keyPath="yes" attribute/component.
I can't put keyPath="yes" in component level, as it breaks component reference counting system.
I can't create <File Id="my.dll" Source="my_src"/> without keyPath="Yes", as it generates compilation error.
I can't create a seperate component as two components will try to install same file.
I know I don't need to call regasm or regsvr32 when using heat. In the component code :<File Id="my.dll" Source="my_src" KeyPath="yes"/> should be enough for the registration.
I'm using heat and now I'm stuck as I have to do assembly registration also.
Assembly=".net" will put you assembly in the GAC, you will then need registry keys for the COM registration. If you run Heat against your assembly it should generate the code fragment you require.
That's how we register DLL in GAC via WIX 3.5:
<Component Id="Level0GAC" Guid="21735A8C-DD0C-4f4e-8AB5-B5BB8C55726B" DiskId='1'>
<File Id='Level0' Name='DLLFileName.dll' DiskId='1' KeyPath="yes"
Source='DLLFileName.dll'
Checksum="yes" Assembly=".net" AssemblyManifest="Level0">
</File>
</Component>
Indeed, there can be only one file inside a Component with a KeyPath set ot "yes", that's why for several DLLs you should create several Components.