How to properly include ATL into Embarcadero project - c++

I've been given a legacy Visual C++ project that I need to compile in Embarcadero RAD Studio XE7, but I have a problem with building it. For now, I have a problem with ATL libraries, which are needed for some components of the project:
I already copied all ATL files from include/atl to windows/sdk/atl
the project requires atlsafe.h. I've installed Visual Studio 2013, which has these headers, but I do understand how to use them properly. In case I copy atlsafe.h to windows/sdk/atl, I start to receive lots of errors which are related to the outdated atlbase.h. Once I replace atlbase.h, I start to receive more errors (expectedly), and so on.
Generally, the question is, how do I properly configure my C++Builder project for ATL, and where do I obtain the correct version of the headers? For example, for the boost headers, the problem was solved very easy (build proper version and add path to headers to -I directive).

Embarcadero dropped support for ATL in C++Builder XE, replacing ATL with the Delphi ActiveX framework (DAX). In order to use ATL in C++Builder projects in XE and later, you need to obtain ATL support files (headers and library binaries) from an earlier C++Builder version, you can't use the ones from Visual Studio. If you don't have access to an older C++Builder version, then you will have to forget about ATL and migrate the project to DAX instead.

Related

convert Windows Forms Application in C++ to executable file

I am using VS10 C++ and try to convert Windows Forms Application project to executable file: this what I did
select project-> properties -> configuration properties -> C/C++
-> Code Generation -> Runtime library
then I select Multi-threaded Debug(/MTd)
when I built my project I got the following error
A Windows Forms application depends on classes from the .NET Framework Base Class Library. To develop a Windows desktop application in C++ that does NOT depend on .NET, you should use the project template for a Microsoft Foundation Classes (MFC) Application instead. This type of project will compile as a native .exe, instead of a .NET assembly. (By the way, not sure why you would still be using Visual Studio 2010 for C++ development, when the free VS 2015 Community Edition fully supports C++11 and many features of C++14. I do not yet recommend VS 2017 however, since it is still very buggy for C++ development.)
EDIT: In Visual Studio 2017, there is another option (which was not available in VS 2015). If you choose the Windows Desktop Application project template, you will get a project that depends on neither .NET (aka CLR support) nor MFC. I have never tried this approach, but on the surface, it looks very similar to MFC. Again, so far I have found VS 2017 for C++ to be very buggy, so you might have a better experience using MFC in VS 2015 instead.

Failing to migrate a .NET C++ class library from VS 2008 to VS 2012

