I am creating WiX installer to drop my custom VS 2010 extension inside Visual Studio Extensions folder. I want to use the system environment variable VS100COMNTOOLS to figure out the VS installed path inside WiX script. I would like to use a relative path syntax like %VS100COMNTOOLS%\..\IDE\Extensions to get to the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions folder or wherever user chose to install VS 2010.
Can somebody please suggest me how I achieve this in Wix script?
WixVSExtension has a bunch of properties available for Visual Studio paths. Not that one in particular but you can use the technique outlined in the question Erik pointed out to construct it from one of the WixVSExtension properties.
Related
I am creating an installation file using VS2019 which creates two files setup.exe and install.msi. Is it possible to bundle them together for easier distribution into one setup file. Previously I used iexpress to bundle them together and using custom.bat file to execute setup after extracting. Though this is an very old technique, Is their any more innovative way we can use directly from VS2019 ?
I found this guide which makes use of Advanced Installer through a Visual Studio extension. I was able to take two projects in a solution and package them into one .msi, which installs both of the project executables when ran.
You will need to download the "Advanced Installer" Visual Studio extension (see the "Extensions" menu item in Visual Studio), as well as install Advanced Installer itself, which can be found here (the extension will prompt you to download Advanced Installer if you attempt to use it without having it installed). All the extension does is make use of the Advanced Installer software, but through Visual Studio. Once you have it all configured, all you need to do is perform a build on the Advanced Installer project that you will need to add to your solution.
We are developing an InstallShield 2013 LE installer using Visual Studio 2013 Ultimate.
We are already familiar with manual modifications of the .isl file and .isproj file. We know how to do property and path variable overrides from the .isproj file, as well as analyze the Directory, File, PathVariable, and other tables in the .isl file.
In InstallShield 2013 LE, you can choose to install to "Program Files (x86)" or "Program Files" in the Files view of the ISLE editor before build time. The problem we are facing is as follows: we need to make the choice between installing to "Program Files (x86)" and "Program Files" at build time. if the MSBuild Platform property is x86, we need to install to "Program Files (x86)". If the MSBuild Platform property is x64, we need to install to "Program Files".
Can this be done? Are we missing something obvious? This seems like something that should be standard in a basic installer.
We are currently playing around with using property override to override a custom made CustomProgramFilesFolder property.
So far we haven't gotten this to work...not sure what we are doing wrong.
InstallShield LE (Limited Edition) is the "free" version of InstallShield that is very limited. The type of things you are talking about are available in InstallShield Professional where you have access to such things as Product Configurations and the Automation Interface.
Another possibility is to factor all of your component authoring out into merge modules using Windows Installer XML and keep your InstallShield LE projects as very thin veneers with 1 .ISE wired as 32bit and 1 .ISE wired as 64bit. Or just go all WiX.
But you really are trying to use a pocket knife as a chainsaw.
I created an installer for MVVM Light and part of the installation is about code snippets for Visual Studio 2010, 2010 Express and 2008. Unfortunately, the code snippets are installed into a folder with a LCID (culture code, for instance 1033 for en-US). If the snippets are not in the correct folder/LCID, Visual Studio doesn't load them (yes, utterly stupid I know. But this is what we have...)
When VS is installed in English, all is well. However when a Geman (for instance) version of VS is found, the snippets fail to register in VS.
Is there a way in Wix to detect the LCID and to use that as a property, in other words to install the snippets in the correct folder depending on the LCID? I know about multilanguage installers but it seems like a bazooka to kill a fly. Any other idea?
Thanks,
Laurent
The user's locale is available in the UserLanguageID property. You need a SetDirectory to assign the runtime value to a directory's name.
I have a CruiseControl .NET build server running on Windows Server 2003, and I am trying to build and publish my ClickOnce application using msbuild.
Everything is working fine, except when I enable the bootstrapper of my ClickOnce application. When this happens, I get the following error in the DeploymentGenerateBootstrapper target:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3939,9):
error MSB3147:
Could not find required file 'setup.bin' in 'E:\Projects\src\TestProject\Engine'.
.NET Framework 3.5 SP1 and 4 and latest Windows SDK for both are installed on the server, but the bootstrapper folder in C:\Program Files\Microsoft SDKs\Windows\versionNo\ does not exist. I tried copying the files from my workstation machine with no luck.
I do not want to install Visual Studio on server and only install the necessary SDKs.
I have also tried copying the bootsrapper folder from my machine
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper
to build server but no luck.
Any ideas?
You will also have to add the associated key and value to the registry to allow MSBuild to find the path to the Bootstrapper folder. I can confirm that this has worked for me using the following regedit.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\4.0]
#="0"
"Path"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\Bootstrapper\\"
Update: According to Emma's TFS Blog it appears the following registry values are checked in order to find the bootstrapper path and if not found looks in your local project folder under the Engine sub folder and then bails with the MSB3147 error if not found there.
HKLM\Software\Microsoft\GenericBootstrapper\<.NET Tools Version>\
HKLM \Software\Microsoft.NetFramework\SDKInstallRoot\Bootstrapper
HKLM \Software\Microsoft\VisualStudio\\InstallDir\Bootstrapper
Reminder: Also remember that there is a 32-bit and a 64-bit registry so be sure to add this value to the same registry that your tools will be accessing.
In the meantime I've also created a feature request to get a more reasonable solution for this issue. Please vote on my feature request to get Microsoft to take a look at it.
BTW, here are a few more links about this issue:
http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/7672078f-f2bd-4142-b8a9-740c2a8a5ae7
http://social.msdn.microsoft.com/Forums/en/msbuild/thread/6964ba78-5b66-4cd1-bdd1-b31edb76b96a
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/97ac8717-daf7-4554-8dfa-8a63da47a17d
MSBuild: error MSB3147: Could not find required file 'setup.bin'
https://connect.microsoft.com/VisualStudio/feedback/details/361924/remove-bootstrapper-from-microsoft-sdks-directory
http://blogs.msdn.com/b/emmamou/archive/2009/04/08/team-build-for-clickonce-application-with-bootstrapper.aspx?CommentPosted=true#commentmessage
You can also pass the location of the bootstrapper packages to the common Publish target like this:
<PropertyGroup>
<BootstrapperSdkPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper</BootstrapperSdkPath>
</PropertyGroup>
and then
<Target Name="Publish">
<MSBuild Targets="publish" ... Properties="GenerateBootstrapperSdkPath=$(BootstrapperSdkPath); ..."/>
</Target>
I struggled with the same problem on my win7 x64 machine. I have not installed Visual Studio and tried to build and publish a .NET 4.5 WPF solution. I had to add the following keys to the registry
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\11.0]
"Path"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v8.1A\\Bootstrapper\\"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\4.0]
"Path"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v8.1A\\Bootstrapper\\"
You also need to copy the Bootstrapper folders from your dev machine. This blogpost directed me in the right direction http://www.wiktorzychla.com/2013/11/msb3147-could-not-find-required-file-on.html
I had a similar issue to this but in my case I do have Visual Studio installed on the box, and publishing from Visual Studio works fine.
When publishing from the command line with msbuild.exe, the build failed with aforementioned error "MSB3147 Could not find required file 'setup.bin'".
The solution was to explicitly specify what version of Visual Studio to use during build.
<MSBuild
Projects="MyProject.csproj"
Targets="publish"
Properties="Configuration=Release;PublishUrl=C:\AnyFolder;VisualStudioVersion=12.0"/>
I have Visual Studio 2013 on a Win7 x64 machine. My reading of the problem is that MSBuild was looking in the wrong place in the registry. By explicitly telling MS Build to use VS 12.0, it picked the correct registry location entry and consequently the correct path to BootstrapperSdkPath.
I was able to fix this problem by pointing to MSBuild.exe from this location
C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
Previously I was pointing to
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Hi I know this answer its soooooo late but just in case
I had to add the Path prop to the task, with the Path where the bootstrapper its located, in my case I used Visual Studio 2015 so the Path is:
**Program Files(x86)\Microsoft Visual Studio 14.0\SDK\Boostrapper**
MSBuild has a Task GenerateBootstrapper in my case
<GenerateBootstrapper>
AplicationFile="$(AppName)"
ApplicationName=..
ApplicationUrl=..
BootstrapperItems=..
Culture=..
ApplicationUrl=..
Path="Program Files(x86)\Microsoft Visual Studio 14.0\SDK\Boostrapper\"
</GenerateBootstrapper>
with this the MSBuild is able to recognize and generate the file
Now i'm stucked with the .net 4 bootstrapper but guess is another story...
I experienced this same error via my TeamCity build server. The cause in my case was that I was running an MSBuild task against my .sln file, with a 'MyProject:publish' target. In this case, the solution+projecth had been updated to target .NET v4.5, but the build server was still configured to use MSBuild Tools 4.0 and .NET v4.0.
Took me a little while to work out the inconsistency between working and non-working branch builds.
I added this line to script. It helped.
call "%VS120COMNTOOLS%vsvars32.bat"
Visual Studio 2013, SDK v8.1A.
Just struggled with this myself - I chose to commit the bootstrapper files to source control. It is possible to override the path to bootstrappers, just provide /p:GenerateBootstrapperSdkPath=.build\Bootstrapper
Then no need to modify registry - and the added benefit that the build is now self-contained.
Only "problem" is that I have to manually copy the Bootstrapper files into source control. In my case (VStudio2015), this meant copying the files from C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper
Background:
I always try to ensure the following tenet in my projects:
After a fresh checkout a developer should be able to do all project related tasks with solely the contents of the combined folders.
Obviously, this isn't always possible (e.g. Visual Studio for Windows development). However, I really dislike having to install any third-party libraries or tools that are specific a project like log4net, NHibernate, NUnit, etc. There are number of reasons for this including:
For a given development machine, you may work on several different projects, all which leverage different versions of the same third-party library or tool.
Minimizing the environment setup requirements makes setting up new developers or machines much easier
Facilitates easier maintenance of automated builds
Assumptions/Contraints
I am currently using WiX 3 beta, but if there is way for either 2.0 or 3.0 please respond
I am using Visual Studio 2005
The IDE syntax highlighting is not a requirement.
Question:
Is it possible to avoid local installation of the WiX toolset and use flat files instead? If so, please explain how.
See Also:
First, build your WiX installer:
Create a new WiX Installer Project in Visual Studio 2005.
Build your WiX XML accordingly.
Now, to integrate the WiX toolkit into your source tree:
Copy c:\Program Files\Windows Installer XML v3\bin to a sub-directory in your source tree. I used WiX\bin relative to my .wixproj file.
Copy c:\Program Files\MSBuild\WiX\v3.0\ to a subdirectory in your source tree. I used WiX\v3.0 relative to my .wixproj file.
Either add the following code or replace the line that follows:
<WixTargetsPath Condition=" '$(WixTargetsPath)' == ''>$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets</WixTargetsPath>
With the following lines:
<WixToolPath>$(MSBuildProjectDirectory)\WiX\bin\</WixToolPath>
<WixTasksPath>$(MSBuildProjectDirectory)\WiX\v3.0\WixTasks.dll</WixTasksPath>
<WixTargetsPath>$(MSBuildProjectDirectory)\WiX\v3.0\Wix.targets</WixTargetsPath>
As you can see, the WixToolPath, WixTasksPath and WixTargetsPath directives reflect the location of the folders I've instructed you to copy.
Rename your .wixproj to .csproj. This ensures that Visual Studio does not get confused by the .wixproj file but because the .wixproj is a valid MSBuild project, Visual Studio will be able to work with it.
Using this method, the WiX directory as described is about 9MB large.
I know with WiX 2, you can just download the executable files and the dll's to whatever directory your project is in. Then you create a .bat file to run candle.exe and light.exe with the parameters you need to build your installer.
That way, all your projects can have their own version of WiX with a disk drive hit of only about 4 megs each.
I'm not positive, but I think you can do the same with WiX 3.