Hello,
Thank you very much for your response.
What hasn't been asked explicitly is: Can I use a MajorUpgrade element and
prevent the Software from upgrading from particular versions, that are not
supported?
For example; I don't want to allow upgrades from versions prior to 2.1.0.0?
Kindest
If you want to block the installation you can use the upgradeVersion element
with OnlyDetect='yes' to set a property to use in a launch condition with your
error message.
If you want to break the new installation away from the previous versions and
allow for side by side installation you can
We made a MSI installer with WIX. It installs some files into a directory
created in 'Program Files', and all works fine. However, if I change (with a
text editor) a file that has been installed and then attempt to repair the
product, the file is not repaired, i.e. it is not replaced by an
The MajorUgrade element is a shortcut for the general cases, if you need
something specific you either replace it with Upgrade elements or add Upgrade
elements. In this case I would add a detect only Upgrade element.
Neil
-Original Message-
From: Przemyslaw Galera
Hi,
Thank you for the answer.
This is exactly how it is set right now. The point is, I wanted to force the
Major Upgrade for all the supported Software upgrades, but not for all.
Is there any way to use Upgrade/UpgradeVersion and MajorUpgrade elements next
to each other within the Product? I
I am new 2 wix.
I tried using burn but it is not generating the wixobj file. Below is the
bundle I am trying to create. Is there anything wrong in this. I already have
my two .msi's in sourcefile path. In the upgrade code I created a new GUID.
?xml version=1.0?
Wix
You may not realize that you can have multiple Upgrade elements. So
you can forget the MajorUpgrade and do something like this, off the
top of my head:
Property Id=PREVIOUSVERSIONSINSTALLED Secure=yes /
Upgrade Id=7F4A46B0-A6E7-4EEA-8655-235BCA4AB2C4
UpgradeVersion
Minimum=5.0.0
Hi,
Thanks for your help.
I do realize that. I have several UpgradeVersions in my configuration file. The
question was about the particular tricky versions: --- upgrade from 2.0.0.1
to 2.0.0.5 --- , not the upgrade from 5.0.0 to 9.0.0...these are a normal
upgrade versions handled very well.
IIRC, OCX Controls were only supported from Windows 95 up to XP,
during the Lifespan of VB4 - VB6. They are no longer supported in
Windows Versions past XP. You'll need to upgrade the components to
their .NET equivalent. If your app is written in VB6, it's time to
upgrade the app.
Yes our app is built in vb6 and we are trying to install the msi in windows
8. Actually windows 7 is working fine. Can you please specify what to
upgrade??
--
View this message in context:
All the items and controls that you are using that require OCX files
will have to be rewritten(custom) or replaced by the .NET replacement.
You can't use the .NET replacements until you recode the app in at
least .NET Framework 2.0 SP1
Carter
Quoting sandyGSS sandhya@gmail.com:
Yes
Ok, but I think somebody may have already mentioned that you can't
upgrade from 2.0.0.1 to 2.0.0.5 because Windows Installer upgrades use
only the first 3 fields of the version. You can't use upgrade
elements or majorupgrade for this reason. Manually uninstall or just
change your new version to
Trying to create a msi for all the active x controls. I am using wix 3.8
version heat to generate .wxs and facing an issue with msinet.ocx . It acts
wierdly and giving different errors in different machines. Below are the
errors I get
While installing .msi it says
1) msinet.ocx failed to
Hey young without upgrading with the existing ocx files can't we use wix
installer to generate an msi?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ocx-file-is-not-registered-in-windows-8-tp7595015p7595021.html
Sent from the wix-users mailing
There's still a dependency on the vb6 runtime, so the target machine
will need that installing.
That error decodes to The operating system cannot run %1. but it's
not clear to me what is running at install time if you've extracted
all the registration data. You may need to look at a verbose log
Do you have any reference / documentation link about this?
--
Nicolás
2014-06-04 11:53 GMT-03:00 Carter Young ecyo...@grandecom.net:
IIRC, OCX Controls were only supported from Windows 95 up to XP,
during the Lifespan of VB4 - VB6. They are no longer supported in
Windows Versions past XP.
ok if there is a solution of merge module. Can you please suggest me how to
use merge module for all the ocx's.
The problem is it is not registering the msinet.ocx in the regedit properly
in windows 8. We are not facing any issues in windows 7
example_Windows_7.log
No ones stopping you from doing that, as that's what youve done, but
if you want to use the installer, you can only use it on the OS'es
that are all EoL, as depending on the settings in Windows 7, users can
choose to support ocx files or not, and if they choose to support
them, you must
Before you go down that path, read my other email... I apologize as a
one handed disabled typist/programmer some of the answers take awhile :)
Carter
Quoting sandyGSS sandhya@gmail.com:
ok if there is a solution of merge module. Can you please suggest me how to
use merge module for all
Oh ok young I got it.
But how can we do by using the merge module? what is the merge module? can
you give me the references?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ocx-file-is-not-registered-in-windows-8-tp7595015p7595027.html
Sent from
This link that Phil Posted Earlier should start you on the right path:'
http://msdn.microsoft.com/en-US/vstudio/ms788708.aspx
Carter
Quoting sandyGSS sandhya@gmail.com:
Oh ok young I got it.
But how can we do by using the merge module? what is the merge module? can
you give me the
From said Link: (Quote)
Supporting and/or shipping Visual Basic 6.0 runtime binaries on
Windows Vista/Windows Server 2008/Windows 7/Windows 8 does not change
the support policy for the Visual Basic 6.0 IDE or Visual Studio 6.0
IDE as a whole. Those products will move out of extended
Thats ok thanks young through our posts I came to know there are two
solutions
1) Either manually go ahead and register .ocx files in windows 8 or
2) In this link it just says it couldn't support but support agreements are
available
No, but Custom Support Agreements may be available.
But here
Thanks again!
Can we say at this point, that MajorUpgrade and Upgrade elements cannot be used
within the same wxs file?
I thought, I would be able to upgrade between builds just by forcing major
upgrade --- which will uninstall the previous Software version --- for
each supported upgrade
Merge Modules:
http://msdn.microsoft.com/en-us/library/aa369820(v=vs.85).aspx
Using Merge Modules:
http://msdn.microsoft.com/en-us/library/aa372427(v=vs.85).aspx
Carter
Quoting sandyGSS sandhya@gmail.com:
Thats ok thanks young through our posts I came to know there are two
solutions
1)
OCX files work fine in Windows 7, 8/8.1.
If you Google for MSINET.OCX you'll find similar problems with this control.
Typically you will need to check the dependencies it needs e.g. VB6 runtime (or
even VB5) and VC runtime.
Neil
-Original Message-
From: Carter Young
The official merge modules should be somewhere in the VB6 setup, or
included with the Visual Studio Installer that was available at that
time. These guys seem to have accumulated the latest ones, including
msinet.msm.
http://www.everythingdesign.net/zero/installanywhere-net-merge-modules.html
Yes that's what my concern is neil all the other ocx files are working fine
except this msinet.ocx. After googling for 4 to 5 days I couldn't find the
answer.
How can we check whether it might have dependencies or not? Can you suggest
me.
Young thanks for sending the merge modules will try to
I'll repeat the part that says you can't do any kind of major upgrade
unless you change your version in the first 3 fields. You cannot major
upgrade from product version 2.0.0.1 to 2.0.0.5, which makes any use
of majorupgrade or upgrade elements irrelevant. Remarks here:
Try using the program depends.exe - I seem to remember it is part of VS but you
can also get it here http://www.dependencywalker.com/. A quick check on my PC
doesn't highlight anything particularly odd, it would be best to try on a
machine that doesn't and also try manually registering it.
I suspect I would need to somehow extract the executable out of the binary
table before I can use it. I'm not sure how to accomplish this though.
I was attempting to do something like:
Binary Id=CalcID SourceFile=C:\Windows\system32\calc.exe /
CustomAction Id=CA1ID Return=check HideTarget=no
There is one option, you can set AllowSameVersionUpgrades that will allow
1.0.0.0 to be upgraded to 1.0.0.1 but (and it is a big but) it will also make
1.0.0.1 upgrade to 1.0.0.0 which is dangerous.
But as Phil said, changing the version scheme is the safest option.
Neil
-Original
Thanks neil I will try to test that once I get permision from my manager.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ocx-file-is-not-registered-in-windows-8-tp7595015p7595039.html
Sent from the wix-users mailing list archive at Nabble.com.
Thank you guys...you are with me now :)
I can't change the released products, though.
What I have already tried is the MajorUpgrade with
AllowSameVersionUpgrades=yes and AllowDowngrades=no...but there is still no
way to preserve the old Upgrade Logic.
For my taste, this configuration would
Follow-up
Our old VS2012 solution was organized like this...
A.vsxproj (C++)
B.csproj (C#)
C.csproj (C#)
W.wixproj (WiX)
Where project-B had a SOLUTION dependency on the C++ project-A. And the
WiX project has project dependencies on both project-B and project-C. When
built via VS2012, the
Tony,
Not sure if this will help you, but I ran into a similar problem. I need to
run MSBuild with /property:BuildProjectReferences=false as I have references
to projects not in the solution and it was attempting to build those references
even though I did not need it to. A side effect of
I decided to attack this issue from a different angle.
I always distribute burn bundles. The bundle uses an ExePackage to do the
work now.
--
View this message in context:
Repair has nothing to do with upgrade. During repair you are usually running
the same install to repair broken files or replace files.
If you want to replace the files make sure to use Keypath=yes in the
component where you declare all your files. Setting it to no will not replace
it.
--Pavan
I've only done it with VBS, which I know isn't recommended, etc, but to do
that, I have the below.
If you're really using calc.exe in your testing, are you sure it isn't
working? Sometimes weirdness happens with user contexts - did you check to
see if calc.exe is running on your system under a
39 matches
Mail list logo