I have a C++ project that builds a .NET class library that targets the framework 3.5.
This project has been working seamlessly since ages and the classes can be used from, among others, C# applications. It was developed with Visual Studio 2008 Professional.
Now I need to migrate if to Visual Studio 2012 Professional. I have successfully converted the project.
I meet a first problem, which is that the target framework cannot be changed from the project Common Properties, the field is read-only.
I can work around this by editing the .vcxproj file to insert a TargetedFramework tag. The new version does appear in the Common Properties.
I am also able to add references to the .NET assemblies that the library needs (just System, System.Drawing and System.Windows.Forms). The class library compiles correctly to a Dll and I can see its content in the Object Browser.
Now if I try to use it in an application targeting a framework version below 4, I get the message
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.Targets(1605,5): warning MSB3258: The primary reference "MyClasses" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.
I can't see where an indirect reference could come from (my explicit references are to v2.0.50727, which seem to be the file version for 2.0/3.0/3.5).
Do you have any explanation ?
(Expanding on Hans's correct comments)
Visual Studio supports .NET multi-targeting for the C++/CLI language by launching older versions of the C++ compiler.
As a result, the language features are inextricably linked to the .NET framework dependency -- with the newer compilers (Visual C++ 2010 and later), you get C++11 and C++14 features and .NET 4, with the older compilers (Visual C++ 2008 and before) you get .NET 2, but very little C++11 support.
To control this, there's a Platform Toolset selection in the Project Properties, but some manual project file editing is also required.
The Visual C++ Team wrote a blog post about C++ Managed Multi-Targeting in Visual Studio 2010... for later versions, read the documentation on MSDN.

Is it possible to create WinRT project with cmake?

To create WINRT project we need to have CMake >= 2.8.10 and:
Set project type to be Windows Store App(CMAKE: SET_TARGET_PROPERTIES(target PROPERTIES VS_WINRT_EXTENSIONS TRUE)
Add compiler flag /ZW for WinRT compilation(CMAKE: ADD_DEFINITIONS(-ZW))
Add App.xaml.h, App.xaml.cpp
Add App.xaml so VS will generate some additional files from it(CMAKE: HOW?)
Add Package.appxmanifest with description so VS will use it(CMAKE: HOW?)
Thank you.
UPDATE: CMake bug report referring to this question is here 0013749: Cannot target Windows 8 RT from CMake without workarounds.
CMake guys are working on it:
Bug report at cmake.org
This is perfectly doable. Things have considerably changed since this question was initially asked. The most significant changes are:
Visual Studio natively supports CMake since Visual Studio 2017 (see CMake support in Visual Studio). It's not longer required to separately download CMake, and have it generate .sln and .vcxproj files. CMake is part of the Visual Studio installation, and can be parsed by Visual Studio's project management infrastructure and build system.
C++/CX is no longer the only way to produce and consume Windows Runtime components. C++/WinRT provides a standard C++ language projection of the Windows Runtime API surface, with the ability to consume and produce Windows Runtime components.
With these changes you can use CMake to create a C++ project that builds a Windows Runtime application. C++/WinRT is standard C++, and Visual Studio 2017 provides built-in CMake support.

How can I build VS 2010's C Runtime Library?

I need to modify the C runtime which ships with VS2010 because the 2010 CRT relies on functions released in Windows XP SP2, and I need to be able to deploy to Windows 2000.
Specifically, I need to remove any and all calls to EncodePointer and DecodePointer.
The source for the C runtime is included in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src, so it seems like it should be possible to build the runtime after slightly modifying the source.
Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only. (I cannot rely on the user installing the CRT on their system either).
With VS2008 and earlier, there was a tutorial in MSDN describing how to build the CRT, but I can't seem to find it for 2010.
Is such a thing possible?
Here's an MSDN link. It looks like you have to do it yourself in VS2010.
You can use the following compiler and linker options to rebuild the MFC, CRT, and ATL libraries. Starting in Visual C++ 2010, scripts for rebuilding these libraries are no longer shipped.
If it is a option, I would consider using the VC++ 2008 toolset within VS2010 instead of building a custom CRT. The procedure is explained here.
"Oh, I don't need to be able to build the dynamic versions of the runtime -- static versions only."
Since you only need static linking, you can try this trick to provide implementations of EncodePointer and DecodePointer.

Visual Studio 2008 Express MFC Support

As may be known by many, the Express versions of Visual Studio 2008 don't include support for MFC and a few other packages required to compile a lot of windows programs.
So, here's my problem:
I have the full version of Visual Studio 2005. I've been using this to compile a project that a friend of mine was working on, so that I could test it out for him and continue to track bugs and things. Recently, he upgraded that project to VS 2008, which I don't have. So, I downloaded the express version in the hopes that I could simply compile with that, but no luck, it complains about headers missing left and right.
It seems to me that since I already have the full version of VS 2005, I'm bound to have at least some (perhaps older) version of the files in question that his project needs to compile against.
Is there a way I can convince VS 2008 to also look in 2005's directories for include files and library files to compile against?
Furthermore, is this a bad idea? I would really prefer not to go out and purchase VS 2008 full, as I'll never use it myself. (2005 does the job fine for me at the moment, and I tend to prefer GCC anyway.)
Thanks
You can use the VC++ compiler directly from the command line, or just create a new project w/ the source in Visual Studio 2005. Unless he is using some functionality provided in the new versions of MFC/ATL in 2008/2008sp1, you should be able to compile the project just fine.
See ("Create Project from Existing Source") in Visual Studio 2005. It is unfortunate that they don't include these libraries with the Express Editions.
Use the vcvars*.bat script(s) from Visual Studio 2005. See this blogpost from VC++ Blog to see how. You will use the old compilers, but the build system from Visual Studio 2008.
You can go into Tools>Options>Projects and Solutions>VC++ Directories
and alter the Include, Library, and Source (and Reference maybe?) folders to use VC++ 2005's folders.
I'd guess you just replace $(VCInstallDir) with a hardcoded VS 2005 path. I'd record the original values before doing this.
However, have you just tried using the OLD 2005 sln and vcproj files? Keep using 2005 on your end and 2008 on his. Keep two sets of these files for each IDE. Any issues are going to be with the library mismatch - which you're not avoiding by using 2008's tools with 2005's libraries.
The simple way to deal with this would be to revert the solution and project files back to their visual studio 2005 state from source control(you are using source control right?). At this point you can compile the project as long as your friend does not use any of the mfc 9 only functions.
The first thing I would try is loading this up in VS 2005 by just modifying the version of the .sln and the .vcproj files. In the .vcproj change the version from 9.00 to 8.00 and in the .sln change the format version from 10.00 to 9.00.
If you don't have fancy stuff in the project you have a high chance of just being able to use it like this. Also this would avoid having to update 2 project and solution files.
On this website it is shown how MFC code can be compiled with the Visual Studio Express versions:
link
Just for the record, I've done that(by modifying the include directories and library directories from inside the IDE) and it's working pretty well, I have MFC, ATL, everything.
I've found this explanation. http://www.codeproject.com/Articles/30439/How-to-compile-MFC-code-in-Visual-C-Express