Where I can download VSTO Office Runtime version 10.0.40820?
I need link for this specific version, NOT for the newest one (http://go.microsoft.com/fwlink/?LinkId=158918).
Why I need this specific version? I created custom InstallShield .PRQ for VSTO that download file from web and checks if file is not corrupted using MD5 hash.
If I use generic download link and MS will deploy new version of VSTO then setup will complaint about corrupted file.
InstallShield has abstractions in their PRQ file that are meant to help but I have found problematic.
First, the PRQ itself can have a URL. This means that at runtime the PRQ embedded into the setup.exe will go try to download a newer version of itself from this URL. If this happens, the new XML is used and yours is ignored. This sounds like a good idea to keep things fresh and up to date but the CM Nazi in me see's this as a man in the middle vunerability that compromises the integrity of the build.
The second is that your XML or the downloaded XML both have URL attributes on the individual files. Again the CM Nazi in me says that while this seems like a good idea, it's really inserting an external dependency that isn't under my control and again violating the integrity of the build.
If it was me, I'd never use InstallShield and/or Microsoft URL's in my PRQ files. Host the content yourself and do change management of that so you can have complete control. If longevity of the build is desired then don't use web downloads in the first place. Bake it all into the EXE.
As for the exact question you asked, I'll have to google for it. But really I'd probably just move onto the latest version and then implement the above advice starting there.
Related
I have a question about the rules organizing resources into components.
What I want to do is the following; There are two files (both 64bit) with the same filename but in different source locations and with different component GUID's;
C:\data\win7\driver.sys
C:\data\win10\driver.sys
I want both included in the installer and when the installer runs decide depending on the OS which of these two files will be installed in the same location:
C:\Program Files\MyProgram\driver.sys
Is this a violation of the rules regarding the components? (the main one applying would be the first one I would say:)
"Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies."
https://learn.microsoft.com/en-us/windows/desktop/Msi/organizing-applications-into-components
Actual Answer: Yes, installing different files to the same absolute path is indeed a violation of the MSI component rules - in
theory. As you have discovered reading the documentation. However,
seeing as only one file will make it onto the box, it is all semantics
really, there will never be two files installed. Still, the MSI will
probably not validate - you will see validation errors.
I am not sure of the technical implications, but could you make the
file name different based on OS? Then you simply put the files in
separate components and use different component GUIDs and condition
the component for installation or not. Full compliance instantly.
With all that said, it seems driver files are to be installed using
INF-files in standalone packages in the future. Please read below.
Component Rules, Pragmatically: This is a well-known problem indeed. I have this old answer that might be helpful: Change my component GUID in wix? It describes how the component rules work in practice, and how the idea is that you reference count an absolute path, and not a file per-se. Please read it to make it clearer. More links in this answer.
Driver Installation: We are supposed to know how to do this, but the rules keep changing (and another answer). Essentially drivers are to be distributed via Windows Update, or at least via a standalone package without the need for an installer in the future (until Microsoft change their mind again?). Windows Hardware Dev Center dashboard. As far as I understand the installation is INF-based (as before).
Question: Are you sure about that installation location? What does the documentation say? I thought sys files should go primarily to the Windows folder? Or the WinSxS folders (side-by-side win32 assemblies). As you understand driver installations confuse us all.
Windows 10 Detection: It appears to be a challenge to detect Windows 10 due to the new "evergreen versionlessness" of Microsoft. I have this old answer written up to summarize my current understanding of it: Windows 10 not detecting on installshield. Deployment tools such as Advanced Installer does the job for you and detects Windows 10 with simple measures. Not sure what Installshield does. The linked answer lists a few approaches to detect the version yourself - not sure which is the saner approach. Please read (and also please report any interesting findings when you have a successful package).
I recently made an Excel-tool, which makes heavy use of VBA macros.
This tool works perfectly on my pc, and on most of my colleagues pc's, but I noticed that it doesn't work on some other pc's. This is because some of the required reference files are not present on those pc's.
I would like to solve this by making an exe-file of the original Excel document, in which all the referenced files are included. I already tried this with Winrar, but I noticed that, after unpacking the exe, the reference files are unpacked in the folder in which the exe file was copied, but not in the required system folders.
How can I fix this, so that I can use the tool on whichever computer I'd like to?
Thanks in advance!
Kind regards,
Marc
Michael Todd's comment about licensing is something worth checking up, but assuming that's ok, you could just write a simple batch file and/or script to first unrar the files and then copy them into the relevant directories. This script would preferably be executed during installation of your excel document.
However, depending on what files they are I'd would be wary of copying them into system directories. Firstly, will you have permissions to write to those directories? Secondly, is it possible that you'll overwrite other versions of those dlls, possibly overwriting a newer version with an older version. Depending on what DLLs you're trying to copy, you might break other applications or even Windows itself by copying them in.
In general, if the solution to your problem is to copy random dlls from your machine to someone else's machine, you should look for an alternative solution. I'd suggest that the better solution might be to change your application to not reference those dlls, or if that can't be done, do a proper install of the application where those dlls come from on the machines where you have the problem .
Just to be sure:
Winrar shows something like this:
and you should be selecting either "Store full paths" (better) or "Store full paths including drive letter" (worse)
I highly recommend you try Inno Setup. It has a higher initial learning curve, but it is well worth it for the enhanced functionality over WinRAR (for this type of thing). Inno-Setup creates installers from plain-text setup files, however, the "Quick Start Pack" includes a GUI front-end for making this part easier.
I'm developing an "installation" like cocoa application wich needs to take care of some http request, some file system reading, copying files to /usr/share, set up cron (not launchd) and ask some information to user.
I discarded PackageMaker since I need more flexibility.
Currently everything is going well, but on my last installation step, I need to:
Delete my previously installed application folder (if exists). It's always the same path: /usr/share/MY_APP
Create again the application folder at: /usr/share/MY_APP
Copy application files to /usr/share/MY_APP
Update a cron job
It's very important that /usr/share/MY_APP keeps protected with administrative privileges, so a regular shouldn't delete it.
What would be the best approach to implement those steps?
BTW, I'm using Xcode 3.2.
Thanks a lot!
Carlos.
Between the preflight script, the postflight script, and perhaps an Installer plug-in for the custom UI, I see no reason why you can't do all of this in PackageMaker.
Note: “Installer plug-in” is a little misleading. The user does not have to install the plug-in somewhere as a separate step; you include the plug-in inside your package, and Installer will use it from there.
The relevant document is a ReadMe file in a sample code project. There's also an Installer plug-in project template in Xcode since 2.0.
Also, an Installer plug-in won't get used if the user does a command-line installation. Of course, they can't install from the command line at all (which includes remote installation onto an office or lab full of machines) if you write your own custom installer.
By the way: Why /usr/share? What are you putting there? There may be a better way to do what you're really trying to accomplish.
I am to migrate a Websphere machine (including the applications which run on it) to a new machine. They wanted a clean install of the OS and WebSphere, so I did that. I also took a full file backup of all of the applications they had on the old server. The problem is that to re-install them on the new server, the WebSphere dialog asks me for the JAR/EAR/WAR file, which I don't have.
Is there any reasonably easy way to simply extract the backup of the WebSphere application files I have taken from the old maching, and simply configure the new machine to use them? WAR, etc. is a nice feature to have, but to be forced to use it seems silly.
Edit: The existing WebSphere server is still up and running in production.
Edit: The old server is WAS 3.5, which means it doesn't even have an export function, sadly. Also, the directory where it actually runs the content from has a completely different structure (consisting of like a a %/Web and %/Servlet, where % is the context path of the application). In the "Install" section, it doesn't even mention EAR or WAR, only JAR. I am currently thinking that perhaps the best thing to do might be to just copy the directory over to another WAS 3.5 system and then upgrade that system (and hope it converts the folder structure and updated the config as part of the upgrade).
Edit: The closest thing I have found to a solution so far is this link:
http://www.javazoom.net/services/newsletter/was4.html (though I am not sure if that tool is available or relevant for WAS 7.x).
This has to be a problem other people have run into before, but I can't find a solution anywhere on the WEB.
Thank you!
Here do they have sample Jacl scripts one can use to export/import appserver's configuration. So that is what you can start with. If your new bow uses the same version of WAS (and the same topology if it is not a standalone box) as the old one, it might be a (relatively) safe process.
Migration between different versions of Websphere might be somewhat more tricky, but I'm sure IBM published at least one redbook on that topic.
If you still have the old server running, than just export the apps and you have the war/ear files. However, If you don't know the configuration for the apps, you are screwed. However, I am sure IBM has tools that you can use. Some of the paid tools look even nice and user friendly (at least according to their sales demos). I can't tell you what you need, since I don't know what documentation you have for your apps. But as it looks like there is not much there, otherwise you would just install the application the same way they were installed on your old server and use the binaries (war, ear, jar) that are archived somewhere.
I found that Wix v3 uses a tool (heat.exe) to "harvest" information into WiX fragments. Either I am looking in the wrong location, or this is thinly documented.
What is the best way to auto-generate a WiX fragment (likely using heat.exe) for a complex folder structure that contains media files:
Of varying types (ico/png/xaml/etc)
That may change regularly (names/locations/adds/removes)
That are classified as "Content" and included in a .csproj
such that they can be built into an installer via WiX and would withstand upgrades and patches with decorum?
Background Information
I found heat.exe, which seems to solve the autogenerate WiX fragment requirement
In getting the "dir" harvester working, I noticed the "project" harvester (commandline help)
Media is already in C# project file, and so noted that "-pog:Content" might do very well
Cursory search found out of date documentation that didn't mention "project" harvester
Realized entire project installer could probably done with "project" harvester, but was unsure how well this was supported, and what the pitfalls were.
Saw the generation of "PUT-GUID-HERE" and realized that autogeneration of guids would likely have upgrade/patch implications.
Realized that there must be people who use these tools for similar purposes and could probably point me in the right direction.
It was (fairly) pointed out that v3 is not yet "done" (thus the scarceness of documentation and tutorials). The sense that I get now is that it is non-trivial to automate this in my build scripts, and the tools are growing right now to ease this.
In my experience John Robbins' Paraffin solves alot of the issues with tallow.exe (heat.exe in v3). I'm not sure if Paraffin plays nicely with v3, but it might be worth checking out.
FYI, I've used Paraffin in a build process and it allowed me to remove the previous 2-3 step cleanup process that involved a powershell script.
For the upgrade implications of auto-generated setups, read this. The take-home message:
Windows Installer doesn’t let you
remove components in a minor upgrade
It is hard to guarantee that components continue to exist if you generate your setup automatically. Therefore you have to chose between auto-generation of components and the ability to do minor upgrades.
If you have some auto-generated components, then just stick to major upgrades. You can use this sample by Rob as an example.
Thanks for the background, I wasn't aware that they were working on a new version of Wix. According to the project page, it isn't RTM yet, so that may explain the problems you're having. I hope to hear from the WIX developers in one of the replies.
I can't help you use the under-development heat.exe features. However, I have been in your situation and my solution was to create a tool that took directory and file information as input and generated valid wix project files as output. A .vsproj file is just an XML file, and you can use XSL, C#'s LINQ, PowerShell, or a number of other tools to do the work. I personally have used (pre-LINQ) C#/XMLDOM to parse VS project files for this purpose.
Good Luck,
Dave
For documentation, check out the help file that is installed with WiX - WiX.chm provides the most up to date information (along with the command line -help option).