none
MS Build gives warning MSB3247: Found conflicts between different versions of same dependent assembly

    Question

  • Originally posted on TFSBuild forum - requested to post in this MSBuild forum instead: http://social.msdn.microsoft.com/Forums/vstudio/en-US/4e7cbde1-a1d1-4870-be28-684e0822f5b7.
    Refer to above link for extra information. Can confirm manually building project with MSBuild 4 on TFS build servers gives warning, but not when doing same with MSBuild 4 on local developer workstations.

    Build is giving warning MSB3247: Found conflicts between different version of same dependent assembly, despite my binding redirect declarations provided in the web.config file for an ASP.NET MVC 4 Web Application project. 

    Note, the different versions is supposed to differ. Various NuGet packages used, reference slightly different versions of a shared dependency. The local VS2012 build is not giving this warning (anymore - it did for a short while).

    The Build is on an TFS2012 Build Server, and uses the DefaultBuildProcessTemplate from TFS2012. The option to clean the workspace is set in the build configuration (though setting it to any other version makes no difference).

    I've tried so many things, variations, combinations, I'm just at a loss now. Here's the build warnings I'm getting, followed by the relevant declarations from the web.config file:

    MSB3247: Found conflicts between different versions of same dependent assembly

    Consider app.config remapping of assembly "System.Web.Mvc, Culture=neutral, PublicKeyToken=31bf3856ad364e35" from Version "2.0.0.0" [] to Version "4.0.0.0" [XXXX\packages\Microsoft.AspNet.Mvc.4.0.30506.0\lib\net40\System.Web.Mvc.dll] to solve conflict and get rid of warning.

    Consider app.config remapping of assembly "WebGrease, Culture=neutral, PublicKeyToken=31bf3856ad364e35" from Version "1.3.0.0" [] to Version "1.5.2.14234" [XXXX\packages\WebGrease.1.5.2\lib\WebGrease.dll] to solve conflict and get rid of warning.

    Consider app.config remapping of assembly "Antlr3.Runtime, Culture=neutral, PublicKeyToken=eb42632606e9261f" from Version "3.4.1.9004" [] to Version "3.5.0.2" [XXXX\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll] to solve conflict and get rid of warning.


     Assembly redirection declarations from my web.config file:

        <runtime>
            <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                <dependentAssembly>
                    <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
                    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                    <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.5.2.14234" />
                </dependentAssembly>
                <dependentAssembly>
                    <assemblyIdentity name="Antlr3.Runtime" publicKeyToken="eb42632606e9261f" culture="neutral" />
                    <bindingRedirect oldVersion="0.0.0.0-3.5.0.2" newVersion="3.5.0.2" />
                </dependentAssembly>
            </assemblyBinding>
        </runtime>


    It doesn't happen locally with VS2012, but it is consistently presented in every TFS Build.

    I noticed a configuration file in the /obj/Debug folders during the build saw that/obj/Debug/MyMvcProject.csproj.App.config and it initially contains some assembly redirects (none of these are in my web.config btw. - so I have no idea where they are coming from??):

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <dependentAssembly>
            <assemblyIdentity name="System.IO" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.6.3.0" newVersion="2.6.3.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.2.15.0" newVersion="2.2.15.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Net.Http.Extensions" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.2.15.0" newVersion="2.2.15.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.2.15.0" newVersion="2.2.15.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Net.Http.WebRequest" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.2.15.0" newVersion="2.2.15.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.6.3.0" newVersion="2.6.3.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.6.3.0" newVersion="2.6.3.0" />
          </dependentAssembly>
        </assemblyBinding>
      </runtime>
    </configuration>


    Notice how the above does not include any of the assemblyRedirections from my web.config mentioned at the top of this post. If I build this locally in VS2012, the file looks different and includes everything from the web.config file, but with the runtime\assemblyRedirect declarations from the web.config file updated to include the ones from immediately above. See below for detailed comparison:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <appSettings>
        <!-- All the stuff from the web.config file -->
      </appSettings>

      <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <dependentAssembly>
            <assemblyIdentity name="System.IO" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.6.3.0" newVersion="2.6.3.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.2.15.0" newVersion="2.2.15.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Net.Http.Extensions" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.2.15.0" newVersion="2.2.15.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.2.15.0" newVersion="2.2.15.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Net.Http.WebRequest" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.2.15.0" newVersion="2.2.15.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.6.3.0" newVersion="2.6.3.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.6.3.0" newVersion="2.6.3.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-2.2.15.0" newVersion="2.2.15.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.5.2.14234" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="Antlr3.Runtime" publicKeyToken="eb42632606e9261f" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-3.5.0.2" newVersion="3.5.0.2" />
          </dependentAssembly>
        </assemblyBinding>
      </runtime>

      <system.web>
        <!-- all the content from my web.config file -->
      </system.web>

      ...
    </configuration>


    I also noticed that this file ends up under the \bin folder as \bin\MyMvcProject.dll.config (I cannot recall whether this always works that way with web projects since we have a web.config file one folder up usually).

    Anyone have some ideas? 


    • Edited by Jaans Thursday, October 10, 2013 4:35 AM Fix incorrect MSB warning code
    Thursday, September 26, 2013 6:33 AM

