It seems like something is wrong in the "Select and configure packages". I can execute and build x86 and x64 packages normally, but when I go to "create package" to upload it to the windows store, x86 option appears with "mixed platform" configuration only, no x86. And in the x64 architecture the x86 configuration is selected by default,I changed it to x64 but when compiling to create the package lots of errors appears.
UPDATE
I removed unnecessary build configurations, just left ARM, x64 x86.
but when building the package from the "Create package" option everything is broken again.
Related
I have Windows 11 with Visual Studio 2022, and Cuda toolkit 11.7.99. After installing Cuda toolkit, it worked fine in Visual studio, and is also in my PATH in cmd.
However, when I try to create a new Cuda executable project in CLion, the CMake complains that failed to detect a default cuda architecture.
I had to go to File -> Settings -> Build, Execution, Deployment -> Toolchains and do both:
change default from MinGW to Visual Studio
Change "architecture" from x86 to amd64
After that, everything worked fine.
Not sure why it defaulted to x86, I think this is a bug in CLion or CMake; it really should be able to detect what architecture I'm using.
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 have correctly compiled Boost for Windows 8 with VS-10 as given in this link. My project works fine. But when I copy the project to another Windows 7 machine it returns an error message as "The application was unable to start correctly (0xc000007b). Click OK to close this application.". I have correctly installed Boost in the second PC as well. Both PCs are 64-bit and I installed 32-bit Boost in both. As I found from some links this is because the project try dynamically linking 64-bit libraries instead 32-bit. Could you kindly advice how to build this as a portable solution. Thanks in advance.
Update 1:
Following is the dependency walker output.
Are you sure you selected the Visual Studio 2010 Command Prompt x86 to compile the library? or the x64 version? there is more than 1 version of the command prompt in the start menu. my guess would be that you accidentally ran the x64 version, and then compiled boost with it, resulting in a x64 bit version of the library compiled.
Here's a batch file that compiles the static and shared version of boost in x86:
compileboost.bat:
call "%vs110comntools%..\..\VC\vcvarsall.bat" x86
cd C:/boostsourcefolder/
call bootstrap.bat
.\b2 runtime-link=static
.\b2 runtime-link=shared
Then in your VS2010 project properties, Common Properties -> VC++ Directories -> Include Directories, type your boost folder (C:/boostsourcefolder/). and in Common Properties -> VC++ Directories -> Library Directories, type the boost compiled library folder (C:/boostsourcefolder/stage/lib/).
That's pretty much all you need to do.
I compiled a x64 application in win32 development environment.. When I run that binary in 64 bit intel machine , the following error is displayed
"The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail."..
In the event log it is mentioned that
"Activation context generation failed for . Dependent Assembly icrosoft.VC80.DebugCRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0" could not be found. Please use sxstrace.exe for detailed diagnosis.
What is this issue and how to resolve this problem ?and architecture of the target system is amd64.
C:\>set | findstr /i amd64
PROCESSOR_ARCHITECTURE=AMD64
The error indicates, that you are trying to run a debug build on a machine that has no debug C runtime installed. The debug runtime is not redistributable, so your current application will only run on a machine with VS2005 installed.
To fix this issue, change the build flavour from Debug to Release and try again.
You also need to make sure, the lates C runtime libraries are available on the target machine. This page holds the lates VS2005 redistributable runtime installers for all supportet target platforms .
I installed the combined package of ICC 11.0.066 for x86 & x64 targets, with all options (IPP, TBB, MKL). Attempting to run the uninstaller from Control Panel > Programs and Features immediately errors out with the dialog:
Another instance of uninstall was launched.
Please wait while it is finished ...
This happens after having also uninstalled VTune (successfully), but does not resolve itself after reboots, etc.
How is it possible to force the Intel Compiler to uninstall and clean up after itself?
The downloadable installers for Intel software development tools extract their install packages by default into:
c:\Program Files (x86)\Intel\Download
It is possible to re-run
C:\Program Files (x86)\Intel\Download\C++CompilerPro11.0\Setup.exe
manually. This will include both Repair and Uninstall options, both of which should complete successfully. If the extracted setup files are not still intact, it should be possible to recreate them by re-running the downloaded installer package for the same version.