Building Boost with VS2015 - visual-c++

I am trying to update from VS2013->VS2015, and to do that I need to rebuild my boost library files using VS2015. I grabbed the latest boost (1.58). By default boost is trying to build with VS2013. I tried to invoke bjam with toolset=msvc-14.0 but this did not work, as it keeps saying:
'cl' is not a recognized as an internal or external command
I guess it doesn't know where VS2015 is located? Does anyone know what I need to change to get boost to build with VS2015?

BlueGo is a tool which builds Boost using Visual Studio 2010/12/13/15. You just have to start the application, select your configuration and hit the Build button- everything else works automatically. The application downloads the library, extracts it and builds it. Can be downloaded from here.
Screenshot of BlueGo:
You also need to install Common Tools for Visual C++ 2015 as described here.
Prebuild boost libraries for VS2015 can be found here. Those seem to be very carefully maintained.

Related

Building Electron Native Extensions using Visual Basic 2015

Where I am currently:
I have began working on a NodeJS native extension I intend to work with Electron, but from previous works I have noted that the build steps for building for just NodeJS are as expected, include the libraries as per instruction and change to output a .dll file with a .node extension.
The problem I am facing:
When compiling my extension, which tried and tested within NodeJS, does not work within an Electron contained instance of NodeJS - from searching around I understand this to be a problem with the header files which I am compiling against etc. The documentation for building with visual studio (not Visual Studio Code) is very sparse and everywhere generally points to using node-gyp - which is something I'm attempting to avoid and build using purely Visual Studio 2015.
For reference, when running the working (in NodeJS) NativeExtension I get the following error (which googling brought me to the conclusion I am compiling against the wrong thing):
ELECTRON_ASAR.js:167 Uncaught Error: Module did not self-register.
Could someone please shed some light on where I may be going wrong? I am a novice when it comes to C++ program structure and compiling methodologies.
The documentation for building with visual studio (not Visual Studio Code) is very sparse and everywhere generally points to using node-gyp - which is something I'm attempting to avoid and build using purely Visual Studio 2015.
There is a standard way of compiling native Node modules, and as a self admitted novice it would be unwise to deviate from it. I suggest you read through the Microsoft NodeJS guidelines and get your development environment properly configured to build via node-gyp, once that's working you can start figuring out how to rebuild native Node modules for Electron.

Project is targeting frameworks not installed or are included as part of future updates to Visual Studio

I am attempting to convert the Microsoft.Health C# class library that is installed as part of the HealthVault SDK, using instructions provided here. After following these instructions, I get the following error when attempting to load the project into Visual Studio 2013.
"The project is targeting frameworks hat are either not installed or
are included as part of future updates to Visual Studio. See
http://go.microsoft.com/fwlink/?LinkId=287985"
Visiting the link takes me to .NET SDKs and Downloads. Once there, I have no clue on what needs to be done.
I do realize that one will have to leverage the Portable Class Library Contrib project to fill in some missing bits, especially code related to System.Security. This, I will deal with later.
Any one run into a similar problem?
Maybe so late but for those who have the same problem.
I had the same error in a project which was working perfect before updating VS2013 and finally after 3 hours looking for the source of the error I found that the error is about TargetFrameworkProfile.
In my case I sloved it like so:
Right click in the unloaded project in your solution and click Edit.
Find the TargetFrameworkProfile tag and set it as below:
<TargetFrameworkProfile>Profile78</TargetFrameworkProfile>
At a guess, this is because you need to specify the TargetFrameworkVersion and TargetFrameworkProfile properties in the project file. Compare the .csproj you are trying to create to a newly created PCL project file, and make sure that everything that's not specific to your project matches.
I ran into the same issue and got it resolved by installing the latest Visual Studio Update

How to compile wxWidgets for x64 on Windows?