Answers

  • I have finally managed to isolate the root cause of this error and identify a few red-herrings.

    First, it is a red herring that the issue does not occur where Visual Studio 2012 installed or does not happen on the developer workstations. While the issue occurs consistently on the build servers (TFS Build), it happens on the workstations too, provided the steps "Batch Clean All", followed "Build" are followed.

    Second, I can now confirm that the culprit for the MSB 3247 warning is the Microsoft BCL Build Nuget Package:

    • Microsoft.Bcl.Build.1.0.10

    It modifies the web application project file, adding the following Import:

    <Import Project="..\packages\Microsoft.Bcl.Build.1.0.10\tools\Microsoft.Bcl.Build.targets" Condition="Exists('..\packages\Microsoft.Bcl.Build.1.0.10\tools\Microsoft.Bcl.Build.targets')" />

    <Target Name="EnsureBclBuildImported" BeforeTargets="BeforeBuild" Condition="'$(BclBuildImported)' == ''">
      <Error Condition="!Exists('..\packages\Microsoft.Bcl.Build.1.0.10\tools\Microsoft.Bcl.Build.targets')" Text="This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=317567." HelpKeyword="BCLBUILD2001" />
      <Error Condition="Exists('..\packages\Microsoft.Bcl.Build.1.0.10\tools\Microsoft.Bcl.Build.targets')" Text="The build restored NuGet packages. Build the project again to include these packages in the build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317568." HelpKeyword="BCLBUILD2002" />
    </Target>

    If I comment it out of the project file, the issue on the local workstations and the TFS Build Servers goes away.

    Unfortunately I do not know what the impact of commenting out the above <Import /> really means. Can someone from MS please comment? Can I leave it commented out - what will happen.

    The reason this Microsoft.Bcl.Build NuGet package is part of the project is because it's marked as a dependency to the Microsoft.Net.Http NuGet package which we do use. Earlier versions of the Microsoft.Net.Http NuGet package did not have this dependency on Microsoft.Bcl and Microsoft.Bcl.Build packages.

    Hope this helps someone.


    Thursday, October 10, 2013 4:34 AM

