none
Was a vc runtime update dropped from vs2017u4? RRS feed

  • Question

  • vs2017u3

    The vs2017u3 drop (vsbt/vspro/vsent) we downloaded on 8/29 (using --layout and --all) has 14.11.25415.0 MFC redists:

    • Microsoft.VisualCpp.CRT.Redist.x64.OneCore.Desktop,version=14.10.25415.0
    • Microsoft.VisualCpp.CRT.Redist.x86.OneCore.Desktop,version=14.10.25415.0
    • Microsoft.VisualCpp.MFC.Redist.X64,version=14.10.25415.0
    • Microsoft.VisualCpp.MFC.Redist.X86,version=14.10.25415.0
    • Microsoft.VisualCpp.CRT.Redist.X64,version=14.11.25325
    • Microsoft.VisualCpp.CRT.Redist.X86,version=14.11.25325

    (Note: 14.10 in directory name above is correct - the layout dirs don't have 14.11 in them)

    If we unzip an MFC vsix for, say, Microsoft.VisualCpp.MFC.Redist.X64 we see 14.11.25415 content directories, and if we look at say, Contents/VC/Redists/MSVC/14.11.25415/x64/Microsoft.VC141.MFC/mfc140u.dll, we find it's version stamp is 14.11.25415.0

    The remainder of the runtime is 14.11.25325 (slightly older)

    vs2017u4

    The vs2017u4 drop (vsbt/vspro/vsent) we downloaded 11/7 and 11/27 is consistently 14.11.25325:

    • Microsoft.VisualCpp.CRT.Redist.x64.OneCore.Desktop,version=14.11.25325
    • Microsoft.VisualCpp.CRT.Redist.x86.OneCore.Desktop,version=14.11.25325
    • Microsoft.VisualCpp.MFC.Redist.X64,version=14.11.25325
    • Microsoft.VisualCpp.MFC.Redist.X86,version=14.11.25325
    • Microsoft.VisualCpp.CRT.Redist.X64,version=14.11.25325
    • Microsoft.VisualCpp.CRT.Redist.X86,version=14.11.25325

    And if we unzip the same MFC vsix here, we get 

    Contents/VC/Redists/MSVC/14.11.25325/x64/Microsoft.VC141.MFC/mfc140u.dll with version stamp is 14.11.25325.0

    ... so why does vs2017u4 (11/27) ship with an older MFC redists (25325) than vs2017u3 (8/29) MFC redists (25415)?


    • Moved by Baron Bi Thursday, December 7, 2017 7:27 AM Not about c++ development
    Tuesday, November 28, 2017 7:53 PM

All replies

  • Is it older?

    You should never really see much meaning in the later numbers if the earlier ones change. Also, Microsoft have been known to make mistakes with version numbering in the past.

    The real way to tell if the DLLs are newer is to look at the modified date of the DLL, assuming that whatever you used to extract it reads the date set in the vsix and sets the date on the files themselves. The modified date for the update 4 runtime is the 4th august 2017. If the update 3 version is newer than this then the file is newer, if it is older then the file is older.

    Although interestingly, the build date in the file header seems to be 25th may 2017 for the update 4 redistributables.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.


    • Edited by Darran Rowe Wednesday, November 29, 2017 12:33 AM
    Wednesday, November 29, 2017 12:29 AM
  • Not so fast. When the Windows Installer (the engine backing MSI) goes to install files and finds one already existing, it has to decide:

    • Does it replace the existing file with it's newer one, or
    • Does it reference count the existing file because it's is older

    For EXEs/DLLs, the version stamp is compared, not the file timestamp. Since some of these files are installed via MSM's linked into MSI's, that could apply here.

    The main caveat is embedded assembly versions. That said, a quick run of vcredist_xxx.exe showed the DLLs ending up in %windir%\system32, not windows\winsxs (i.e. the native code GAC). That suggests we're not dealing with native assemblies (I think)


    • Edited by A Oney Wednesday, November 29, 2017 12:39 AM typo
    Wednesday, November 29, 2017 12:38 AM
  • Hi A Oney,

    thanks for posting here.

    This forum is about c++ code issues. For your case which is more related to the version of MFC package, I suggest you connect to Microsoft and post this issue on it. Or click Help->Send Feedback->Report a Problem in your vs.

    Your understanding and cooperation will be grateful.

    Best Regards,
    Baron Bi


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    • Edited by Baron Bi Wednesday, November 29, 2017 2:12 AM
    Wednesday, November 29, 2017 1:22 AM
  • Microsoft stopped using the side by side assemblies for the VC redistributable in Visual Studio 2010. It seemed like people weren't getting used to them and causing more issues than they solved.

    But another thing to remember about the Windows Installer, it doesn't have to check the files to find out what version is installed. The installer itself has its own version and when a package is updated then it checks the installer information not the individual file information.

    In this kind of situation, Windows Installer can just look at the list of files that has changed, or just a list of files and blindly replace them with the ones in the installer package because it is able to assume that the files are out of date.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Edited by Darran Rowe Wednesday, November 29, 2017 12:50 PM
    Wednesday, November 29, 2017 12:49 PM
  • In this kind of situation, Windows Installer can just look at the list of files that has changed, or just a list of files and blindly replace them with the ones in the installer package because it is able to assume that the files are out of date.

    Are you claiming that, if

    1. Windows Installer installs Product A, which includes version 1.0 of File.dll in a common folder;
    2. a legacy installer upgrades File.dll to 3.0, without using Windows Installer;
    3. Windows Installer installs Product B, which includes version 2.0 of File.dll;

    then Windows Installer would assume File.dll is still version 1.0, and replace it with version 2.0, even though File.dll was actually version 3.0 on disk?

    I would expect it to be documented in Replacing Existing Files if Windows Installer worked that way. Such behavior would hurt compatibility with legacy installers, which Windows Installer apparently tries to maintain (see msidbComponentAttributesSharedDllRefCount). Besides, opening previously installed packages in order to read the version numbers from the File tables would likely be slower than checking the file itself.

    Friday, December 29, 2017 4:11 PM