I have had quite the experience trying to compile wxWidgets on Windows for x64. After a nightmare setting up Visual C++ 2008 express to compile x64 apps, I opened the wx.sln file. (I'm using wxWidgets 2.9.0, by the way.) I picked the Release configuration and set x64 as the platform. When I hit build, I get a slew of errors saying that wx/setup.h is missing. It would seem like the file is not being created. The real mystery is that the above steps work perfectly for wxWidgets 2.8.10. Any idea why this does not work?
Ensure that you have the file include/wx/msw/setup.h (in particular, it wouldn't be there if you checked sources out of svn). Other than that also check that you use vc9 versions of the project files just to be sure that you don't run into some import problems. With these projects all the necessary setup.h under lib/vc_lib (or vc_dll) directory should be created automatically by custom build steps in the projects.

generate exe file

i have developed application in visual c++ 6.0,i have do exe of that application,i have done by using icnt.exe(install creator),but when i run my application exe file on other system which does't have the vc++ software it's showing dll files are missing,how could than i downloaded the dll files again it is asking other dll's files.i want run my application without installing vc++ software in windows,how can i solve it,plz help me i'm touble.
How to make Realease build? by default its debug build
thanks for reply.
As a wild guess, you have deployed the Debug build, which depends on DLLs that are not allowed to be shipped.
If that is the case, have VC6 create a Release build and deploy that.
You can verify which DLLs are required by your application with the depends.exe utility that came with Visual Studio.
Edit: The easiest way to get a release build when ready is to use the Batch Build command from the Build menu. It will let you pick among all of the known build types in the project, and choose to either build them clean (recommended) or to just bring them up to date.
It is also possible to switch the GUI to default to the Release build instead of Debug. That is the right thing to do if you actually need to run the debugger on the Release build. Note that both builds include debug symbols. The differences have more to do with which runtime libraries are linked, and certain optimizations such as making the assert() macro have no effect.

Error: The Side-by-Side configuration information in "BLAH.EXE" contains errors

This is the error Dependency Walker gives me on an executable that I am building with VC++ 2005 Express Edition. When trying to run the .exe, I get:
This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem.
(I am new to the manifest/SxS/etc. way of doing things post VC++ 2003.)
EDIT:
I am running on the same machine I am building the .exe with. In Event Viewer, I have the unhelpful:
Faulting application blah.exe, version 0.0.0.0, faulting module blah.exe,
version 0.0.0.0, fault address 0x004239b0.
Open the properties sheet for your project, go to the Configuration Properties -> C/C++ -> Code Generation page, and change the Runtime Library selection to /MT or /MTd so that your project does not use the DLL runtime libraries.
The C/C++ DLL runtimes used by VS2003 and up are not automatically distributed with the latest version of the OS and are a real pain to install and get working without this kind of problem. statically link the c-runtime and just avoid the total mess that is manifests and version specific runtime dlls.
I've had this problem. The solution has two steps:
1. Compile your program in "Release" mode instead of "Debug" mode (there's usually a combo-box in the toolbar)
2. Download from Microsoft their Redistributable Package of runtime components. Make sure to download the x86 edition for 32-bit computers and the x64 edition for 64-bit computers/OSes. Install this package on the target computer, and your application should run fine
P.S. This is a SxS thing
P.P.S. Alternatively, use a different compiler (like GCC, for example with Dev-Cpp) to compile your program's source, and your headaches will disappear.
Sorry to bump an old question, but I was able to get around this exact issue and thought I'd post a solution in case someone else needs it...
Even after installing Microsoft's redistributable DLLs I was getting this error, the fix was to copy the
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT
folder into the application's directory on the target PC. After that, no more problems.
BTW, the DLL that was giving me issues was a 3rd-party DLL that had never had problems before on over 100 other computers... go figure.
Run Event Viewer: it'll have more information.
Probably you've attempted to run your program on a machine that doesn't have the VC redistributables installed, or you're attempting to run a debug build on a machine that doesn't have Visual Studio installed (the debug libraries aren't redistributable).
I have had the same issue with VS 2008-built debug binaries on other winxp sp3 machines.
I first tried installing the client machine with vc redist package,as it seemed sensible. Annoyingly, it didn't work.
I tried copying all the dependent dlls to the application's directory - still didn't work
After being struck over this issue for hours, I found that the latest VS builds require manifests and policies to link with the dlls. After copying them into their respective "C:\WINDOWS\WinSxS\" folders, I got it working.
The problem was caused due to the fact that the vc redist package did not install debug versions of dlls, they somehow thought its up to the programmer to figure out.

Resources