- Home /
- Visual Studio /
This site uses cookies for analytics, personalized content and ads. By continuing to browse this site, you agree to this use. Learn more
Get help from our community supported forum
Report an issue
in Visual Studio Installer or Visual Studio
This allows diagnostic information about the program to be included in your report
1. Installer or Visual Studio
2. Report a Problem
3. Type and Submit
Available on Visual Studio 2017, Installer, and newer releases
Would you like to know more?
When VS 2017 RC is installed, resources.dll is generated from .resx file using mscorlib 4.0 even when project targets .NET 2.0
- Install .NET Framework 2.0/3.0/3.5 - Install VS 2015 - Create a Class Library named ClassLibrary1 that targets .NET Framework 2.0 - Add a Resource1.es-Es.resx file to the project - Build the project - File ClassLibrary1.resources.dll is created in folder Debug\es-ES\ - Open that file with some disassembler (such as ildasm.exe or .NET Reflector) and check that the assembly references mscorlib 2.0.50727, which is correct. - Install VS 2017 RC on the same computer - Create a new Class Library with VS 2015 and repeat the steps. The generated ClassLibrary1.resources.dll now references mscorlib 4.0, which is incorrect because the project targets .NET 2.0. The same happens if you create the Class Library with VS 2017 RC.
Edit (Dec 6):
The problem seems to be that the Assembly Linker (AL) uses the one of .NET 4.6, despite the project targeting .NET 2.0:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\AL.exe /culture:es-ES ...
It happens that AL.exe is called with the $(TargetFrameworkSDKToolsDirectory) variable, that when targeting CLR 2.0 should map to $(SDK35ToolsPath) (see file Microsoft.NetFramework.CurrentVersion.props):
<TargetFrameworkSDKToolsDirectory Condition="'$(TargetingClr2Framework)' == 'true'">$(SDK35ToolsPath)</TargetFrameworkSDKToolsDirectory>
<!-- If the sdk path is not 3.5 or lower set it to the 40 sdk tools path. This will allow future target framework versions to use the 4.0 sdk tool set When a new windows SDK revs they will inplace update the location pointed to by this property. When a new sdk is release this target will have to be revised along with another toolsversion. -->
<TargetFrameworkSDKToolsDirectory Condition=" '$(TargetFrameworkSDKToolsDirectory)' == '' ">$(SDK40ToolsPath)</TargetFrameworkSDKToolsDirectory>
If $(SDK35ToolsPath) is empty then $(TargetFrameworkSDKToolsDirectory) maps to $(SDK40ToolsPath). Hence the problem.
On a system with VS 2010 (which installs WinSDK 7.0A) and VS 2015, the following registry entry is:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx35Tools-x86
Name: InstallationFolder
Value: c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\ (notice that SDK v8.0A points to v7.0A for NetFx 35)
However, once VS 2017 RC is installed, value becomes blank:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx35Tools-x86
Name: InstallationFolder
Value: <blank>
Best Solution
Just curious, to what extent have you reviewed the situation. I never explicitly installed those tools and they're still showing as not installed on the "Individual components" tab. The problem is no longer present regardless. I'll be doing a clean install of VS2017 in a VM at some point with no other versions of VS or any SDKs present, to see what happens (unless you're able to confirm you've already done that). It may be the problem is still present after all. Based on the combination of all our experiences (yours, Ray Koopa's and my own), I now suspect VS2017 was corrected to pick up the right version of "al.exe" even if the ".NET Framework 3.5 development tools" aren't selected (from the "Individual components" tab), but only if it was already installed from some other version of VS or SDK. Otherwise the problem may still be there (I strongly suspect it is).
I had the issue that it could not build a project with resource files in it, it said al.exe was missing, and I couldn't find it anywhere.
Ok, thanks for the update. When I originally encountered this problem, I had the correct version of "al.exe" installed (3.X or earlier) from other versions of VS and/or the SDKs (the latter being independently installed), but the problem occurred anyway. The problem disappeared in VS 2017 RC build 26206. Since you still had the problem however in the RTM version, but now you don't (after installing the 3.5 tools), it seems to confirm my last comment. Microsoft did made some type of correction, but potentially not enough. I just need to test it. Will post back here when I do (may be several days however).
My previous dev machine had lots of VS versions and WinSDKs, so some dependency problems didn't arise. I had to format yesterday the hard drive of my Windows 10. I have installed only VS 2017 with no other VS versions or SDKs, and some problems have arisen, one of them this. The current situation with VS 2017 RTM is as follows:
1. Installing ".NET Framework 3.5 development tools" in the "Individual components" tab does solve the problem. I have verified installing and uninstalling it three times, so I am 100% sure
2. This is still important:
If you:
a) don't install the Individual component ".NET Framework 3.5 development tools" in the "Individual components" tab
and
b) don't have other WinSDK that provides the .NET 3.5 tools (such as WinSDK 7.0) and fill the value "InstallationFolder" of
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx35Tools-x86
to point to
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\
then:
VS 2017 still uses silently the .NET 4.0 tools (Microsoft hasn't fixed this to alert the developer)
Note: option b) was my workaround during VS 2017 RCs. Today I have switched to option a), which saves me the task of keeping the setup of WinSDK 7.0 and modify the registry by hand.
To avoid the silent failure of point #2, it is wise to add this to the MSBuild, because if SDK35ToolsPath is blank then SDK40ToolsPath is used silently
<Error Condition="$(SDK35ToolsPath)==''" Text="SDK35ToolsPath not set. Maybe HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx35Tools-x86@InstallationFolder is blank." />
Ok, thanks very much. It confirms what I thought, and saves me the trouble of verifying it (appreciated). I'll be making the necessary repairs to deal with the situation. You've been very helpful (!). Thanks again.
Just an FYI that the Windows 7 SDK won't install on Windows 10 due to a bug (or it's simply not compatible). See here for further info including several of my ("Hexadigm Systems") own exasperated comments (from more than a year ago): https://social.msdn.microsoft.com/Forums/sqlserver/en-US/1de7c9b4-1feb-4c98-b426-f7f02cbafa99/windows-sdk-71-on-windows-10?forum=windowssdk
FWIW, I managed to extract the WinSDK_nfxtoolsm_amd64.msi and cab1.cab files (for the .NET 3.5 tools) from the WinSDK 7.0 Web Installer (winsdk_web.exe) once downloaded, and the .msi installs fine on Windows 10 (C:\Program Files\Microsoft SDKs\Windows\v7.0\bin). I can't comment on the C++ compilers because I only use the recent version.
Well that's one way (thanks), but in my case it's my customers who require the tools ("al.exe" only actually), so I likely can't extract the 3.5 tools (really just "al.exe" only) and ship it with my app without violating the SDK's license agreement (or even ship a utility with my app to extract the 3.5 tools from the SDK on site). I haven't actually checked this in the license but it's probably the case (or I'd need a lawyer to verify the situation anyway). I may contact MSFT and ask for permission to ship "al.exe" with my app.
I can reproduce this, having the same issues with an old project, and it's still not fixed in VS2017 RTM. Way to go...
Others have also reported this problem (including myself) but my testing shows the problem was fixed in (at least) VS 2017 RC build 26206 (and remains that way in the RTM version according to my own informal testing). MSFT hasn't officially confirmed it (I wish they would) but they did take my word for it and changed the status of my own reporting of the problem from "Closed - Won't Fix" to "Closed - Fixed" (and the problem originally manifested itself in earlier versions of VS as well, but only after installing VS2017 - this is also now fixed in my testing). See https://developercommunity.visualstudio.com/content/problem/5761/satellite-assembly-references-40-of-mscorlib-inste.html?childToView=21795
81 People are following this
