none
Solution failing builds (MSBuild and under VS2015) on only one machine. RRS feed

  • Question

  • We have a solution which has existed for months. It builds correctly on all machines it's been tested with under both VS and with MSBuild except on. The one failing machine is Windows 8.1 with VS2015 Enterprise Update 1 though it is succeeding on another machine with the same OS and VS version. The build errors are quite perplexing. There are several of the same form.

    Error CS0234 The type or namespace name 'Collections' does not exist in the namespace 'SSI.SS' (are you missing an assembly reference?)

    The error indicates that the using statement "using SSI.SS.Collections" is invalid. That is not correct. The namespace in question comes from an assembly installed through NuGet. The NuGet package restores correctly, the reference shows as valid and the path to the assembly in question is likewise valid. In addition the VS editor itself does not indicate any such error. The error only appears in the Output and Error List panels in VS2015 or as output during the MSBuild run. In fact Intellisense shows clearly that VS is quite aware of this assembly and it's namespaces. If I type "SSI." Intellesense immediately shows me everything as it should including allowing me to auto-complete the remaining namespace, i.e. SSI.SS.Collections.

    One other anomaly (which I feel is most likely related) is that the build produces a series of build warnings as below only on the one machine for which builds are failing. These warning appear in the VS Output and Error List panels as well as in output for MBBuild:

    Warning The primary reference "AnAssemlby.dll" could not be resolved because it has an indirect dependency on the assembly "Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" which was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".

    Again, these warnings are not correct. The assembly AnAssembly.dll does reference another assembly AnotherAssembly.dll and both are compiled against .NET 4.0. The assembly AnotherAssembly.dll does indeed reference Newtonsoft.Json.dll but the target framework for that referenced Newtonsoft.Json assembly is .NET 4.0 NOT .NET 4.5.

    I've about run out of ideas as to why the exact same solution could behave so differently on two machines that are so close to identical. Any thoughts you might have will be appreciated.

    • Moved by Jamles Hez Monday, December 14, 2015 3:28 AM
    Saturday, December 12, 2015 12:08 AM

Answers

  • First, we have discovered the trigger mechanism for this class of errors, installation of Azure SDK 2.8.1. As I said these build errors were only occurring on a single machine. That machine was the only one that had the Azure SDK 2.8.1. We installed that SDK on two other machines where the build was succeeding. The first had version 2.7 of the SDK and the other had version 2.8 of the SDK. As soon as 2.8.1 was installed those machine immediately starting throwing the same errors during build of the project in question.

    Next, we have also discovered the "source" of this error. The issue is that the NuGet package includes an assembly that has a dependency on another assembly. This secondary referenced assembly is not included in the package itself no is it actually needed in the project. Something in the Azure SDK 2.8.1 appears to have changed the compile mechanism for .NET (VS2015 and MSBuild are both effected) to resolve such secondary references. In this case the resolving mechanism cannot find the secondary assembly an appears to search for as close a match as possible. The match if finds (in a sub-directory of the solution but not in the project) is a version of the secondary assembly that targets a later version of the .NET framework. This causes the compile warnings which in turn appear to be the source of the errors.

    It is VERY disconcerting that an SDK can effect the compiler in this fashion.

    • Marked as answer by Dane Vinson Wednesday, December 16, 2015 7:50 PM
    Wednesday, December 16, 2015 7:50 PM

All replies

  • Hi Dane,

    >>Error CS0234 The type or namespace name 'Collections' does not exist in the namespace 'SSI.SS' (are you missing an assembly reference?)

    Error message means the Collection does not exist in the namespace SSI.SS, but what is SSI.SS, I saw you download from the Nuget, could you share me the Nuget link for this library so that we can test for you.

    I will move the question to .NET framework forum for a better support. Thanks for your understanding.

    --James


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, December 14, 2015 3:27 AM
  • The package is a private internal feed so I cannot share it.

    I know what the exception means but it is erroneous. The namespace does exist in an assembly that clearly shows as a valid references in the project's References. What's more Intellisense in the code editor is aware of the assembly contents as auto-completion is working for classes in the assembly including classes under the SSI.SS.Collections namespace. That is if I type "SSI." I get a drop-down for auto-completion which includes "SS". If I select "SS" and then hit "." I get a drop-down for auto-completion which includes "Collections". If I select "Collections" and then hit "." I get a drop-down for auto-completion of all the classes in the SSI.SS.Collections namespace.

    I'm having trouble understanding how the compile is producing an exception that the compiler isn't finding during code editing.


    • Edited by Dane Vinson Monday, December 14, 2015 5:18 PM
    Monday, December 14, 2015 5:18 PM
  • >>The package is a private internal feed so I cannot share it.


    Based on your description, your package is third-party package, actually, this is out of our support scope. From my point of view, your namespace SSI.SS cannot recognized by .Net Framework, I would suggest you ask for the producer for better support.  Thanks for your understanding.

    Best regards,

    Kristin


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, December 15, 2015 6:03 AM
  • The package was created by us. Your assertion that it's an issue with the package is 100% incorrect. It's not a "package" issue at all. NuGet has deployed the assembly in the package and it is found exactly where the reference in the project shows it to be. As I've pointed out a couple times now the compiler operating in the background for the code editor in VS2015 CLEARLY reads into the assemblies deployed in the package (I have full intellisense on everything in them). The errors only occur on compile and only on one machine.
    Tuesday, December 15, 2015 6:10 AM
  • Hi Dane,

    Sorry I am not clear about your real scenario is. And thanks for pointing me out.

    In order to that, I would suggest you uninstall the package that created by you and test again, If there is no build errors, that is a package issue, if not, that is your program issue or some others.  

    >>The errors only occur on compile and only on one machine

    Do you mean only one machine has compile error? If so, I suspect your machine may miss some dll. Please make double check to make sure there is no these issue.

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

    Have a nice day!

    Kristin


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, December 16, 2015 9:03 AM
  • First, we have discovered the trigger mechanism for this class of errors, installation of Azure SDK 2.8.1. As I said these build errors were only occurring on a single machine. That machine was the only one that had the Azure SDK 2.8.1. We installed that SDK on two other machines where the build was succeeding. The first had version 2.7 of the SDK and the other had version 2.8 of the SDK. As soon as 2.8.1 was installed those machine immediately starting throwing the same errors during build of the project in question.

    Next, we have also discovered the "source" of this error. The issue is that the NuGet package includes an assembly that has a dependency on another assembly. This secondary referenced assembly is not included in the package itself no is it actually needed in the project. Something in the Azure SDK 2.8.1 appears to have changed the compile mechanism for .NET (VS2015 and MSBuild are both effected) to resolve such secondary references. In this case the resolving mechanism cannot find the secondary assembly an appears to search for as close a match as possible. The match if finds (in a sub-directory of the solution but not in the project) is a version of the secondary assembly that targets a later version of the .NET framework. This causes the compile warnings which in turn appear to be the source of the errors.

    It is VERY disconcerting that an SDK can effect the compiler in this fashion.

    • Marked as answer by Dane Vinson Wednesday, December 16, 2015 7:50 PM
    Wednesday, December 16, 2015 7:50 PM