none
.NET 4.6 Targeting Pack Doesn't Actually Install Reference Assemblies RRS feed

  • Question

  • When attempting to use the .NET 4.6 Targeting Pack installer (found at: https://www.microsoft.com/en-us/download/details.aspx?id=48136) I find that the installation doesn't actually install the reference assemblies. The files should show up, at least on my system, under "E:\Program Files (x86)\Reference Assemblies\Microsoft\Framework", however they don't show up at all.

    I have also found that running the installer again and selecting "Repair" causes the files to be installed to the correct folder but on the wrong drive. Specifically, it installs them to "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework".

    I'm not sure what's causing this behaviour, could somebody please help me?

    This is on windows 7 SP1.

    Wednesday, October 4, 2017 3:18 PM

All replies

  • Hi Mattew,

    Thank you for posting in MSDN forum.

    .NET is closely integrated into Windows and will always install into %SystemRoot%.

     Usually once the .NET Framework installation is finished,the default installed path of the reference and assemblies is on

    C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework

    .NET is installed on the same drive as Windows. i'm afraid that your machine Drive E: is not the system drive. If you want .NET on a non-C: drive then install Windows on another drive.

    Best Regards,



    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.


    Thursday, October 5, 2017 2:29 AM
    Moderator
  • Hello, I was under the impression that the reference assemblies should be located under the 32-bit program files directory.

    The end use case for this is that I'm trying to run `dotnet build` which in turn uses `msbuild`. I was told that msbuild searches the 32-bit program files directory for the reference assemblies, and from my own testing this seems to be the case.

    It seems like there's a disconnect here between these 2 systems. Either the reference assemblies should install to %programfiles(x86)% or msbuild should look only in the %systemroot% drive.

    What do you think?

    Thursday, October 5, 2017 10:21 AM
  • Hi Mattew,

    Thank you for your update, understanding that it is for your .Net project build testing.

    Could you please tell us if there are two systems installed on your machine (Drive C: and Drive E:)?

    Refer to Scott Hanselman on this topic. You can also find the specific versions in:
    C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework

    Best Regards,


    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.


    Friday, October 6, 2017 8:55 AM
    Moderator
  • I have just 1 operating system which is installed on the C drive. The C drive is a small-ish SSD and the E drive is a larger HDD I use for most programs. That's why I've got program files set to the E drive.

    Even if Scott Hanselman is saying that the Reference Assemblies must be installed on the C drive that doesn't explain why msbuild expects them to be installed under %programfiles(x86)%. Could you please explain the disconnect between these 2 systems?

    Thanks

    Friday, October 6, 2017 10:35 AM
  • Hi Mattew,

    This Program Files folder(x86). is the recommended location where programs you install should store their executable, data, and other files. In other words, programs install to the Program Files folder.

    Windows automatically installs programs to the correct folder, so you don’t have to think about it. Programs appear in the Start menu and function normally, no matter where they’re installed.  Just let your programs automatically decide which Program Files folder to use.

    Best Regards,


    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.

    Monday, October 9, 2017 9:22 AM
    Moderator
  • I'm sorry if my previous point wasn't clear. I understand what program files is, the problem is either that:

    1. The targeting pack installer doesn't install to the correct program files directory.
    2. Or msbuild is looking in the wrong directory.

    Or I've misunderstood something in which case could you help me understand whatever that is?

    Thanks

    Monday, October 9, 2017 10:28 AM
  • Hi Mattew,

    Net Framework 4.6 is a highly compatible, in-place update to the Microsoft .NET Framework 4, Microsoft .NET Framework 4.5, Microsoft .NET Framework 4.5.1 and Microsoft .NET Framework 4.5.2.

    If you have those previous version before, when installing 4.6, it will cover the original directory.

    For MSBuild looking the wrong directory, does there any error pop up when you test your application?

    Best Regards,


    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.

    Tuesday, October 10, 2017 7:44 AM
    Moderator
  • I'm not trying to install .NET Framework 4.6, I'm trying to install the Targeting Pack for .NET Framework 4.6. I understand that when installing .NET Framework 4.6 it's an in place upgrade.

    Are you saying that when installing the targeting pack it looks for previous targeting pack installations for .NET Framework versions 4.5 to 4.5.2 and overwrites them?

    The error I get from msbuild is:

    E:\Program Files\dotnet\sdk\2.0.0\Microsoft.Common.CurrentVersion.targets(1122,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.6" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. [E:\Work\TestSolution\TestProject\TestProject.csproj]

    I've asked the dotnet people about this previously and they found that the issue was that the targeting pack was installing to the wrong drive.

    Thanks

    Tuesday, October 10, 2017 11:11 AM
  • Hi Mattew,

    Thank you for the detailed explanation.

    We are still investigating this issue, there could be some delay time for finding the real cause.

    If you change the target path to drive C:, does the error pop up again?

    Best Regards, 


    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.

    • Proposed as answer by sreenimenon Saturday, March 3, 2018 4:36 AM
    Wednesday, October 11, 2017 9:27 AM
    Moderator
  • What do you mean by "target path"? I can change msbuild's FrameworkPathOverride property to look in the correct directory for the reference assemblies and that works, however this isn't a proper solution. I've tried building projects from the C and E drive and I get the same error.

    Thanks

    Wednesday, October 11, 2017 11:50 AM
  • Hi Matthew,

    Currently I think I'm not able to help you answer this, but I have invited other Microsoft senior engineer to solve it.

    Thank you for your understanding.

    Best Regards,


    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.

    Thursday, October 12, 2017 9:01 AM
    Moderator
  • Hi Matthew Padbury,

    Do you know which assembly was not installed in your side? Do you get any error or warning in your side? How did you build your app?

    As far as I know, the old MSBuild was included in .NET Framework, but in new VS version, it has been changed:

    https://stackoverflow.com/questions/32070490/how-to-build-net-4-6-framework-app-without-visual-studio-installed

    This case showed the steps about how we could use the higher MSBuild version to build the app using .NET 4.6.

    As you said that you use the MSBuild, whether it was related to the version or others?

    Best Regards,

    Jack


    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.

    Friday, October 13, 2017 8:41 AM
    Moderator
  • Hi,

    After running the installer the first time nothing new shows up in either "Reference Assemblies" directory. It's only after running it a second time, to do a repair install, that the assemblies show up but they show up on the wrong drive.

    I get no errors when running the installer.

    I build my solution with the dotnet command. In turn this uses msbuild. For reference, "dotnet --version" gives 2.0.0 and "dotnet msbuild -version" gives 15.3.409.57025.

    I can get the build to work if I specify msbuild's FrameworkPathOverride property as such:

    dotnet msbuild -p:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6"

    But this isn't an ideal solution. Ideally either msbuild would look in the correct directory or the installer would install the the correct directory. Or it's entirely possible I'm missing something.

    Thanks

    Friday, October 13, 2017 10:53 AM
  • Hi Matthew Padbury,

    >>After running the installer the first time nothing new shows up in either "Reference Assemblies" directory. It's only after running it a second time, to do a repair install, that the assemblies show up but they show up on the wrong drive.

    So you could find all reference assemblies now, it has been resolved even if it was in different drive, am I right?

    Based on your previous reply, your VS was installed in E drive, but if you install the .NET 4.6 Targeting Pack singly, it would install it in C drive, am I right?

    Not found that whether we could change the path for this setup file, but it really has no settings to change the setup path in the wizard during I install the .NET 4.6 Targeting Pack in my side. Since the VS was installed in other path which was different from the .NET 4.6 Targeting Pack , I think that's the reason why it could find the assembly directly.

    I will discuss with MSbuild members and others, if I get any update, I will also share it here. But I think we have found the real issue/reason.

    Best Regards,

    Jack


    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.

    Monday, October 16, 2017 8:23 AM
    Moderator
  • Hi,

    The problem isn't that I can't find the reference assemblies it's that dotnet/msbuild is looking for the assemblies in the Reference Assemblies directory under the %programfiles(x86)% environment variable but the installer is installing to the main OS drive regardless of that setting.

    In my previous replies I have said that I don't have VS installed. However, you are right that programs in general get installed to the E drive by default. When I first install the targeting pack it doesn't actually install any files, I'm not really sure why. When I do a repair install the files get installed to the Reference Assemblies directory in the C drive.

    I'm not sure what you mean by "Since the VS was installed in other path which was different from the .NET 4.6 Targeting Pack , I think that's the reason why it could find the assembly directly." since I don't have that installed.

    Thanks

    Monday, October 16, 2017 8:41 AM
  • Hi Matthew Padbury,

    Sorry for my misunderstanding.

    >>You are right that programs in general get installed to the E drive by default

    MSbuild was included in the VS IDE, so actually I mean that your MSbuild tool was installed in E drive even if you don't install the VS, am I right? If not, please share me how I can setup the build Environment as yours, I will repro it firstly.

    I installed the  .NET 4.6 Targeting Pack in my windows10, actually it really doesn't provide the settings to change the setup path. It seems that the real issue is that how MSbuild/dotnet find and refer to the assemblies if we couldn't custom the setup path.

    If I misunderstood this issue, please feel free to let me know.

    Sincerely,

    Jack


    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.


    Monday, October 16, 2017 9:00 AM
    Moderator
  • Hi,

    No worries, I get it's difficult to get to grips with a problem talking like this on a forum.

    So, my understanding is that the dotnet cli delegates to its own bundled version of msbuild so it wouldn't be using any msbuild versions installed by VS.

    Looking at it now, I must have an old msbuild installation anyway because I can see that doing "dotnet msbuild -version" gives 15.3.409.57025 whereas just doing "msbuild -version" gives 15.1.1012.6693.

    To be clear I use the dotnet cli which in turn delegates to msbuild. I never directly call msbuild anywhere.

    Thanks

    Monday, October 16, 2017 9:25 AM
  • It seems that the same issue was reported to the GitHub here:

    https://github.com/dotnet/cli/issues/6770

    Best Regards,

    Jack


    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.


    Tuesday, October 17, 2017 10:55 AM
    Moderator
  • Yeah, that's my initial report of the issue.

    I originally didn't realise that the reference assemblies were installed in the wrong drive so I reported this as an issue with dotnet. However, it eventually became clear that dotnet (through msbuild) expects the reference assemblies to be installed under the directory defined by the %programfiles(x86)% environment variable.

    There's a discrepancy between these 2 systems. Either the assemblies are being installed to the wrong directory or msbuild is looking in the wrong directory.

    Thanks

    Tuesday, October 17, 2017 11:20 AM
  • Hi Matthew Padbury,

    Just open your regedit, view all MSbuild path like:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\

    You would find that where the MSbuild was installed or where it finds the .NET Framework

    https://stackoverflow.com/questions/328017/path-to-msbuild

    Best Regards,

    Jack


    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.


    Thursday, October 19, 2017 7:32 AM
    Moderator
  • Hi,

    I think that registry entry is for older versions of msbuild. In the stackoverflow link you can see version 15 is instead installed with Visual Studio at "E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin". However, it looks like dotnet cli does come with its own msbuild dll installed with it under under "E:\Program Files\dotnet\sdk\2.0.0".

    The version numbers for these files also match those I gave earlier with the more recent version being the one installed with dotnet.

    Could you please clarify what you would like me to do?

    Thanks

    Thursday, October 19, 2017 11:11 AM
  • Hi Matthew Padbury,

    Since this forum is just to discuss the .NET Setup issue, not the real dotnet cli expert, but I could provide a path/my understanding for this issue.

    The msbuild was different from the one in dotnet, I also get some information here,  but they would use the same theory, I mean that all called path was written in the registry. Like my previous reply, the MSBuild was installed in C, and the called .NET path by the MSbuild was also in C drive in the registry.

    As you said that the MSBuild was installed to "E:\Program Files\dotnet\sdk\2.0.0", you could discuss with the dotnet cli expert in the GitHub, and know how it really calls the MSBuild, and then find the information/called path in the registry like above screen shot.

    I think The real reason is the paths the command line try to find the dll files in the registry would be in E drive, but the default .NET target package was installed in C, so it couldn't find and launch them directly.

    To really resolve this issue, I think you also find certain nice workarounds:

    (1) Install the command line tool in the same drive as the .NET target package in default.

    (2) Just use the absolute path as you used before: dotnet msbuild -p:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6".

    (3) Just discuss with the dotnet cli expert here, and find the information in registry, or edit the registry would be also a path, but generally we'd better not to modify it. 

    If it was clearly, feel free to let me know. I will also discuss with other members, if I get any update, I will share it here.

    Sincerely,

    Jack


    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.

    Friday, October 20, 2017 1:02 AM
    Moderator
  • Hi,

    According to that stackoverflow post you linked dotnet uses its built in version of msbuild. So I don't think looking at the registry's msbuild entries is going to help solve this problem because dotnet doesn't need to look in the registry to know where msbuild is installed. Furthermore, the issue isn't that dotnet is using the wrong version of msbuild, the issue is that msbuild expects the Reference Assemblies to be installed under the %programfiles(x86)% environment variable. You can see that in the source code at: https://github.com/Microsoft/msbuild/blob/538c23ba9f9e63858ce6f51f6742ae36651ec0e9/src/Shared/FrameworkLocationHelper.cs#L859

    This is the msbuild code that generates the path to the Reference Assemblies. In order it:

    1. Checks for an overriding environment variable.
    2. If that doesn't exist and assuming we're using Windows, it combines the programs files 32 directory and a string containing "Reference Assemblies\Microsoft\Framework".
    3. If you look up to line 799 you can see that, when generating the program files 32 path, it uses Environment.SpecialFolder.ProgramFilesX86 which I believe is is the %programfiles(x86)% environment variable.

    I'm not an expert on this stuff, I'm not a contributor to these reops, so take what I'm saying with a grain of salt. I got that link from somebody on my initial report of the issue on the dotnet cli repo issues.

    There's no real urgency in solving this because, as we've talked about, there are workarounds. However, if this is the wrong place to be discussing this then please let me know who/where I should be asking. The main reason I asked here was because there were issues with the installer which seemed to fall under .NET Setup issues. I really just want this discrepancy with msbuild and the installer to be fixed.

    Thanks

    Friday, October 20, 2017 12:15 PM
  • Hi Matthew Padbury,

    This case showed some information about "Program Files(x86)" environment variable from msbuild:

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/a743dbea-b214-48ef-aab8-a25ce29ddc1b/program-filesx86?forum=msbuild

    Best Regards,

    Jack


    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.

    Wednesday, October 25, 2017 7:48 AM
    Moderator