I'm working on a solution in Visual Studio 2017 where there are several projects intended to separate functionality. Those projects are then added as dependencies of other projects.
I'm trying to build a 64-bit exe of the top level project but for some reason some 32-bit dlls are leaking into the build.
------ Build started: Project: LeadtoolsLib, Configuration: Debug x64 ------
LeadtoolsLib -> C:\Users\its-rowc\source\Workspaces\Imaging\LeadTools\bin\x64\Debug\IQLeadtools.dll
------ Build started: Project: LeadtoolsLib, Configuration: Debug Any CPU ------
LeadtoolsLib -> C:\Users\its-rowc\source\Workspaces\Imaging\LeadTools\bin\Debug\IQLeadtools.dll
------ Build started: Project: WebServicesWrapper, Configuration: Debug x64 ------
WebServicesWrapper -> C:\Users\its-rowc\source\Workspaces\Imaging\WebServicesWrapper\bin\x64\Debug\WebServicesWrapper.dll
------ Build started: Project: IQHyland, Configuration: Debug x64 ------
IQHyland -> C:\Users\its-rowc\source\Workspaces\Imaging\IQHyland\bin\x64\Debug\IQHyland.dll
------ Build started: Project: PDFConverter, Configuration: Debug x64 ------
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "Leadtools.Codecs", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "Leadtools.Codecs.Fax", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "Leadtools.Codecs.Tfx", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "Leadtools.Codecs.Tif", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "Leadtools", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "Leadtools.Pdf, Version=19.0.0.0, Culture=neutral, PublicKeyToken=9cf889f53ea9b907, processorArchitecture=x86", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
PDFConverter -> C:\Users\its-rowc\source\Workspaces\Imaging\PDFConverter\bin\x64\Debug\PDFConverter.dll
------ Build started: Project: DocProcessor, Configuration: Debug x64 ------
DocProcessor -> C:\Users\its-rowc\source\Workspaces\Imaging\DocProcessor\bin\x64\Debug\DocProcessor.exe
------ Build started: Project: IQHylandTest, Configuration: Debug x64 ------
IQHylandTest -> C:\Users\its-rowc\source\Workspaces\Imaging\IQHylandTest\bin\x64\Debug\IQHylandTest.exe
------ Build started: Project: IQHylandUnitTest, Configuration: Debug x64 ------
IQHylandUnitTest -> C:\Users\its-rowc\source\Workspaces\Imaging\IQHylandUnitTest\bin\x64\Debug\IQHylandUnitTest.dll
========== Build: 8 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
The general hierarchy is as follows:
PDFConverter .exe (64-bit exe with some incompatible 32-bit dlls)
IQHyland
LeadtoolsLib
Leadtools.dll (32-bit!)
WebServicesWrapper
IQHyland .dll (only 64-bit gets built)
LeadtoolsLib
Leadtools.dll (64-bit)
LeadtoolsLib .dll (both 32 and 64 bit get built, why?)
WebServicesWrapper .dll (only 64-bit gets built)
The issue is that at the top level, the 32-bit .dlls from the LeadtoolsLib project are being included rather than the 64-bit dlls.
PDFConverter depends on IQHyland which depends on LeadtoolsLib, however PDFConverter also directly depends on LeadtoolsLib, which I imagine might be causing the issue, though I still don't know why it wouldn't get the 64-bit version of the dlls considering PDFConverter itself it a 64-bit target.
When I do the build, only 64-bit targets are built EXCEPT for LeadtoolsLib which has both 32-bit and 64-bit targets built. I don't know why the build thinks the 32-bit version is required by anything.
Any idea?
Edit:
Configuration manager
Not shown "WebServicesWrapper /Debug/x64/ build checked.
2>------ Build started: Project: WebServicesWrapper, Configuration: Debug x64 ------
1> LeadtoolsLib -> C:\Users\its-rowc\source\Workspaces\Imaging\LeadTools\bin\x64\Debug\IQLeadtools.dll
3>------ Build started: Project: IQHyland, Configuration: Debug x64 ------
2> WebServicesWrapper -> C:\Users\its-rowc\source\Workspaces\Imaging\WebServicesWrapper\bin\x64\Debug\WebServicesWrapper.dll
3> IQHyland -> C:\Users\its-rowc\source\Workspaces\Imaging\IQHyland\bin\x64\Debug\IQHyland.dll
4>------ Build started: Project: PDFConverter, Configuration: Debug x64 ------
4>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "Leadtools", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
4> PDFConverter -> C:\Users\its-rowc\source\Workspaces\Imaging\PDFConverter\bin\x64\Debug\PDFConverter.dll
========== Build: 4 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
When solving this we needed to identify where dependencies are coming from.
There are 2 types of dependencies in Visual Studio: Assembly references (like the dependencies you specify by "Browse..." dialog), and Project references.
To see both types of references you can open Project -> Add Reference...
One way to see just the direct dependencies is to search for "HintPath" in all of project files, e.g. "git grep HintPath" might show something like:
...
myproject.csproj: <HintPath>...\path\to\LeadtoolsLib.dll</HintPath>
...
If you include both Project and Assembly reference for the same assembly, the system might prefer one over the other (in this case the 32-bit library direct reference was preferred for one of the projects).
Related
I'm using VS2019 to build 32-bit release.
1>------ Build started: Project: modulesLib, Configuration: Release Win32 ------
1> Creating library ..\..\GeneratedFiles\Release32\\modulesLib.lib and object ..\..\GeneratedFiles\Release32\\modulesLib.exp
1>Generating code
1>Previous IOBJ not found, fall back to full compilation.
1>\modules\stdafx.h.cpp : fatal error C1083: Cannot open compiler intermediate file: '..\..\GeneratedFiles\Release32\\modulesLib.ipdb': Not enough space
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "modulesLib.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 8 up-to-date, 0 skipped ==========
I already found that removing /GL option temporary solved it but this is not the solution.
I have a lot of free space on system drive as same as drive where compilation occurs. I have 32GB RAM, 64-bit Win10.
Is there any solution? Thanks
Edit: Based on the next observations although C1083 is compiler error the reason is that 32-bit linker is running out of memory (reaches 3GB and than process crashed). I believe I saw somewhere that it's possible to use 64-bit toolset to generate 32-bit apps. But I can't find it now.
Ok, I just solved it.
It's a caused by 32-bit linker (although Cxxx error is compiler error).
I obviously reached 3GB limit for /GL (Whole Program Optimization) switch.
The solution is to tell VS to use 64-bit tools to compile 32-bit app via "Prefered build Tool Architecture" set to 64-bit
The same option can also be set via command line (for MSBuild) or via editing vcxproj: https://learn.microsoft.com/en-us/cpp/build/walkthrough-using-msbuild-to-create-a-visual-cpp-project?view=vs-2019#using-msbuild-with-the-64-bit-compiler-and-tools
I use MS VS 2015 Pro edition 14.0 Update 3 and TACO Update 10. I can build any type of Windows package successfully except UWP. I tried to follow this guide https://taco.visualstudio.com/en-us/docs/tutorial-package-publish-readme/#package-the-windows-version-of-your-app step by step as well. Always I get these errors:
1> Building project: d:\data\zdroje\PhoneGap\Thurisaz\Thurisaz\platforms\windows\CordovaApp.Windows10.jsproj
1> Configuration : release
1> Platform : anycpu
1>C:\Program Files (x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets(170,5): error MSB3779: The processor architecture of the project being built "Any CPU" is not supported by the referenced SDK "Microsoft.NET.Native.Framework.1.3, Version=1.3". Please consider changing the targeted processor architecture of your project (in Visual Studio this can be done through the Configuration Manager) to one of the architectures supported by the SDK: "x86, x64, ARM". [d:\data\zdroje\PhoneGap\Thurisaz\Thurisaz\platforms\windows\CordovaApp.Windows10.jsproj]
1>C:\Program Files (x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets(170,5): error MSB3779: The processor architecture of the project being built "Any CPU" is not supported by the referenced SDK "Microsoft.NET.Native.Runtime.1.4, Version=1.4". Please consider changing the targeted processor architecture of your project (in Visual Studio this can be done through the Configuration Manager) to one of the architectures supported by the SDK: "x86, x64, ARM". [d:\data\zdroje\PhoneGap\Thurisaz\Thurisaz\platforms\windows\CordovaApp.Windows10.jsproj]
1>MSBUILD : cordova-build error : Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
1>MDAVSCLI : error C: \Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
Please, could anybody let me know, how to solve the issue?
I am building a Windows OpenGL application with bullet physics support.
My development environment setup is :
OS : Windows 7 SP1 64 bit
IDE ; Visual Studio 2010 SP1
BulletPhysics - bullet-2.82-r2704
My application has two configurations i.e. Win32 and x64.
Here's my step to build the Windows application :
First I execute the vs2010.bat file in "bullet-2.82-r2704\build".
I add project files from vs2010 folder created by step 1 into my visual studio solution.
Add project dependencies for BulletDynamics, BulletCollision and LinearMath
Add References for all the thee bullet libraries.
Now when I build my solution for both the configurations (i.e Batch Build for Win32 and x64), everything builds properly except for :
x64 Release - with errors like :
BulletCollision_vs2010_x64_debug.lib(btDefaultCollisionConfiguration.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in stdafx.obj
Win32 Release - with errors like :
Win32_Window.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall btConvexInternalShape ...
Win32 Debug - with errors like :
Win32_Window.obj : error LNK2019: unresolved external symbol "public: __thiscall btRigidBody
Final message - Build: 13 succeeded, 3 failed
I am following this help to build my Visual Studio project :
http://bulletphysics.org/mediawiki-1.5.8/index.php/Creating_a_project_from_scratch#Create_a_new_Visual_Studio_project
Note: If I use CMAKE to build VisualStudio solutions for BulletPhysics and then link those separately to my windows application for each CPU architecture then it builds properly (i.e. Build for Win32 and x64 separately).
Is there any way I can make that work with just one Visual Studio solution ?
In x64 Release you are trying to link a static library compiled in debug mode (BulletCollision_vs2010_x64_debug.lib) with object files from your app compiled in release mode (stdafx.obj specifically). Compiler options (_ITERATOR_DEBUG_LEVEL) of your object files and compiler options of a lib don't match (values 0 for release and 2 for debug respectively). That's why linking fails. And in Win32 Debug and Win32 Release cases it looks like you don't link libs at all.
I think that project references went wrong way.
In my opinion while "Project references" is good for C# style of modules, in native development it is more like unnecessary complication of things. Just add plain old libs to linker input explicitly, like this:
..\..\lib\BulletDynamics_vs2010_x64_debug.lib
..\..\lib\BulletCollision_vs2010_x64_debug.lib
..\..\lib\LinearMath_vs2010_x64_debug.lib
Change "debug" and "x64" parts accordingly for each configuration. I think it is more reliable.
Add BulletDynamics, BulletCollision and LinearMath to "Project dependencies" for your app project. That will guarantee that bullet will be built before your app. Check "Build order" tab to make sure that builds go in right order.
Double check that compiler options are the same for each module.
In <Build->Configuration manager> for all "Solution configurations" and all "Solution platforms" (dropdowns above) check that project configurations and platforms are right. (i.e. you don't have projects that use debug when you switch solution to release and vice versa)
Still fails? Take a look at sample Bullet applications, like "App_HelloWorld". Compare it's options to your app's options, and you will surely find a source of error.
Probably, you could make it other way around: add your app project to Bullet's solution (remove unneeded stuff), to see if it works.
I'm trying to get debugging working for a Windows CE 6.0 application but I cannot even start the debugging process. I can run a "Hello World" application OK but when I try to run my app which is linked against another DLL I don't get any error but debuggin does not start. The DLL is present in the same folder as the executable.
This are the logs from VS2005.
1>------ Deploy started: Project: protobuf_lite, Configuration: Release SDK3 (ARMV4I) ------
2>------ Deploy started: Project: libus_cqlink_msg, Configuration: Release SDK3 (ARMV4I) ------
3>------ Deploy started: Project: libus_cqlink_nw, Configuration: Release SDK3 (ARMV4I) ------
4>------ Deploy started: Project: libus_cqlink_cli, Configuration: Release SDK3 (ARMV4I) ------
5>------ Deploy started: Project: CtrlClientWinCE, Configuration: Release SDK3 (ARMV4I) ------
========== Deploy: 5 succeeded, 0 failed, 0 skipped ==========
I also checked dependencies on Executable on Win CE device using peinfo.exe.
This is the log from peinfo.e
Necessary library file(s):
libus_cqlink_cli.dll Is loadable
COREDLL.dll Is loadable
commctrl.dll Is loadable
ole32.dll Is loadable
OLEAUT32.dll Is loadable
Imports Table:
libus_cqlink_cli.dll
OrigFirstThunk: 0016D3AC (Unbound IAT)
ForwarderChain: 00000000
First thunk RVA: 0016E710
Ordn Name
11 ?instance#USPlatformMgr#cs##SAPAV12#XZ (Bound to: 0016D3E4)
COREDLL.dll
I can not figure out what's wrong I am doing.
Please suggest.
Windows CE devices are very often configured with minimal free space for Storage Memory. While using debugger VS must copy some files to Storage Memory (ie. \Windows folder), and if there is not enough space it fails. The solution is to increasing memory level for Storage Memory, its in control panel -> System Properties -> Memory on your device.
I ran into this problem recently (few days ago everything was working fine): Visual Studio 2012 started to refuse to build native WP8 projects.
Today, I created new solution from template 'Windows Phone Direct3D App (Native Only)' to check if my newly created DLLs will be properly supported on WP. I tried to compile this project, first without any changes or additional references - pure code generated by VS. However, it failed with given error.
I know very well what does it mean and what could be the possible reason, but I can't understand, hovewer, where does it come from in this case.
Weird thing: this only happens in 'Win32' configuration, ARM compiles fine:
1>------ Build started: Project: PhoneDirect3DApp, Configuration: Debug ARM ------
.......
Build Summary
-------------
00:11.742 - Success - Debug ARM - PhoneDirect3DApp\PhoneDirect3DApp.vcxproj
but Win32 does not:
1>------ Build started: Project: PhoneDirect3DApp, Configuration: Debug Win32 ------
.......
1>LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
Build Summary
-------------
00:09.725 - Failed - Debug Win32 - PhoneDirect3DApp\PhoneDirect3DApp.vcxproj
My standard (native C++/Win32) projects also work as expected (in both Win32 and x64 platform targets).
Project configuration: (in both platforms)
Linker::Input:
d3d11.lib;%(AdditionalDependencies)
Linker::Ignore:
ole32.lib;%(IgnoreSpecificDefaultLibraries)
VC++ Directories:
Microsoft.ARM.Cpp.User:
$(WP80ToolSetPath)lib\arm;$(WindowsSDK_LibraryPath_ARM);
Microsoft.Win32.Cpp.User:
$(VCInstallDir)lib;$(VCInstallDir)atlmfc\lib;$(WP80ToolSetPath)lib\x86;$(WindowsSDK_LibraryPath_x86)
Any ideas what else could be wrong or configured incorrectly? I'm running out of ideas, I have never seen something like this before.
By the way, I have noticed one more change: when I was trying to compile WP8 projects in ARM configurtion before, there was always an error, saying "building ARM application on desktop is not supported" (or something like that). Now ARM compiles with no problem. Is it normal?
Finally, I have found the reason of my problems: as I suspected, internal Visual Studio configuration has been broken.
I did all standard steps, that can be performed in case of LNK1104, however:
- kernel32.lib was in valid location
- all include and library directories was correct
- standard *.props files were attached to each project
However, the cause was lying elsewhere.
All paths are defined using standard macros. One of them is $(WindowsSDK80Path), which is used to build include/library paths. On my system, this macro was defined as
C:\Program Files (x86)\Windows Phone Kits\8.0
instead of
C:\Program Files (x86)\Windows Kits\8.0
And that's it. I do not know, when or how, this problem arosed. Visual Studio repair via orginal installer was sufficient method to fix everything. All projects compile now without any problems.