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

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.

Related

Visual Studio for Mac 2019 .NET Assemblies missing

I've been writing a .NET Standard 2.1 class library project in Visual Studio for Mac 2019. However, when I was trying to add an attribute to a class, I was expecting I would be able to use quick-fix to add the reference for me. So when I was trying to do just that, it does not have the option of referencing the correct using statement. So I tried to add the assembly myself but then when I tried adding a new reference, I could only see the projects in the solution, but no .NET Assemblies. See the screenshot below.
By the way, I am running:
OSX Catalina version 10.15.3
Visual Studio for Mac 2019 Community Edition version 8.5.4 (Build 12)
.NET Standard projects do not show assemblies in the .NET Assembly tab in the References dialog.
.NET Standard projects use NuGet packages and framework targeting packs instead of the GAC so there is nothing to list in that tab.

What provids C/C++ runtime libraries?

I have following 2 questions wrt to Windows SDK and Platform toolsets and C/C++ runtime library.
a) What is the relation of Windows SDK with C/C++ runtime and platform toolset?
Is it correct to say that BOTH C++ runtime libraries & platform toolsets are provided by Windows SDK?
Since we mostly deal with Platform toolsets from within the Visual Studio project settings, so want to understand that whether under the hood does the Visual Studio controls the C++ runtime library and platform toolset versions by installing the required version of Windows SDK?
b) Another thing i wanted to clarify was that if it is correct to say one version of platform toolset can work with different version of Windows SDK OR these are totally unrelated?
eg. in my Visual Studio i see that 'Windows SDK version' is Windows 10 and Platform toolset is v142. Can i set the 'Windows SDK version' to Windows 8.1 and keep the toolset as v142? If yes, then what does it mean?
This is confusing me a lot and i can't seem to get the correct picture with so many different explanations from different people.
TL;DR: If you are using Visual C++, and use the standard REDIST instructions from Microsoft Docs, then these details shouldn't really matter to you.
With VS 2015 and later, the "C/C++ Runtime" has been refactored into three pieces:
UCRTBASE.DLL is part of the OS and serviced through Windows Update. There are 'down-level' versions of it included in the Visual C++ REDIST package, but generally you should think of this as the "OS" part. This is the "C Runtime". These headers, import libraries, and are in the Windows 10 SDK. You can find the source for it there as well C:\Program Files (x86)\Windows Kits\10\Source\<version>\ucrt.
MSVCP*.DLL This is the "C++ Runtime" library, basically stuff like std::vector et al. The headers, import libraries, and such are in the Visual C++ product. You can find the source to it on GitHub per this blog post.
VCRUNTIME*.DLL has the entry-points needed at runtime for the Visual C++ compiler language features.
There are also a few auxiliary libraries as well for specific scenarios:
VCCORLIB*.DLL is used for C++/CX extensions (a.k.a. /ZW)
VCAMP140.DLL is used for C++ AMP
VCOMP140.DLL is used for OpenMP
CONCRT*.DLL is used to implement C++11 <thread> on Windows XP (not used on newer versions of Windows; it's delay loaded if required)
See this blog post and this one.
Essentially the C runtime (the UCRTBASE) part is a simple extern "C" interface so the ABI is well-defined, and thus is usable with multiple versions of Visual C++ and even other compilers. Exactly which version of the UCRT you are using is therefore primarily depending on the OS and the Windows 10 SDK you are using via WindowsTargetPlatformVersion. You can applocal deploy UCRT as well per this blog.
The C++ Runtime (MSVCP*.DLL) includes a lot of inlines and exposed memory layouts, and historically there was a breaking change between between Visual C++ versions. That said, for VS 2015 Update 3, VS 2017, and VS 2019 the VC team has made a point of keeping 'binary compatibly' here meaning that if you have a static library that uses C++ std namespace components from a PlatformToolset of v140/v141, it will successfully link with a later version of Visual C++ up through v142. It's not clear that this will hold in the future, but it is true for this particular set of releases per Microsoft Docs.
The VCRUNTIME*.DLL needs to match the version of the Visual C++ compiler you are using to build the final link, so this is very much intended to match your PlatformToolset.

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.

Is Visual C++ a programming language or an IDE?

I've created and finished a project using Visual Studio 2013 and C++ programming language. However this was the first time that I use Visual Studio. (I've created this project by New-> Visual C++ -> General-> Empty project) Before I had always programmed in Linux/Ubuntu.
Now, I need to make a GUI to this project and I decided to use plotLab.(http://www.mitov.com/products/plotlab#overview)
While I was searching in this website to find the libraries that I need to download, I saw the following :
Our component libraries come in 3 versions a VCL
Firemonkey version (for Delphi / C++ Builder / RAD Studio XE3 to XE6)
MFC compatible Visual C++ version,
.NET 2.0-4.5 version (compatible with Visual Studio 2005 to 2013).
I'm confused a bit, because it is written Visual C++ version, and a .NET 2.0-4.5 version (compatible with Visual Studio 2005 to 2013). seperately. What should I do since I've never used .NET.
To other words, I'd like to use this PlotLab in my current C++ project which I've explained above but I'm not sure should I download libraries for Visual C++ or .NET 2.0-4.5 version?
.NET version applies to the .NET languages including Visual Basic, C#, J# and C++/CLI. that the library supports. In short the text means you can either use .NET language of the versions listed or or C++ with one of the specified versions. The two things are separate. As for the question title - Visual Studio is an IDE, but it comes with a collection of compilers for different languages including C++ and all the .NET languages.

Downgrade .NET framework 4.5 to 4 in Visual Studio 2012 for C++ CLR supported DLL project?

I get this error when linking a Visual C# .NET framework 4.0 supported project as I added a reference of C++ CLR DLL with 4.5 .NET Framework.
error CS0246: The type or namespace name 'project' could not be found (are you missing a using directive or an assembly reference?)
As a result, how do I downgrade .NET framework 4.5 to 4.0 in Visual Studio 2012 for this C++ CLR supported DLL project?
I have seen this before which was the cause. For my C++, this link may help out my cause http://msdn.microsoft.com/en-us/library/bb772098(v=vs.90).aspx
I just discovered this warning as well:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5): warning MSB3274: The primary reference "X" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".
Anyone seen this before? So how I downgrade the C++ DLL?
Thanks
The C++ IDE doesn't support multi-targeting for .NET projects. You'll need to edit the .vcxproj by hand. Close the project if you have it open and open the .vcxproj in a text editor. Locate this line:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
and modify it to "v4.0". Open the project again in VS. Project + Properties, Common Properties, Framework and References. Select "System" in the list and check the Relative Path property. It should now point to the 4.0 version.
Do beware of a significant issue and the core reason that the C++ IDE does not support multi-targeting. There is a problem with the #using directive, it loads assemblies from the c:\windows\microsoft.net subdirectory. Which will get it to load a .NET 4.5 assembly instead of the 4.0 assembly that you want when you target 4.0. The 4.0 reference assemblies are stored in c:\program files\reference assemblies. This can cause very hard to diagnose runtime problems, the 4.5 assemblies are not that compatible with the 4.0 assemblies. It is easy enough to avoid #using in your own code but it used in the include/msclr/marshal.h and include/vcclr.h header files. Caveat emptor if you use these headers.
I have figured it out. It was the warning but the link specified did fix the problem.
http://msdn.microsoft.com/en-us/library/bb772098(v=vs.90).aspx
what worked for me was: in the project properties -> configuration properties -> project defaults. .NET Target framework version - edit to the version you need - in my case 4.6.1