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.
Related
I'm trying to get a C++ solution converted from VS2013 to VS2017 to build on a build server using TFS 2010 but the build cant find the platform toolset.
I keep getting the error message:
error MSB8008: Specified platform toolset (v141) is not installed or invalid.
I've installed VS2017 (not just the Build Tools) on the build server and checked that the platform toolset v141 is installed.
I've update the .proj file to use ToolsVersion 15.0 and the project files in the solution are all updated to use ToolsVersion 15.0.
I've also added /p:VisualStudioVersion=15.0 to the MSBuild arguments in the build definition.
Can someone give me a hint of what else to check? I'm running out of ideas.
I did see that the error message contains this:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(511,5): error MSB8008: Specified platform toolset (v141) is not installed or invalid.
The path contains v4.0, shouldn't it be v15.0? Is there a reference to something that is incorrect?
However, this doesn't seem to be a problem in another project that is built in VS2015 so I'm not sure this is a problem.
I hope someone can help me.
Regards
Mattias
Build cant find platform toolset v141
As far as I know, you may had to amended the build templates to point to MSBuild version 15.0. There are two parameters including ToolPath and Toolversion to set, edit template change msbuild activity ToolPath to "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.exe".
For some more details, you can check the thread BuildActivity ignores ToolsVersion for more details.
Hope this helps.
I am installing a C# windows service that uses Geode onto a UAT Windows 2012 server. The referenced dll (like log4net, newtonsoft.json and QuickFix) are working except for Pivotal.Gemfire.dll
When I start the service I get System.IO.FileNotFoundException: Could not load file or assembly 'Pivotal.Gemfire.dll' or one of its dependencies. The specified module could not be found. File name: 'Pivotal.Gemfire.dll'
Now Gacutil doesn't come with Win Server 2012. I've tried installing Windows SDK and .Net SDK and not found a Gacutil executable. So I've tried to get in the dll into the GAC using powershell like this:
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("D:\Pivotal.Gemfire.dll")
I've tried regsvr32 Pivotal.Gemfire.dll in various flavours
I've tried compiling and running the GacInstall executable at https://github.com/apache/geode-native/tree/develop/executables/GacInstall. It says Installation completed successfully. but when I try to run the service, or try powershell:
([system.reflection.assembly]::loadfile("D:\Pivotal.Gemfire.dll")).FullName
I get the same error.
I've tried a private assembly using runtime assembly binding
<runtime>
<assemblyBinding
xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Apache.Geode" publicKeyToken="null" culture="neutral" />
<codeBase version="9.1.1-build.2" href="file://Pivotal.Gemfire.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
and various flavours of name Pivotal.Gemfire, Apache.Geode.Client according to Implementing Shared Assembly but always the same error.
Any ideas? Thanks...
UPDATE: Make sure you have x86 and x64 bit C++ packages back to 2013 (for older versions of Geode Net client)
I downloaded the previous version of Geode, 9.0.7, called Gemstone.Gemfire.Cache.dll and got the same error, but that version included a Gemstone.Gemfire.Cache.xml in the same directory. If I took the xml file to my bin directory the error stopped and the service started properly.
So like this the problem is a redundant accompanying xml file to the dll. I fixed the issue by creating a new dummy xml file Pivotal.Gemfire.xml
<?xml version="1.0"?>
<doc>
</doc>
For me the marked answer did not work.
I had to download DependencyWalker which showed me why the Pivotal.Gemfire.dll was not working. One of missing DLLs was from:
Visual C++ Redistributable Packages for Visual Studio 2013
After installing 64x bit, application started to work.
This problem happened again with another install. The answer above using the xml file did not resolve it, it was resolved by downloading version 9.0.7 of the Native Client, Gemstone.Gemfire.Cache.dll and then running
.\gacutil /if C:\Gemstone.Gemfire.Cache.dll
which returned Assembly successfully added to the cache then removing the earlier version of the dll, but retaining the later version Pivotal.Gemfire.dll that I could not get into the GAC because of a strong name issue. This bizarre workaround of getting the earlier version of the dll into the GAC allows the GAC to find - and use - the later version...
This happened to me again with a Geode Native built locally, when it is run on a new Windows 10 install the dependency walker shows missing MSVCP140D.DLL VCRUNTIME140D.DLL and UCRTBASED.DLL as here
The D is related to having built the client in debug mode.
The problem is related to How can I install a Visual Studio C++ redistributable if it is missing? and the answer is either to get a release build of your dll, or to go to Visual Studio Installer, Modify, navigate to Individual components -> compilers, build tools, and runtimes, and check the MSVC v 140 VS 2015 C++ build tools
Yet another time this happened to me and I had to remove references and files to Apache Geode dll built as native client, then reference them all again.
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.
When I build a visual studio 2008 setup project, I get the following warning:
"Could not find prerequisite '.NET Framework 3.5 SP1' in path 'C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\Bootstrapper\'"
There is not a Bootstrapper folder under my v6.0A folder. Do I need one? Is this warning important? The project's .msi file seems to work fine.
That is for creating the setup.exe which ensures all prerequisites for your application are installed. It doesn't affect your msi.
You can change your prerequisites by going to the properties of your setup project, click prerequisites button on the bottom right, and set the install location to download from the vendors site.
You can also disable the creation of this file by unchecking the top checkbox in the prerequisites window.
You may try to download this.
Also you may try to follow the directions in 2.3.1.1 Enable Samesite for the .NET Framework 3.5 SP1 bootstrapper package
Please excuse the large amount of background info, but this is a fairly specific question.
I have a Visual Studio 2005 project that creates a .dll file. This project depends on a .dll from another company, "BigCorp", which gets installed with BigCorp's software.
Ideally the dll I create should be usable with any (backwards compatible) version of BigCorp's dll. That is, if I link against version 4.3.2.100 my program should still work if the user upgrades BigCorp's app so that the .dll is version 4.3.3.20.
This is straightforward enough in VS2005, by looking at the project's References, selecting the .dll and making sure the "Specific Version" property is false.
Now for my actual question: Is it possible to specify a base version of the .dll that is older than the one installed on the machine that is building the project? Continuing my previous example, my build machine has version 4.3.3.20 installed, but I want the .dll it generates to be compatible with installations that haven't upgraded, and only have version 4.3.2.100 installed.
It seems that VS resolves the path to the .dll and detects the runtime version based on the file it finds. Trying to override it by specifying the version number directly in the .vbproj or .csproj, i.e.,
<Reference Include="BigCorp.Program.Component, Version=4.3.2.100, Culture=neutral, PublicKeyToken=abc123def456654fed321cba, processorArchitecture=MSIL">
has no effect. Trying to register my assembly on a computer that has the older version fails with the good old "Could not load file or assembly" error because it tries to find the newer version of BigCorp's .dll.
Is what I want to do even possible?
You can do this by referencing the older DLL directly from the project, so copy the .dll file to your project, then reference it from there.
I do this all the time with my various development projects. Typically I'll put a "References" folder inside my project to hold referenced DLL's