Unfortunately, a set of setup & deployment issues have been reported with the Visual C++ 2008 Feature Pack. Some of these are blocking issues and, as a result, we are currently working on a refresh of the Feature Pack. In the interim, a list of the issues and their workarounds is provided below. These issues will all be addressed via the refresh.
Feature Pack failed to install on German OS or English OS with German locale.
Before installing the Feature Pack, change the Regional & Language settings as follows:
On XP: Control Panel ->Regional and Language Options->Regional Options, set “Standards and Formats” to “English(United States)”
On Vista: : Control Panel ->Regional and Language Options->Formats, set “Current Format” to “English(United States)”
Once installation completes, you can restore your Regional & Language settings.
VCRedist_x86.exe failed to install on Vista and Windows Server 2008
No current workaround. We are working on publishing a fixed VCRedist_x86.exe
VCRedist_x86.exe installs the ATL and OpenMP assemblies with the wrong processor architecture, which will cause ATL and OpenMP applications targeting x86 to fail.
Visual C++ Development Team
PingBack from http://microsoftnews.askpcdoc.com/?p=1658
I haven't had the chance to try the current version in the feature pack this week, but when you re-release vcredist_x86.exe, could you make sure that KB950683 is also resolved? (and maybe update the KB article to indicate such?)
Am I the only one who thinks the VCRedist_x86 problems indicate a serious breakdown in the QA process? I hope the STL/MFC code changes got better testing than the redist package. Creating absolutely bulletproof runtime installers should be a core competency of the Visual C++ team. You're not allowed to screw this up and still be taken seriously by the ISV community. This is the kind of crap that would drive people to the competition, if you still had any :-(.
Windows Server 20008?
The wrong processor thing is a good one, well done! Now I know why I always static link as much as I can :-)
Does this also affect the merge-modules?
Is this a problem with just VSRedist or is there a problem if you use the merge module in your own installation programs?
C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.MFC
<file name="mfc90.dll" /> <file name="mfc90u.dll" /> <file name="mfcm90.dll" /> <file name="mfcm90u.dll" />
Version not updated in manifest ?!
Wow, this is just ridiculous. How could you guys take months to release an MFC add-on that you licensed from a third party and *still* have this type of (incredibly amateurish) problem? What in the world have you folks been doing?
I'm starting to wonder if the MS VC++ library development team isn't comprised of three guys in a basement somewhere in Redmond.
Was about to make a Release. But now waiting for you guys tox fix the merge modules. Please hurry. We make a living out of this.
(the sound of your quality bar falling through the bottom of muddy pond)
The version issue in Microsoft.VC90.MFC.manifest will be addressed as well in the refresh.
No, the merge modules are not affected.
As a C++ programmer, I am serious thinking maybe I should move to c#...
Mittlerweile ist das MFC Feature Pack und somit auch die TR1 Implementierung im finalen Release im Web
We experiencing some strange error with the MFC Feature Pack under Windows XP 64bit SP1 MUI in Debug-Mode.
The same Application under Win32 causes no problems... The x64 Release-Mode is also OK!
If we trying to start our application from VS2008 Debug-Mode - following error message appears:
dtxr2.exe - Illegal System DLL Relocation
The system DLL user32.dll was relocated in memory. The application will not run properly. The relocation occurred because the DLL C:\WINDOWS\WinSxS\amd64_Microsoft.VC90.DebugMFC_1fc8b3b9a1e18e3b_9.0.30304.0_x-ww_8C1EB4FC\mfc90d.dll occupied an address range reserved for Windows system DLLs. The vendor supplying the DLL should be contacted for a new DLL.
Any ideas what can it be??? Thanks...