When I compile a wix project, and wix launch the compilation via MSbuild of all the existing projects, can I use "Any CPU" instead of "X86" or "64 bit" ?
If not, how can I compile the projects using "Any CPU" ?
If your question is whether you can compile WIXPROJ for Any CPU then the answer is no.
"WiX projects will not be built when building the 'Any CPU' platform
because Windows Installer packages are CPU-specific."
The TargetPlatform setting in your WIXPROJ defines the way Windows Installer treats folder variables, registries and GAC etc. For example, the setup project will use the [ProgramFiles64Folder] variable if the TargetPlatform of the setup project is x64; and [ProgramFilesFolder] for x86.
Check this answer, it will be helpful:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Any-CPU-platform-in-wix-3-0-td3441097.html
Step1: Go to solution Properties
Step2: Configuration properties --> Configuration
Step3: Check the build option for WIX project.
Related
I am having issues with trying to create a Visual Studio Deployment Project via command prompt.
I have a visual studio 2015 installer I am trying to create, I am running the following command:
devenv.exe <SolutionName>.sln /Build "Release|Any CPU" /Project "<InstallerProjectName>.vbproj" /ProjectConfig "Release|Any CPU"
I also read that maybe the dependent projects need to be built as well, so I have also tried that as follows:
devenv.exe <SolutionName>.sln /Build "Release|Any CPU" /Project "<ProjectName>.vbproj" /ProjectConfig "Release|Any CPU" /Project "<InstallerProjectName>.vbproj" /ProjectConfig "Release|Any CPU"
No matter what I have tried the installer project does not build and it gives an error (pop's up the Microsoft visual studio helper window)
If I run the code without the installer such as the follow that project will be built just fine.
devenv.exe <SolutionName>.sln /Build "Release|Any CPU" /Project "<ProjectName>.vbproj" /ProjectConfig "Release|Any CPU"
What I am missing to get the installer project to build?
clarity:
- for devenv.exe I am pointing straight to the devenv.exe for VS 2015, I do have multiple versions of VS installed
- I am using "" around the locations paths to deal with the spaces in the names
- language is VB.Net
Suggestions that help to locate the cause of issue and then resolve it.
1.Try using devenv.com instead of devenv.exe, so that you can quickly get output info.
See this: Using devenv.exe directly prevents output from appearing on the console.
2.For installer project, it doesn't have platform like Any Cpu. See this:
For Release|Any Cpu solution configuration, the installer project(Setup1) doesn't have Any CPU project platform by default. Which mean your /ProjectConfig "Release|Any CPU" is not valid. I think it can build if you changes it to be /ProjectConfig Release
3.And make sure your path is all right. For me, I opened Developer Command Prompt for VS2015 and then navigate to solution folder by cd C:/solutionPath. Then i use command like this to build the installer project:
Normally the project file is in SolutionPath/ProjectName(one folder)/projectName.vdproj, so I use InstallerProjectName\InstallerProjectName.vdproj instead of InstallerProjectName.vdproj. (You may need to correct the InstallerProjectName.vbproj to InstallerProjectName.vdproj in your question...)
And now the devenv command will actually try to build the installer project. And if you meet HRESULT='8000000A', it's known issue about installer project. Check my another issue for more details to resolve that. (For VS2015, you should use corresponding way of VS2015)
Hope it helps:)
My Windows app has 2 build configurations - x86 & x64.
I have 2 setup projects - one targeting the x86 build to produce a 32-bit MSI, and one targeting the x64 build to produce a 64-bit MSI.
In each setup project, I have added the project output for the specific configuration, e.g. Release | x86 for the x86 Setup Project. This pulls in the detected dependencies (other projects in the solution).
Problem: When I build my project and then look at the source path property of my dependencies, they default to the x86 versions, even if the x64 project output was added as primary output. For example, in my x64 Setup Project, if I build the x86 version in VS, then my x64 setup project dependencies will be pulled from the bin\x86 folder and not the bin\x64 folder.
Ideally I would like the dependencies to remain consistent with the type of Primary Output selected i.e. if my primary output is added from the x86 build, then I want all my dependencies referenced from the bin\x86 folder. If my primary output is added from the x64 build, then I want all my dependencies referenced from the bin\x64 folder.
I am curious to know if there is a way where I can stop the detected dependencies from auto-updating to match the last build configuration in Visual Studio.
I'm trying to build V8 as part of ArangoDB using the official build scripts and following the official Windows build instructions.
The compilation fails for all v8* targets (v8-build.bat):
msbuild All.sln /t:v8 /p:Configuration=Release /p:Platform=x64
msbuild All.sln /t:v8_libbase /p:Configuration=Release /p:Platform=x64
msbuild All.sln /t:v8_libplatform /p:Configuration=Release /p:Platform=x64
error MSB4057: The target "v8" does not exist in the project.
If I open the solution file in Visual Studio, it looks like this:
I can build v8, v8_libbase and v8_libplatform just fine in VS.
Windows 7 64bit
Visual Studio 2013 Ultimate
Cygwin 2.2.0
cmake 3.3.1
You can run
set MSBuildEmitSolution=1
msbuild All.sln /t:v8
Then search in the generated All.sln.metaproj file the exact target names (<Target Name="">) of all projects you want to build. v8 can have a name like _tools_\_gyp_\v8. After that you can build projects
msbuild All.sln /t:"_tools_\_gyp_\v8" /p:Configuration=Release /p:Platform=x64
The correct way to specify a target/project if it's in a solution folder is:
msbuild all.sln /t:PATH\TO\PROJECT
But in case of (tools) and (gyp) it's simply not possible, because msbuild can't handle parentheses in the target parameter /t.
So either remove ( ) and specify the path like tools\gyp\v8, or get rid of the solution folders entirely. If the solution is flat, /t:v8 will work.
Unfortunately, both the wrapping of folder names with brackets as well as the generation of non-flat .sln are hardcoded in gyp, which generated my all.sln. There is no switch to control whether solution folders are created or not. It will create them if the target version of Visual Studio is known to support this kind of nesting.
Workaround: Force flat solution generation in gyp, see
https://github.com/arangodb/arangodb/commit/796d2d263db6271142d954c8c99b9dec0fbe75e9
Reported errors to Microsoft/msbuild and Google/gyp:
https://github.com/Microsoft/msbuild/issues/157
https://code.google.com/p/gyp/issues/detail?id=494
#dothebart and this post helped me a lot to figure it out, thank you!
In VS2013 use
msbuild All.sln /p:Project=v8;Configuration=Release;Platform=x64
I'm currently setting up project in Visual Studio Online (VSO) and having troubles with setting up automated build.
My solution contains projects targeted as Universal Windows
VSO uses msbuild to run my project.
During build I see strange error messages like:
Error CS0518: Predefined type 'System.Void' is not defined or imported
Error CS0518: Predefined type 'System.Object' is not defined or imported
Error CS0246: The type or namespace name 'Uri' could not be found (are you missing a using directive or an assembly reference?)
msbuild is invoked with following parameters:
C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe "C:\a\b0d9e3fd\test\src\Shipping.sln" /nologo /m /nr:false /fl /flp:"logfile=C:\a\b0d9e3fd\test\src\Shipping.sln.log" /dl:CentralLogger,"C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agent\worker\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"*ForwardingLogger,"C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agent\worker\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:Platform=Win32 /p:TargetVersion=”Windows10” /p:TargetPlatformVersion=”10.0.10010.0” /p:platform="any cpu" /p:configuration="release" /p:VisualStudioVersion="14.0"
What's wrong with this? Are there any other additional parameters required to build universal windows app with msbuild?
Are you targeting the Windows 10 SDK? If so note that it is not installed on the TFS hosted build servers. Consequently you will not be able to build apps that use the Windows 10 SDK. You can see the complete list of installed software here.
Just found the solution.
If build UWP app, from VS it resolves NuGet dependencies automatically. By default VS 10 projects uses NuGet of 3rd version, which was not installed on our build machine. That's why we had such issue.
The problem was fixed with installing NuGet 3 onto build agent and configure script which resolves NuGet packages before build.
If you can't customize the software of your build agent (aka: the free Hosted Agent) another work-around is to just check in your project.lock.json file.
This is because NuGet v2.8.7 can read both project.json and project.lock.json files but it cannot generate a project.lock.json file from a project.json file.
And, if at such a time Microsoft updates NuGet for their default build agents, you can just remove it from source-control and let it generated automatically as part of Nuget -restore. Until then, just check it in.
For C++ projects I can do this:
SET CL=/DMYDIRECTIVE
devenv.exe MySolution.sln /rebuild
What is the C# version (visual studio 2008) of this trick?
Go to the Build tab in Project Properties
On the command line, csc /define:MYDIRECTIVE
The following command lists you the options of the C# compiler
csc.exe /?
The respective option is
/define:<symbol list> Define conditional compilation symbol(s) (Short form: /d)
However, for command-line building a C# project you might prefer MSBuild. With MSBuild, it is probably easiest to create a configuration using Visual Studio's Configuration Manager that already defines appropriate conditional compilation symbols. You can then select one of the configurations from the MSBuild command line:
MSBuild MySolution.sln /t:Rebuild /p:Configuration=ReleaseWithMyDirective