All replies

  • Hi,

    There exists different  settings for build environment between local machine and Build Server so the warning MSB3274 occurs.

    Here are some suggestions below:

    • First,please try to use the MSBuild command /verbosity:diagnostic to get more detailed error informatioin.
    • Then,please check if the publisher policy that might affect the version settings has been set to no.

    When a component vendor releases a new version of an assembly, the vendor can include a publisher policy so applications that use the old version now use the new version. To specify whether to apply publisher policy for a particular assembly, put the <publisherPolicy> element in the <dependentAssembly> element.

    The default setting for the apply attribute is yes. Setting the apply attribute to no overrides any previous yes settings for an assembly.

    Permission is required for an application to explicitly ignore publisher policy using the <publisherPolicy apply="no"/> element in the application configuration file.

    For more information,please refer to the following links:

    <assemblyBinding> Element for <runtime>:

    http://msdn.microsoft.com/en-us/library/twy1dw1e.aspx

    <publisherPolicy> Element:

    http://msdn.microsoft.com/en-us/library/cf9025zt.aspx 

    Here is one related topic below:

    Resolving MSB3247 - Found conflicts between different versions of the same dependent assembly

    In addition,please clarify the relationships between mvc project and web project with details so that we can have a better understanding of this issue.

    Best Regards,

    Jane.


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.


    Friday, September 27, 2013 7:52 AM
  • Hello Jane

    Thank you for your reply.
    PS: It's MSB 3247 and not 3274.

    Suggestion 1 - Run build with detailed verbosity:
    I ran the build with diagnostic detail and the from ResolveReferences build task, it confirm that for example one assembly System.Web.Optimization.dll (v1.1.0) has reference to a shared assembly WebGrease (v1.3.0.0), and that another assembly (the project itself) has a reference to the same assembly WebGrease but for v1.5.2.14234. The same goes for other shared dependent assemblies - see below. 

    There was a conflict between "WebGrease, Version=1.5.2.14234, Culture=neutral, PublicKeyToken=31bf3856ad364e35" and "WebGrease, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35". (TaskId:79) "WebGrease, Version=1.5.2.14234,
     Culture=neutral, PublicKeyToken=31bf3856ad364e35" was chosen because it was primary and "WebGrease, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was not. (TaskId:79)
    References which depend on "WebGrease, Version=1.5.2.14234, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [D:\Staging\1\Dish\Default\Sources\packages\WebGrease.1.5.2\lib\WebGrease.dll]. (TaskId:79) D:\Staging\1\Dish\Default\Sources\packages\WebGrease.1.5.2\lib\WebGrease.dll
     (TaskId:79) Project file item includes which caused reference "D:\Staging\1\Dish\Default\Sources\packages\WebGrease.1.5.2\lib\WebGrease.dll". (TaskId:79)
    WebGrease, Version=1.5.2.14234, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL (TaskId:79)
    References which depend on "WebGrease, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" []. (TaskId:79) D:\Staging\1\Dish\Default\Sources\packages\Microsoft.AspNet.Web.Optimization.1.1.0\lib\net40\System.Web.Optimization.dll
     (TaskId:79) Project file item includes which caused reference "D:\Staging\1\Dish\Default\Sources\packages\Microsoft.AspNet.Web.Optimization.1.1.0\lib\net40\System.Web.Optimization.dll". (TaskId:79)
    System.Web.Optimization, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL (TaskId:79) There was a conflict between "Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f"
     and "Antlr3.Runtime, Version=3.4.1.9004, Culture=neutral, PublicKeyToken=eb42632606e9261f". (TaskId:79) "Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f" was chosen because it was primary and "Antlr3.Runtime,
     Version=3.4.1.9004, Culture=neutral, PublicKeyToken=eb42632606e9261f" was not. (TaskId:79) References which depend on "Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f" [D:\Staging\1\Dish\Default\Sources\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll].
     (TaskId:79) D:\Staging\1\Dish\Default\Sources\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll (TaskId:79) Project file item includes which caused reference "D:\Staging\1\Dish\Default\Sources\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll". (TaskId:79)
     Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL (TaskId:79) References which depend on "Antlr3.Runtime, Version=3.4.1.9004, Culture=neutral, PublicKeyToken=eb42632606e9261f" []. (TaskId:79)
     D:\Staging\1\Dish\Default\Sources\packages\WebGrease.1.5.2\lib\WebGrease.dll (TaskId:79) Project file item includes which caused reference "D:\Staging\1\Dish\Default\Sources\packages\WebGrease.1.5.2\lib\WebGrease.dll". (TaskId:79) WebGrease, Version=1.5.2.14234,
     Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL (TaskId:79)
    Consider app.config remapping of assembly "System.Web.Mvc, Culture=neutral, PublicKeyToken=31bf3856ad364e35" from Version "2.0.0.0" [] to Version "4.0.0.0" [D:\Staging\1\Dish\Default\Sources\packages\Microsoft.AspNet.Mvc.4.0.30506.0\lib\net40\System.Web.Mvc.dll]
     to solve conflict and get rid of warning. (TaskId:79) Consider app.config remapping of assembly "WebGrease, Culture=neutral, PublicKeyToken=31bf3856ad364e35" from Version "1.3.0.0" [] to Version "1.5.2.14234" [D:\Staging\1\Dish\Default\Sources\packages\WebGrease.1.5.2\lib\WebGrease.dll]
     to solve conflict and get rid of warning. (TaskId:79) Consider app.config remapping of assembly "Antlr3.Runtime, Culture=neutral, PublicKeyToken=eb42632606e9261f" from Version "3.4.1.9004" [] to Version "3.5.0.2" [D:\Staging\1\Dish\Default\Sources\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll]
     to solve conflict and get rid of warning. (TaskId:79) C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1605,5): warning
    MSB3247: Found conflicts between different versions of the same dependent assembly. [D:\Staging\1\Dish\Default\Sources\UI.Web.Mvc\UI.Web.Mvc.csproj]


    The above is correct because WebGrease v.1.5.2.14234 is a backwards compatible update to v1.3.0 and there is a relevant binding redirect for it in the web.config file of the project (same goes for the other shared assemblies) - the issue is that on the build servers, it is not picking up that assembly redirection from the web.config file, and then correctly issues MSB3247 as a result. On the developer workstations it is indeed picking up on the redirections in the web.config file and as expected, does not issue the warninig.

    Very strangely, as an experiment, I added to the web project, an app.config file (containing the binding redirect declarations - I still kept them in the web.config file too) and it did successfully pick up on the binding redirections from there, and did not issue the build warning. So it seems that MSBuild 4 somehow not happy with the web.config file.

    Suggestion 2 - Check publisher policy settings
    In my original post above, you can see that there is no publisher policy element specified, and therefore there is no suppression of the redirection.

    Related Post - Found conflicts between different version of the same dependent assembly.
    I have look at that post initially and even used the "AsmSpy" utility to confirm the above. The post does not apply because the versions are supposed to be different and the relevant assembly redirection declarations are specified in the web.config file, except that it is not honoured by MSBuild on the build servers, but on the workstations using MSBuild to build the project does not cause the issue.

    Clarify project source code structure and details

    • It's a multi-project solution, with class Libraries and an ASP.NET MVC 4 project. 
    • The class libraries are cross-cutting or layer-roled (e.g. BusinessLayer) and the Web project has project references to them. These references do not form part of the MSB3247 warning. 
    • All projects target .NET 4.0.
    • All workstations and build servers have the latest Windows Updates applied, including VS 2012 Update 3 for the developer workstations and TFS 2012 Update 3 on the build servers.
    • All have .NET 4.5 installed.
    • All are 64-bit OS and are using MSBuild 4 from Framework64.


    Thanks again for your help,
    Jaans




    • Edited by Jaans Saturday, September 28, 2013 1:17 AM tweak html for build layout
    Saturday, September 28, 2013 1:14 AM
  • Hi Jaans,

    Please accept my apology for my carelessness in the previous reply.

    And thanks for providing the detailed analysis here.

    Since I don't have the test environment at present,I have delivered this case to the team members who have rich technical experience for better solutions, which might take some time.

    All of us would appreciate your patience.

    Have a nice day.

    Jane.


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Monday, September 30, 2013 7:53 AM
  • Thank you Jane.

    OK will await their feedback. Hopefully we can resolve this easily.

    Jaans

    Tuesday, October 01, 2013 11:24 PM
  • Some additional information that may or may not be useful.

    The project in question, uses the Microsoft BCL Build (v1.0.10) NuGet Package:
    https://www.nuget.org/packages/Microsoft.Bcl.Build
    Friday, October 04, 2013 3:03 AM
  • Some more info:

    I saw a setting in the properties window for the web project (I don't recall seeing it there ever before), that might relate:

    http://i.imgur.com/ULYoDUW.png

    If I set the option "Use msbuild to obtain project references" to "True", and then do a "Clean" followed by a "Build" of the web project, I'm able to reproduce the warning seen on the Build Server.

    NB: If I build (or rebuild) again, then the warning does not show anymore. Only if I "Clean" and then "Build" does it appear, but it disappears after a second and subsequent build/rebuilds.

    Friday, October 04, 2013 11:39 AM
  • Hi Jaans,

    Thanks for these detailed remarks.

    The experts are handling thes case at present and would take these valuable information into consideration.

    Best Regards,

    Jane.


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Monday, October 07, 2013 12:42 AM
  • Hi,

    We have looked into the issue and from a support perspective this is really beyond what we can do here in the forums. If you cannot determine your answer here or on your own, consider opening a support case with us. Visit this link to see the various support options that are available to better meet your needs:  http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone.

    Thanks!


    Shaleen Thapa

    Monday, October 07, 2013 10:01 PM
  • Yeah..fine..ok. Thanks anyway.

    PS: Definitely not the answer and should remain unanswered until a solution is found by someone.

    Tuesday, October 08, 2013 3:59 AM
  • I have finally managed to isolate the root cause of this error and identify a few red-herrings.

    First, it is a red herring that the issue does not occur where Visual Studio 2012 installed or does not happen on the developer workstations. While the issue occurs consistently on the build servers (TFS Build), it happens on the workstations too, provided the steps "Batch Clean All", followed "Build" are followed.

    Second, I can now confirm that the culprit for the MSB 3247 warning is the Microsoft BCL Build Nuget Package:

    • Microsoft.Bcl.Build.1.0.10

    It modifies the web application project file, adding the following Import:

    <Import Project="..\packages\Microsoft.Bcl.Build.1.0.10\tools\Microsoft.Bcl.Build.targets" Condition="Exists('..\packages\Microsoft.Bcl.Build.1.0.10\tools\Microsoft.Bcl.Build.targets')" />

    <Target Name="EnsureBclBuildImported" BeforeTargets="BeforeBuild" Condition="'$(BclBuildImported)' == ''">
      <Error Condition="!Exists('..\packages\Microsoft.Bcl.Build.1.0.10\tools\Microsoft.Bcl.Build.targets')" Text="This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=317567." HelpKeyword="BCLBUILD2001" />
      <Error Condition="Exists('..\packages\Microsoft.Bcl.Build.1.0.10\tools\Microsoft.Bcl.Build.targets')" Text="The build restored NuGet packages. Build the project again to include these packages in the build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317568." HelpKeyword="BCLBUILD2002" />
    </Target>

    If I comment it out of the project file, the issue on the local workstations and the TFS Build Servers goes away.

    Unfortunately I do not know what the impact of commenting out the above <Import /> really means. Can someone from MS please comment? Can I leave it commented out - what will happen.

    The reason this Microsoft.Bcl.Build NuGet package is part of the project is because it's marked as a dependency to the Microsoft.Net.Http NuGet package which we do use. Earlier versions of the Microsoft.Net.Http NuGet package did not have this dependency on Microsoft.Bcl and Microsoft.Bcl.Build packages.

    Hope this helps someone.


    Thursday, October 10, 2013 4:34 AM
  • Thank you, Jaans.

    What you have contributed to would help those who are confronting with the similar issue a lot.

    Best Regards,

    Jane.


    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.

    Thursday, October 10, 2013 6:01 AM
  • Thanks Jane.

    Unfortunately, I've only found the issue and not a fix. The guys from the BCL / .NET team will need to look further to resolve why their NuGet package is causing this issue.

    Can you get them involved?


    Thursday, October 10, 2013 6:04 AM
  • Jaans,

    Please consider reporting this issue on the following sites:

    Best Regards,

    Jane.


    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.

    Thursday, October 10, 2013 6:21 AM