I've implemented the MSBuild Community Tasks from tigris to my C# Project.
My Problem is that im not alone working on this project, but i dont want everyone to install the MSBuild Community Task on his local PC.
Without MSBuild Community Task you're not able to compile the project.
So my idea was to make a small workaround, i want to include the Install-Files to my project and copy it with a precompile-command to the MSI-Install-destination
But i dont know where the MSI saves its files.
Does anyone know how to find out where the MSI File copies the included file to?
Or does anyone have a better idea?
Thanks, Alex
It solved my problem executing the MSI-File with the command-shell, I've changed the TargetDir to C:\Temp\MyMSI and the generated folder-structure told my where it's saving the files to.
msiexec /a "MyMsi.msi" /qn
TARGETDIR=C:\Temp\MyMSI
Related
I've tried for many hours to find the solution for my problem and couln't find it even here.
So I have that application.exe that I am writing the Wix Toolset installer for it. Unfortunately I have no access to the source code but I hope I can do my task without it.
The problem is that it runs correctly with vc_redist.x64 installed on the end user's machine, but not without it.
What I've tried:
I was trying to run it without those runtimes and got into "couldn't find vcruntime140.dll error"
So I pasted it in the app's folder and tried to move on with dll's and the next error occured as shown in picture:
the application was unable to start correctly (0xc000007b). Click OK to close the application
I've read those runtimes after installation go into eg. "C://Windows/System32"
so I tried to go to that location and
dir > before.txt
and
dir > after.txt
after installing the vc++ runtime.
and copy pasted the files that occured only after the installation.
I tried to use gumpbin.exe from Visual Studio that gave given output:
found some dependencies
and the Dependency Walker gave me kind of similar output.
Dependency Walker output the same libs as direct ones, but also gave imo about hundreds of indirect ones. So I thought copy/pasting all of them is a really hard job without software to help.
I was also thinking about forcing vc_redist.x64.exe to extract files to folder given by me so I could use them for my purpose and the only parameter that looked fine was /layout but it only copied the whole .exe to another folder. Didn't extract it.
My questions is:
is there an easy way of obtaining the vc_redist.x64 libraries so I could author only the needed ones in my installer?
Any help will be appreciated. Thanks in advance!
Edit:
My goal is to secure newbie end users from being unable to run the application when they accidentally uninstall the VC runtime, therefore having vc_redist.exe as prerequisite in bootstrapper is unfortunetely not the case
So here's the scenario: I have several wix projects that the exact same extra msbuild targets and tasks to automate some very tedious tasks: things like building a help file and authenticode signing the msi and output files using signtool.exe.
Having gotten tired of copying changes to these scripts into 5 different repositories every time I made a fix. So I got clever and I turned them into nuget packages with a .targets file in the build folder. A simple nuget restore turns a laundry list of packages into targets files.
The problem
Wix v3 doesn't like packages. It doesn't support package references so packages.config looks like the thing. Except that visual studio doesn't like packages.config. It will happily restore the packages (into the folder I specified with a nuget.config) but none of the .targets files are automatically imported.
Easy enough to fix: I just added an import statement into my wixproj file. Except that visual studio doesn't automatically re-evaluate the wixproj after running the restore operation. We can work with this, but it is really annoying to have to build, unload the project, reload the project, and rebuild any time the packages change.
So I tried to fix it
I crawled through the log output of a standard C# project build and discovered the Nuget.Targets file, which can be imported into a project to provide pack and restore targets. It also let me convert to packagereferences, which are somewhat more convenient and less messy than packages.config, but I still had to manually add the import statement for the nuget.g.targets and nuget.g.props files that were produced by the restore target.
And, since I had to manually import those files, I'm right back to the build, unload, reload, rebuild workflow.
Attempt number 2
I discovered through intense internet searching that msbuild recently added a /restore flag to their command line utility specifically to force a project re-evaluation after restoring packages. This works on the command line, but visual studio seems to be clueless. (Maybe because of something that wix v3 does behind the scenes in the Visual Studio template?) In any case, they mentioned in the issue notes that they are essentially using an msbuild task with new global properties to force a re-evaluation. So I attempted to add such a step to the pre-build event of my wixproj, but no sauce.
The question
How do I tell visual studio to re-evaluate this wixproj after running restore? Is there some sort of property or item group I need to add to the wixproj? Is there some kind of target I can insert into the build process?
Update 1:
Found a project property that looked promising: UseHostCompilerIfAvailable, but it didn't work. Still got the same problem.
Since pulling changes, building my InstallerBootstrapper project in Visual C# 2010 fails with:
Could not find a part of the path "WiX Toolset v3.8\bin\IA64\burn.exe"
Indeed this directory does not exist, but it never did and the InstallerBootstrapper was building correctly before pulling.
The .wixproj and .wxs have not changed.
I reviewed the changes but can't seem to find what change could have caused that.
No file in the whole solution contain the string "IA64".
I have not updated WiX since a few months.
Google does return anything with these words.
Any idea what could have happened?
For some unfathomable reason, InstallerBootstrapper was configured to use IA64:
This happened when I re-imported the Installer et InstallerBootstrapper projects into the solution. No idea why, but it can be fixed by editing the solution file or using the COnfiguration Manager.
I should have searched for the lowercase string too.
I had an app A for which I created an installer A1. This has been in use for many months.
We now realized that AI used to package some files - d1,d2,d3 which are not needed.
Therefore we removed them from our project and created an installer A2 which does not package the above mentioned unwanted files. (atleast thats what we expect)
Things are ok when I use this installer the usual way...but when I use this for a silent install, I get the following error:
Error 1334. The file d1 cannot be installed because the file cannot be found in cabinet file 'myMedia1.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.
I googled this and saw that people usually encounter this whn u release a patch or some installer release where some files are removed or moved around.
Apparently, msiexec tries to reference some cached version of these variables and since it still looks for the missing files in the new installer, install fails.
Is there a way to tackle this? - like some way to have msiexec use just the .msi file I provide in the input rather some cached version.
Thanks...
It sounds like you could receive this error if you haven't updated the PackageCode, ProductCode, or UpgradeCode for your A2 installer. If A1 is installed, and then A2 runs with the same PackageCode, ProductCode, and UpgradeCode the system thinks you are running the A1 installer again and will look for the cached A1 msi under C:\windows\installer.
For anyone else like me that is experiencing the same problem (Error 1334) when building a Setup project and didn't find any explanations or solutions, here's a thread that solved my problem:
https://www.itninja.com/question/1334-error-tried-just-about-everything-i-can-think-of-anyone-know-of-some-obscure-causes
Basically, the solution to the problem is to “touch” all the files referenced in the Setup project (that is, all the dependencies - DLLs and all else). You can find the list and path of all the files in the build output, on lines like these:
2> Copying file from "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Threading.dll" to "C:\Path\To\Your\Project\bin\Debug\System.Threading.dll".
To “touch” the files, you may use this technique or you may use some third-party file manager like Total Commander. You'll just need to run as administrator / accept UAC warning, because some files are in system folders.
EDIT: in my case, the problem with the Setup project began after updating some NuGet packages used by the main project.
P.S.: although I'm not using WiX, but Microsoft Visual Studio Installer Projects, the symptom was the same, so I hope this answer will be helpful for someone.
If this is a repeat question, please direct me to the existing solution. I wasn't able to find a matching query.
We currently use InstallShield. I'm attempting to covert a project with 407 files to a WiX3 installation package. I tried using heat.exe to do some of the automation but I get the following warning for almost every file:
c:> heat dir "c:\projectDir\projectA" -gg -ke -template:Product -out "c:\install\projectA\heatOutput"
heat.exe: warning HEAT5150 : Could not harvest data from a file that was expected to be a SelfReg DLL: c:\projectDir\projectA\plugin1.dll. If this file does not support SelfReg you can ignore this warning. Otherwise, this error detail may be helpful to diagnose the failure: Unable to load file: c:\projectDir\projectA\plugin1.dll, error: 126.
Q: Is it normal for this warning to be reported for every file?
If there's a current "How To create/convert to your first WiX install project with many files" tutorial, please point me to it. The key requirement is "with many files".
PS. I know that WiX is designed for incremental install project creation but it would be nice to know if there's an automated way to convert existing install projects.
If there's a current "How To
create/convert to your first WiX
install project with many files"
tutorial, please point me to it. The
key requirement is "with many files"
You can take the msi file generated with installshield, and then decompile it with the dark.exe tool which comes with wix. As you can see in this diagram, dark.exe generates wxs files from a msi file.
You can use it like this:
dark installer.msi decompiled.wxs
See dark /? for more information.
edit: I don't use Votive, but AFAIK it should be able to handle the wxs files generated by dark. Did Votive show you an error?
edit2: wixproj files are just for visual studio and msbuild integration. The core tools don't know or use this format. Simply create a blank wixproj and add the wxs file to it from visual studio.
edit3: You should not compare the size of the wxs file to the msi file size. Like an installshield project file, a wxs does not contain the files to install. It only references them. Your installshield project file is not 70MB large either. If you want to extract the binary files from the MSI, then you should use dark.exe with the -x <path> switch.
Are you trying to extract data from x64 DLL's? That doesn't really work...