Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 months ago.
Improve this question
I've been unable to build C++ projects since upgrading to VS2022. No matter what I do, it cannot programmatically find the Windows SDK files it needs, always claiming MSB8036 (the extremely generic "it can't find the Windows SDK" error).
To be absolutely clear, the version of the Windows SDK that it is looking for (10.0.19041.0) is the one that is installed. At various times, it has been installed using both the Visual Studio installer and the standalone installer (the latter of which apparently fixed this issue for some people). I had even tried installing an older SDK several times, which still failed, even when solutions were specifically retargeted.
EDIT: To be even more clear, I've also tried simple solutions like the one outlined here.
So far, I have tried:
uninstalling and reinstalling (after a recent reinstall, the VS IDE won't load anymore, so I'm stuck with Build Tools)
installing a different edition (Build Tools vs Community)
running sfc /scannow (it found and fixed some errors, but none fixed the issue with MSBuild)
removing the symlinks I had and allowing Visual Studio to install directly to my system drive (to be clear, the symlinks did not cause issues with VS2019, but I was unsure whether VS2022 had issues with them)
running InstallCleanup.exe -f
installing VS2019 again (despite working before, it won't anymore)
checking the environment variables manually (everything points to where the files are located)
checking the registry manually (couldn't find anything, not sure what I'd be looking for)
I was able to get it to pass the check for the Windows SDK by hardcoding the (x64) paths (which were literally the same) into the Microsoft.Cpp.WindowsSDK.targets file, but it would then fail to find windows.h at build time (this is also untenable for non-x64 targets).
I am out of ideas. Has anyone else had this issue? Are there any fixes that don't involve reinstalling Windows?
#john's comment here provided the answer. I then was able to grab the proper SDKManifest.xml from here, which is basically the same as the version given in the video with the Windows SDK version swapped out.
Related
This question is much asked and much answered, but I can't find a single answer that really seems to get to the nub of the problem and which really answers the question as asked. Which is to say, if I simply Create New Project -> Console App -> (choose a name for the project) -> Create then the project is in 32-bit mode. It's trivial to click where it says X86 in the tool bar and change it to X64. Problem solved. You don't even have to go into Configuration Manager or any similar complicated strategies that many answers through the years have suggested. But still, I have to change the X86 to X64 every single time I make a new project. And in addition, the very process of defaulting to X86 has created a gazillion little files and folders for the X86 version of the project that really aren't needed. So the question is not how to make a 64-bit app. That's extremely easy. And the question is not about how to convert a 32-bit app into a 64-bit app. That's also extremely easy. The question is how to configure Visual Studio 2019 Community Edition so that a new project defaults to 64-bit in the first place.
By the way, all the answers on the Microsoft forums start out with "Open the C++ project that you want to configure." But there is no existing project if what you are trying to do is to set the default for new projects. Also, I did find default.vcxproj and played with it a bit. I didn't see anything there that established a default of X86 vs. X64. But I did see that the X86 entries were in front of the X64 entries. I moved the X64 entries in front of the X86 entries, but that did not change the default. It did change the order of the way entries were displayed when I clicked the X86 vs. X64 box in the tool bar. Another promising file was shared.vcxproj. It appears that it may hold the default, but there I haven't yet found any forum messages suggesting that it should be changed to solve this problem.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
As the title says, my MSI that is built in VS 2015 is a whole 4mb smaller than my MSI built in VS 2010. In addition to the file size difference, the Win10 installer only seems to be able to be installed on Win 8+, giving a missing DLL error on Win7. I've tried searching a number of phrases, but I can't find anything that relates to my question. Can anybody shed some light on this? Any ideas would be greatly appreciated. I can provide more information, but I'm not sure what you'd need, so let me know if you need more info.
A few comments of explanation:
MSI files are not built from scratch - they are based on a schema MSI file that's used as the starting point. If the two VS editions use different schemas you'll see different MSI files, especially if support for old stuff was deleted.
MSI files are sparse files, not continuous data streams. If the mechanism for updating the database (which is what MSI files are) is different then the file structure may be different, with less unused space in it.
MSI files contain data other than your files. There are binary files containing bitmaps, calls to detect the NET framework, C++ Dlls to call managed custom actions, all kinds of things that may be different between the two versions of Visual Studio. Any change here will change the size of the MSI file.
Is this an actual issue? I suspect that if somebody used VS 2010 and VS 2015 to generate a 100MB code file, nobody would worry if they came out as different sizes because they are different compilers with different internals.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
I have recently written a fairly simple code for windows app, a 2048 game, including some basics such as icon, background and stuff, 4 buttons for different directions and 4x4 array of static windows for output. The Code isn't really "nice" but as I'm still learning I find it enough since it work ( at least on my PC ). I'm using default VS13 config, haven't changed anything after I installed it and the code is written in c++.
Codes can be found here: https://www.dropbox.com/sh/15y1daq2h3jm8p7/AADp0m1EfUJo3W2z315Zgd0Wa
Now what bugs me is that the program compiles with 0 warnings or errors and works just as I intended it when I run it either via debug or from desktop on my PC, but when I upload it to dropbox and want to start lets say on laptop then it doesn't work.
Also if I try to compile the exact same code in Codeblocks I can't and there are warnings that many functions weren't declared in the scope.
Can any1 explain why is this happening and how can I fix it ?
The basic problem you are facing is that you are trying to compile the code outside of the Visual Studio environment for a VCPP code that you have written.
When you debug the code using Visual Studio, all the required files/dependencies are injected during compilation.
I'd recommend packaging the code using Visual Studio and try running the exe on your laptop.
Make sure you have the correct version of VC++ runtime environment installed on your target machine. (You can optionally also include the setup with your packaged setup.)
From here: https://stackoverflow.com/a/20890610/1477051
As you can see here, the MSVCP DLL is the platform's
implementation of the C++ Standard Library. In short what that means
is you cannot distribute your application without needing the "stuff"
that these libraries provide. All compilers regardless of platform
would need some kind of implementation of the Standard Library.
Typically this is distributed in the form of libraries.
However you can distribute your application so that the "stuff" is
built in to your program directly, rather than being shipped in a
separate DLL. In order to do this, you must statically link your
application to the Standard Library.
There are a few ways to accomplish this. One way is in Project
Settings. In "Configuration Properties" > "C/C++ Code Generation" >
"Runtime Library", choose "Multithreaded (/MT)" as opposed to
"Mutithreaded (Static)".
By the way, the "D" in "MSVCP120D.dll" you mentioned above means
"Debug." This means that you are trying to distribute a debug build of
your program. You should (almost) never do this. Distribute release
builds instead.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed last year.
Improve this question
is there any c++ compiler i can put on a usb or external harddrive and use it on any other computer? the school computjers in my library dont have an ide... or a compiler installed...
P.S the school computers are very tight on securty. i cant even download things from the internet, no websites like facebook, so can i install it on one of the computers? or can i just run it as the actual executable file and run it straight from my usb?
there are several computers with windows 7, and 3 imacs
I'd try Eclipse. And if it doesn't work straight away, try one of those USB-stick program-hosting softwares like U3 (it comes on some Sandisk thumb drives).
Code::Blocks can easily be made portable by setting custom environment variables, described here
At the back-end, C::B can use mingw, which doesn't require any specific install information other than a few environment variables. (namely PATH). These can be set temporarily using SET PATH=%PATH%;./mingw/, which should be possible without elevated privileges.
You might try some of the tools at portableapps.com. They're a group that modifies open source software to run off of USB sticks. I've used their versions of Notepad++, Gimp, and Filezilla for years.
In particular, maybe look at they're development tools: http://portableapps.com/apps/development
It looks like they even have some programs to make other apps portable as well, which you might try with Eclipse, as John suggested. (I think Eclipse may also just run off a USB stick without any modification.)
Dev-C++ might be a good choice if you only use Windows.
If you want an IDE that works in both Windows and Mac, you can choose Emacs, which is a very powerful text editor and is a part of the GNU project. But as it's only a text editor, you will need to download the C++ compiler yourself. MinGW might be a good choice in Windows. Since I have never used a Mac, I cannot give you more suggestion for the Mac environment. But as it's a Unix based system, I guess it has a C++ compiler itself.
What you're looking for is a portable c++ ide. Google gave me the following:
devcpp-portable
Netbeans portable config
But go through google to find more
There is portable code blocks.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 14 years ago.
Improve this question
Is there anyway to build a solution to target 64 bit environment in vs2003? My solution is native c++ not visual c++. Any help would be greatly appreciated.
cheers,
RWendi
This page on 2003's lack of 64-bit targeting seems to address your issue: http://www.toymaker.info/Games/html/64_bit.html.
The first step was to set up my development environment for 64 bit development. I use Visual Studio 2003 which has little built in support for 64 bit development.
In order to create 64 bit applications you need to install the latest Platform SDK from Microsoft (Microsoft Platform SDK for Windows Server 2003). The SDK, as well as having libraries for 32 bit programming, has 64 bit versions for AMD64 and IA64 (Intel) development.
Getting the correct library and header file paths set up in Visual Studio proved surprisingly difficult. I wanted the choice of developing 32 bit or 64 bit projects. While the platform SDK comes with command files to set up the correct paths they wipe out any other paths. Since T2 uses DirectX I also needed the DirectX paths setting correctly.
Upgrading to a newer edition of Visual Studio looks like the safer, non-hackish solution, if possible.
As Warren points out, this isn't easy with VS2003. You need to install the x64 compiler from the platform SDK.
We ran this way for a couple of years (starting with even earlier versions and the IA64 compiler). There were separate project configurations for X64 builds, so in addition to the normal DEBUG and RELEASE configurations we had DEBUG_X64 and RELEASE_X64.
But you have to launch VS studio with the paths set up for either the x86 or x64 compilers & libraries. You couldn't switch between them on the fly. I believe there was a command line switch /useenv that told VS to set its various paths from environment variables. We had bat files to set this all up.
It is messy, and every now and then we'd build the wrong project configuration for the environment which always took a while to sort out. You are much better off upgrading to VS2005/VS2008 where the target architecture is exposed directly in the GUI.
Sounds like a viable solution... going to try it before accepting the answer. votes up!
RWendi