I am having trouble with getting a merge module to build in VS2013 on Windows 10 Enterprise. From searching around all day it seems to be related to not having .Net3.5 installed.
I’ve tried all the different ways suggested but .Net3.5 just won’t install on my system and there are a lot of people who seem to have the same issue.
My actual WiX error message is as follows;
Error 1 The "CreateProjectReferenceDefineConstants" task could not be loaded from the assembly C:\Program Files (x86)\WiX Toolset v4.0\bin\WixTasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
C:\Program Files (x86)\WiX Toolset v4.0\bin\wix.targets 709
I started using v3.8 which we use on other projects but also have the same issue with v3.10, v3.11 and v4.0.
Does anyone know if WiX still has a dependency on .Net3.5 and if any of the later unstable versions are dropping this?
I tried joining and sending an email to the WiX Installer Email forum but my question is never posted and there is very little ability to figure out why. I do get various email question from others so I know I have joined the group. Is there a better forum for community questions? The email group approach seems rather out dated today.
Thanks for any help.
Cheers
Dave
WiX 4.0 is very experimental and not meant for production use at this time. Go back to the latest stable release of WiX 3.xx that you can find. Don't use a weekly release in production.
I seem to remember a bug on this but don't know for sure. I'd install .NET 2.0/3.5 for now.
Related
Background
WiX & the Windows Installer are completely new to me.
In production, we used an MSI (created using WiX) to install our software. The MSI references a third-party assembly (e.g. OtherCompany.ThirdParty.dll, version 2.5).
The next release of our software must reference an older version of the third-party assembly (e.g. OtherCompany.ThirdParty.dll, version 1.7).
While I understand that installing an older version of a dependency is uncommon, it must happen.
So my question is... how do you configure a MSI (generated by WiX) to use an older version of an assembly without having to completely uninstall the existing package?
Options
We have explored the following:
Increment the assembly's version
it's a third party assembly, and
for traceability this is not an option
rename the assembly
the dependency is being retrieved using NuGet... so this won't be straight forward
force existing install to be completely removed (automatically or manually)
we don't want configuration information that was collected during the previous installation to be lost, so this isn't an option
schedule RemoveExistingProducts before costing
not recommended by Microsoft (see: MSDN)
custom action: to delete dependency
if the installation fails, the application may be left in an undefined state
override file version in setup
moving forward, this will be error prone
changing the REINSTALLMODE
From the articles that I have read, it appears that this should only be used as a last resort.
use a WIX companion file
am still investigating
For Moderators
I am aware that there are other SO posts on this subject. Please note that several of the recommended solutions are incomplete or are error prone.
References
MSDN: Patching and Upgrades
MSDN: RemoveExistingProducts Action
downgrade a library during a msi upgrade
Why Windows Installer removes files during a major upgrade if they go backwards in version numbers
MSI Writing Guidelines
What Every Developer Should Know About MSI Components
Windows installer deletes versioned file during product upgrade, instead of downgrading it
MSDN: Windows Installer - File Versioning Rules
Msiexec REINSTALL=ALL REINSTALLMODE=vamus not reinstalling anything
good overview of what is happening under-the-hood
Forcing an upgrade of a file that is modified during its initial installation
this is an older post is from 2009
Some issues are best solved by the application design rather the deployment.
There are two places to save a particular version of a .NET assembly: the GAC or the application folder (or subfolder with probing privatePath). In either case, you might want to use a bindingRedirect.
Also, you can load from a specific location using AppDomain.AssemblyResolve, provided the binding is not successful using the GAC.
General Reference: How the Runtime Locates Assemblies—thanks to #Pressacco.
I'd like to create an installer package to install registration-free COM components (with manifest files included). This would be more or less a self-extracting archive to place some files in a target directory given as commandline argument, but it would also need to check or install some other redistributables like VC++ or DirectX.
The package is supposed to be used in another applications's installer as some kind of redistributable package itself. It should not be registered in the "Program and Features" dialog of Windows but has to be removed with the application. Ideally there should be no changes to the Windows registry.
So far I haven't been very successful. Can anyone please provide me with some hints regarding this use case?
You've got about a dozen different questions in that one question. Start with just creating a simple MSI that successfully installs your files and your manifest. Create a COM client to test it. You can also put AppSearch and LaunchConditions in your MSI to detect your dependencies and not allow installation if they are missing.
That's about all you should have to do for this simple question. As for the other questions.... if you are a redistributable and someone else is silently installing you then it's their job to handle the installation of the other redistributables. Also if they don't want you listed in Programs and Features they can pass the ARPSYSTEMCOMPONENT=1 to your installer and you won't be listed. If they want to uninstall you when they uninstall themselves, that's their problem not yours.
If you are really creating a redistributable to be used by other products, sometimes a merge module is the appropriate solution. They build their MSI files and include your merge module.
Otherwise, reg-free COM is in theory an easy install because you're just installing manifest files and Dlls etc. However I don't understand how that could be used by other apps because (IIRC) a client app exe needs your manifest and Dll in their install folder, so how can they do that when they are not installed yet? Or even if they are installed how can you find them? So that goes back to the merge module idea so they include your merge module and install an exe, your manifest and your Dll in the same location. When they uninstall so do your files.
I'm trying to compile a WiX installer (which has custom actions, which I suspect are the source of the issue) on a build server and I'm getting the following error:
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3245: Could not resolve
this reference. Could not locate the assembly "Microsoft.Deployment.WindowsInstaller, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=ce35f76fcda82bad, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this
reference is required by your code, you may get compilation errors. [C:\code\rms1-moverssuite\src\RMSS.Setup.CustomActi
ons\RMSS.Setup.CustomActions.csproj]
Any idea what needs to be installed? I vaguely remember that I had to install something from the Windows SDK last time I did this, but can't remember what it was.
It's part of Windows Installer XML (WiX) an open source project formerly from Microsoft but since transferred to the Outercurve Foundation. It can be found on CodePlex. 3.7 is the latest release.
This interop assembly is part of Deployment Tools Foundation (DTF) and you'll find an SDK help file installed in the start menu. The actual assembly will be found in C:\Program Files (x86)\WiX Toolset v3.7\SDK.
I downloaded WiX v3.11 from official website which eventually lands to this git hub page. The set up is actually an executable (*.exe) rather an MSI which shows you this installation page:
Just click on the install gear icon. Once installation completes select the reference to Microsoft.Deployment.WindowsInstaller in Visual Studio solution explorer and click refresh from toolbar.
For me this was just a matter of providing a hint for the reference in cproj file, pointing to the Wix nuget package.
<Reference Include="Microsoft.Deployment.WindowsInstaller">
<HintPath>..\packages\WiX.3.11.2\tools\Microsoft.Deployment.WindowsInstaller.dll</HintPath>
</Reference>
You have to create a Custom Action Project and refer it to your installer. That will locate the assembly Microsoft.Deployment.WindowsInstaller.
I developped a vb6 program then I build an installation wizard with visual studio interdev.
I used "dependency walker" and "process explorer" to find out the missing DLLs but there is always a problem with :
IESHIMS.DLL
WER.DLL
MPR.DLL
These dlls shown by dependency walker.
And when installing the program on another machine I have these error messages :
uxtheme.dll failed to register
msdatsrc.tlb failed to register etc..
PS : no problem on a machine where visual studio is installed.
Any Idea to fix this issue?
Thanks
Dependency Walker is not an appropriate tool to troubleshoot VB6 dependencies. It works well enough for DLLs written in C or C++ that use implicit dependencies. Although it hasn't kept up with the times and has trouble with DLLs that are stored in the Windows side-by-side cache or are delay loaded. Delay loading is what generates the warnings on ieshims.dll et al.
VB6 uses COM, which loads DLLs dynamically with LoadLibrary(). You'll never see such a dependency back in Depends unless you use the Profile option. Such DLLs are found back through the registry, the reason you needed to write an installer and tinker with regsvr32.exe.
You have to be pretty careful when writing installers like that, VB6 is old and can depend on operating system components that have been updated many times since 1998. Like uxtheme.dll, an important operating system DLL that implements visual styles. Having your installer overwrite the existing one on the user's machine is, well, disastrous. Although it is probably protected by Windows through its File System Protection feature, something that got added as a counter-measure against broken installers.
Giving proper advice is here difficult beyond "do no harm". A commercial installer like InstallShield or Wise (which I liked back then) is the best way to avoid shooting off the customer's leg. Fairly sure they still support VB6 installs. Microsoft makes a pre-cooked installer available for VB6 that installs all the core vb6 runtime components. You can download it here.
You should ALWAYS double check and verify any dependancies that you think your application needs.
All the files you mentioned are system DLLs and MUST NOT be distributed.
For a VB6 application you need the basic runtimes, and any DLLs you explicitly reference/use if and only if you have permission from the authors of those DLLs and instructions on the correct procedure and location for installing them.
For the standard Microsoft provided OCX files, these normally just need to be copied to the system32 folder and registered.
See redist.txt in the root of your Visual Studio installation for more details.
Has anyone got the MSBuild Community Tasks or MSBuild Extension Pack working with Mono's xbuild? They both seem to have MSI installer, so I guess it's a case of manually transferring the files to the Mac (in my case)?
If anyone's done it, I'd appreciate the benefit of his/her experience.
I guess you have to do it manually because of the MSI.
You can get the sources :
http://msbuildtasks.tigris.org/files/documents/3383/36642/MSBuild.Community.Tasks.v1.2.0.306.zip
http://msbuildextensionpack.codeplex.com/SourceControl/list/changesets#
And compile them with xbuild. Then you should be able to use them with xbuild.
Nevertheless, I'd never tried.