As suggested in this post, If I install the VC++ redistributables for VS2015 update 3 am I likely to break other software running on the same PC built with previous updates to VS2015? Similarly, if I stick with update 2 for my release, is this going to get broken at some point in the future when someone installs the redists for update 3?
Based on the bug description as reported at New VC Runtime 14.0.24210.0 breaks MFC app built with VS 2015 Update 2 the U3 redistributables will indeed break MFC apps compiled with U2 or earlier, which:
use MFC in a DLL i.e. not statically linked, and
create objects of type CMFCToolBarButton or derived.
From the linked page:
The problem is caused by the new BOOL member m_bIsDragged in class CMFCToolBarButton.
So memory layout differs between Update 2 and 3.
When initializing m_bIsDragged in the constructor, the (stack) memory behind the ToolBarButton is overwritten.
The problem should arise also on all classes which are derived from CMFCToolBarButton:
CMFCColorMenuButton
CMFCCustomizeMenuButton
CMFCDropDownToolbarButton
CMFCOutlookBarPaneButton
CMFCRibbonGalleryMenuButton
CMFCToolBarComboBoxButton
CMFCToolBarDateTimeCtrl
CMFCToolBarEditBoxButton
CMFCToolBarFontComboBox
CMFCToolBarFontSizeComboBox
CMFCToolBarMenuButton
CMFCToolBarMenuButtonsButton
CMFCToolBarSpinEditBoxButton
CMFCToolBarSystemMenuButton
[ EDIT ] For completeness, it should be pointed out that apps that use AppLocal deployment of the MFC/CRT DLLs are not affected, since they do not use the system-wide installed copies thereof.
AppLocal deployment is described under bullet #6 "updated September 11 2015" in "Distributing Software that uses the Universal CRT" at Introducing the Universal CRT.
Related
I have been using a graphics library from Smaller Animals Software called ImgSource. Unfortunately, Smaller Animals Software has closed and is no longer available to answer questions. Recently, I had a system failure that deleted my only up-to-date copy of the library (I thought I had a backup but was wrong). I did, however, have the source code. I recompiled the library, both release and debug. (Both are static .lib files) I am also using MSVS 2019 Community edition and the project is an MFC project. The problem, and why I'm posting here, is that when I link the new release library with a previous project, the project compiles properly. However, when I build the debug version, it will compile, but not link and produces the linker error discussed LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in file.obj
A reasonable conclusion is that there is something wrong with the debug library. However, if I build a new project and link the debug library, everything works fine. So, the error does not appear to be in the library. It seems I could start from scratch and completely redo these projects, but they do reflect a tremendous amount of work.
I can't figure out how to modify the settings in the existing projects so that they will compile in debug mode. I have tried the suggestions offered in the article referenced above. Further suggestions would be greatly appreciated.
I have a project that I'm trying to get updated to the universal CRT, and I'm still seeing a dependency on vcruntime140.dll and msvcp140.dll, which I think should have been replaced with a ucrtbase.dll, as well as api-ms-win-crt* dlls.
I've already checked out this response here, and this blog post, which explain things pretty well, but still no luck. Here's what I've changed:
Platform Toolset: Visual Studio 2019 (v142)
Windows SDK version: 10.0 (latest installed version)
Additional include directories: added $(UniversalCRT_IncludePath)
Additional library directories: added $(UniversalCRT_LibraryPath_x86)
I also updated my linker dependencies to this set:
ucrt.lib
vcruntime.lib
msvcrt.lib
user32.lib
advapi32.lib
Wsock32.lib
Crypt32.lib
ws2_32.lib
But when I run dumpbin /dependents mydll.dll
File Type: DLL
Image has the following dependencies:
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
VCRUNTIME140.dll
USER32.dll
ADVAPI32.dll
WSOCK32.dll
CRYPT32.dll
WS2_32.dll
MSVCP140.dll
bcrypt.dll
KERNEL32.dll
Summary
E000 .data
66000 .rdata
E000 .reloc
1000 .rsrc
14A000 .text
Is there something else I'm missing to be able to drop the dependency on the specific CRT version?
I've done some more digging, and found this page that says the following:
Starting in Visual Studio 2015, the CRT has been refactored into new
binaries. The Universal CRT (UCRT) contains the functions and globals
exported by the standard C99 CRT library. The UCRT is now a Windows
component, and ships as part of Windows 10.
Great, that's what I expected. Just below though is this:
The vcruntime library contains Visual C++ CRT implementation-specific
code, such as exception handling and debugging support, runtime checks
and type information, implementation details and certain extended
library functions. This library is specific to the version of the
compiler used.
Which implies that there is still a non-universal VC++ dependency that gets linked in by VS. To me, this implies that a dependency-free DLL doesn't really exist (at least not something built with VC++), since you'll always have a vcruntime dependency.
There is always the option of static linking (/MT), but in my case, I'm also looking at a DLL that has /clr, and the two options are mutually exclusive. Application local deployment (just copy vcruntime140.dll with the binaries) also seems to work, and may be the best option for something that I want to be a portable/xcopy deployment.
I'm going to mark this as an answer for now, but if there's a way around this, I'd be interested in seeing it.
I've inherited a legacy .Net 3.5 VB app to support from a client and they'd like to make some small data changes. Before we begin I think it's important to note that I am running Windows 7 64 bit, and VS 2013 Ultimate R2.
While making my first changes to the project, I noticed their datasets use a custom tool AGDataSetGenerator (written by Shawn Wildermuth in 2004). I did a lot of poking around on how to register custom tools. I went over to http://www.codeproject.com/Articles/8582/Inherit-from-ADO-NET-DataSet-to-create-your-own-bu and got the source code of the tool, inside the project there are a couple of utility files that you need to run in order to register the tool. Remember this was made in 2004 so things were a little different back then.
I modified the Reg.cmd file to point to v2.0.50727 since my project is running .Net 3.5 and .Net 3.0 and 3.5 are both just minor updates from .Net 2.0 and not completely new .net versions. Also I noticed that there is both a Framework and a Framework64 folder with the C:\Windows\Microsoft.Net folder, so I added both locations to my .cmd file in hopes to cover all of my bases. Code Below
Reg.cmd - Original
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\regasm /codebase /verbose F:\AGDataSetGenerator.dll`
Reg.cmd - My Modified Version
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm /codebase /verbose F:\AGDataSetGenerator.dll
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\regasm /codebase /verbose F:\AGDataSetGenerator.dll
Then it was on to the.reg file.
Upon opening the file my first thought was, cool, I can just switch the version from 7.1 to 12.0 and away we go. Not the case. After quite a bit of googling I found the first line registers the tool for VB.Net, and the second registry entry registers the tool for C#, so for me I only need the first line, also VS now a days registers to a new location HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\ for 64 bit specific registers. So in hopes to cover my bases once again, I tried including both 32 bit and 64 bit locations. I even threw in a more global register for both 32 and 64 bit that in hopes that would point visual studio to the generator entry, unfortunately I'm a bit out of my wheelhouse here so I was pretty much grabbing at straws.
BSDataSetGenerators.reg - Original
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\AGDataSetGenerator]
#="ADOGuy DataSet Generator"
"CLSID"="{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}"
"GeneratesDesignTimeSource"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Generators\{FAE04EC1-301F-11d3-BF4B-00C04F79EFBC}\AGDataSetGenerator]
#="ADOGuy DataSet Generator"
"CLSID"="{3C13044D-394D-45cd-89FF-51C885BFBCD9}"
"GeneratesDesignTimeSource"=dword:00000001
BSDataSetGenerators.reg - My Modified Version
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\12.0\CLSID\{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}]
#="AGDataSetGenerator"
"InprocServer32"="C:\\WINDOWS\\system32\\mscoree.dll"
"Class"="BottomLine.Generators.VBNETAGDataSetGenerator"
"Assembly"="AGDataSetGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=35e4ca7ea38d2508"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\12.0\CLSID\{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}]
#="AGDataSetGenerator"
"InprocServer32"="C:\\WINDOWS\\system32\\mscoree.dll"
"Class"="BottomLine.Generators.VBNETAGDataSetGenerator"
"Assembly"="AGDataSetGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=35e4ca7ea38d2508"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\12.0\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\AGDataSetGenerator]
#="AGDataSetGenerator"
"CLSID"="{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}"
"GeneratesDesignTimeSource"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\12.0\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\AGDataSetGenerator]
#="AGDataSetGenerator"
"CLSID"="{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}"
"GeneratesDesignTimeSource"=dword:00000001
Regardless of everything I've tried. When I right-click a dataset and try to run custom tool. BAM! I get the following:
If anyone can get this working in similar settings to my own, I'd love to know how you did it.
I'm very much the type of person that find's it very hard to take NO for an answer when it comes to technology. Unfortunately the answer here is simply just "No". The custom tool is very much outdated and to get it to work in VS 2013 just isn't feasible (I still can't bring myself to say impossible).
I'm writing this answer because I have a workaround that I suggest anyone in the same situation use straight out of the gate instead of trying to get that old tool to work. As a workaround, I created a new data project in .Net 3.5 and used entity framework to bring in just the models I needed to update. I generated my models from database and then went to the .aspx code behinds and replaced references to the outdated generated datasets. It took some refactoring but using EF instead of those ancient generated datasets cut the code by about 40%. Win Win in my opinion. Hope this helps someone else in the future.
According to the old .reg reference to VS 7.1, that means it was built to work in VS 2003. I know that VS plugin coding changed a lot in VS 2010 and later editions. So, it is possible this plugin may only work in VS 2003... possibly all the way up to VS 2008. But, it may need to be re-written to work in anything later.
Hopefully you have MSDN or know someone who does. I would spin up a VM, install VS 2003 (or you could try up to VS 2008), and install this plugin using the original .reg/.cmd.
I'm setting up FREEGLUT and GLEW for Visual Studio2012 on Windows7 64bit.
First of all, should I need to set up also GLUT?
Second, I'm confused, in GLEW/lib and GLEW/bin there both Release and Release MX folder, which one should I pick files?
In regards to GLEW:
I suggest you use GLEW for now, and switch to GLEW MX (Multiple Rendering Contexts) once you need the additional functionality it provides.
According to http://glew.sourceforge.net/advanced.html
Starting with release 1.2.0, thread-safe support for multiple rendering contexts, possibly with different capabilities, is available. Since this is not required by most users, [GLEW MX] is not added to the binary releases to maintain compatibility between different versions.
Here is how you build glew:
Note: Just because you are using a 64 bit machine, doesn't mean that you have Visual Studio set up to run 64 bit applications. I suggest you use the 32 bit versions of libraries until you are ready to reap the benefits of using the 64 bit versions, as you can switch later.
1. Link your project with the static GLEW library in the lib folder. This is either glew32s.lib or GLEW depending on your platform.
Note: glew32s.lib is to link statically, glew32.lib (without the s) is to link dynamically. If you prefer to dynamically link with GLEW instead, leave out the define and link with glew32.lib instead of glew32s.lib on Windows. Don't forget to include glew32.dll or libGLEW.so with your executable!
2. Add the include folder to your include path.
3. Include the header in your program, but make sure that it is included before the OpenGL headers or the library you used to create your window.
In regards to GLUT:
Could someone else answer (or edit my answer), as I have not used GLUT yet.
Additional Sources Used For This Answer:
https://open.gl/
I have a new project where I cannot use boost::format. I get a compiler error complaining that boost's override of a virtual function, ~basic_altstringbuf, lacks a "throw()". Even the most trivial attempt to use boost::format does that.
I have other projects where it works fine. I have verified that the new project uses the same include-paths for boost, and for the VC++ includes. All the projects have "Enable C++ Exceptions" set to Yes. The only explanation I can come up with is that the projects that work have some #DEFINE or some setting that disables those vile exception specs in the std:: include-files. But I have no idea what or where it might be. Any ideas?
Error 1 error C2694: 'boost::io::basic_altstringbuf::~basic_altstringbuf(void)': overriding virtual function has less restrictive exception specification than base class virtual member function 'std::basic_streambuf<_Elem,_Traits>::~basic_streambuf(void) throw()
EDIT: Corollary question: Is there a Properties-item in VS++ 2012 that will cause the std:: header files to be included without exception-specs? - short of turning off exceptions, that is?
At the request of the original owner of the green check-mark, I am submitting this summary.
The bugs are on the Microsoft side, in header-files for C++ standard library interfaces, and in the VC++ compiler when "Disable Language Extensions" is NOT set. The header files contain exception-specifications that the standard does not call for. When "language extensions" are not enabled, the compiler accepts invalid code. I have filed a bug report.
Boost could work around the problem in this specific case by adding seven characters to a nested include-file, i.e. "throw()" at line 65 in alt_sstream_impl.hpp. I filed a report with boost also, although I made it clear that the bug is not in their code. I am just suggesting a workaround.
All the tedious details are in the two reports linked above.
Check the preprocessor defines.
You might turn on and inspect verbose logging to see the exact flags that are passed to cl.exe
You could keep the preprocessed source and compare the version from the old (working) project with the new (failing) project.
My gut says, something else is being #defined/passed using -D in the old project that is not being defined in the new project, of differently (think of WINVER type macros)
See new answer posted: VC++ 2012 and Boost incompatibility - `throw()` specifications in library headers
EDIT by OP, Jive Dadson - It turned out to be /Za, which enables/disables "Microsoft language extensions." It is the contention of Visual Studio that the C++ standard requires that a program shall not compile if it has a virtual function override that is less restrictive in the "throw()" category than the function it overrides. Boost has a class that derives from basic_streambuf, and has a virtual destructor that lacks "throw()". The original destructor has that evil festoon. My new project will compile boost::format if I turn MS language extensions ON.
So the question becomes, who is wrong, and how? Is it standard-complying to put throw() on that destructor or not? Is the desired behavior (desired by me, that is) actually an "extension"? I seem to recall that MS considered some standard C++11 features to be "extensions," but I am not sure I remember correctly. Anyway, I will leave it to the boosters to decide, if they are interested. https://svn.boost.org/trac/boost/ticket/7477